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

[David Tolpin <dvd at hragir dot aua dot am>]

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

I just wanted to say that, in general, dividing a transformation
into steps is much like providing roadsigns. True transformation
language must succeed without the need for pipes.

Whether pipes make impossible things possible or just turn frustration
into fun, I dare not judge now. Good question, I'll think about it.

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

Pipes cannot be described in the declarative manner; thus, using pipes
compromises one of the greatest ideas behind XSLT. Pipes are procedural
hints added to declarative description.

keys() are essentially the same technique - procedural preparation
of data for more efficient declarative processing.  They abuse
declarative power of XSLT by making the code depending on non-local
actions.

Whether pipes or keys are more evil is not an issue. The issue is that
they represent the same compromise using slightly different technologies.
Some are more comfortable with vertical split, while others cut horizontally.

Dvd


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list