This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Antwort: comments. (Re: key() Re: Saxon VS XT)
- To: xsl-list at mulberrytech dot com
- Subject: Re: Antwort: comments. (Re: key() Re: Saxon VS XT)
- From: Paul Tchistopolskii <paul at qub dot com>
- Date: Thu, 10 Aug 2000 01:49:52 -0700
- Organization: The Qub Group
- References: <200008100724.MAA19132@mix.aua.am>
- Reply-To: xsl-list at mulberrytech dot com
----- Original Message -----
From: David Tolpin
> Great poetry is very difficult to create, but is a great pleasure to
> read.
Yes, there is one language which provides a built-in support
for writing 'poetry'. I mean of course perl. Just kidding.
> On the other hand, key() in my opinion, is the true equivalent to pipes.
I think it is not. We have to define the 'equivivalence' first.
> That is, pipes are on the same level abstract as key() is, and using
> pipes instead of key() does not solve the problem of abstraction from
> low-level data.
How do you measure 'abstraction from low-level data' ?
I'm defining the generic and 'second-class' entities of XSLT in
terms of 'logical' 'ideal' XSLT VM ( not talking about the implemenation
of XSLT VM yet ).
At the moment I think that any key() could be written as pipe(s), but
probably not any pipe could be written with key() (s). I simply don't
even understand how "stream of <lines> | grouping page with
footer" usecase could be done with key(). Mind to show? I mean
I have provided the usecase. There was a mistyping PAGE_WIDTH
should be actually PAGE_HEIGHT... but I think the rest is clear?
I think that key() -> pipe trasition is at least more obvious
than pipe ->key(). To me this means that pipe is more generic entity.
Maybe I'm wrong - we could continue with some more usecases,
if you have some.
To explain maybe better , what I'm talking about:
Another example of 'first-class' and 'second-class' constructions
could be apply-templates and for-each.
I think almost any for-each Xpath { body } could be converted into
apply-templates mode = "f"
template match = Xpath mode="f" { body }
( pull becomes push, BTW. because apply-template
also allows xsl:sort - it seems that this transition is OK ).
I don't see the equaly easy way to express apply-template
with for-each.
To me this means that in terms of 'ideal' XSLT virtual machine
apply-template is more generic than for-each.
For sure there could be some tricky usecases. I just don't see
them yet.
> However, if XSLT provide a way to describe complex superpositions
> of transformation (of which sequence is just the simplest case),
> it would great. Unfortunately, I don't see now how to do it without
> sacrificing clarity of the language.
There is 'practical' clarity and there is 'real' clarity ( I'm saying
this even I agree that 'clarity' is subjective ).
For example, in C compiler, the 'register' roadsign appeared
only because DEC PDP 11 CPU had 6 registers and Dennis
could not resist from using them. I doubt that modern optimizing
compilers pay too much attention to this 'register' artifact.
The real 'clarity' for C could be placing garbage collector
into stdio and have a function prototypes.
Rgds.Paul.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list