Re: Antwort: comments. (Re: key() Re: Saxon VS XT)

[Paul Tchistopolskii <paul@xxxxxxx>]

----- 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