Subject: Re: Antwort: comments. (Re: key() Re: Saxon VS XT) From: David Tolpin <dvd@xxxxxxxxxxxxx> Date: Thu, 10 Aug 2000 21:57:35 +0500 (AMST) |
> > 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Antwort: comments. (Re: key() R, Paul Tchistopolskii | Thread | Re: Antwort: comments. (Re: key() R, Paul Tchistopolskii |
Memory-saving Prescription for key(, John Robert Gardner | Date | RE: How dynamic is XSL?, Søren Neigaard |
Month |