[XSL-LIST Mailing List Archive Home]
Re: Antwort: comments. (Re: key() Re: Saxon VS XT)
Subject: Re: Antwort: comments. (Re: key() Re: Saxon VS XT)|
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Fri, 11 Aug 2000 18:58:09 -0700
> > > 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.
I don't know about 'true' transformation language. When
I's see some, I'l think about it. Well, there is some
XML transformation library on top of Prolog... Maybe
Prolog will strike back some day. Sofar I dont like
the snippets which I got from some Prologers.
What I do know is that XSL ( the original one, XSLT + XSL FO )
was a language designed for a pipe of 2 components
( XSLT | XSL FO ) based on the years of expereince
that James Clark got with DSSSL. The thing which
is good for the pipe of 2 components is by induction
good for pipe of N components.
Maybe the original idea of having XSL to be a pipe of 2
components is evil - well, shame on W3C then, who
picked up the wrong model.
Maybe they have made a mistake. Sofar I like this mistake
better than anything else W3C have produced - this
means I'm also making a mistake.
However, your letter makes me feel that I don't
understand what you are really saying.
> Whether pipes make impossible things possible or just turn frustration
> into fun, I dare not judge now. Good question, I'll think about it.
Because pipes do not introduce any new syntax to XSLT, pipes
have no impact on 'possibility' of anything. This means I don't
understand what do you mean comparing 'fun' with 'possibility'.
> > > 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.
I think I already showed that pipes are invariants of call-template.
( This means any pipe could be easliy replaced with the sequence
of call-templates and because any pipe could be always composed
into one stylesheet, this means that you can write any pipe in one
stylesheet of 'ordinary XSLT' ).
This really means that you are saying that that call-template is the
procedural hint, compromising the greatest ideas behind XSLT.
Because I'm just mortal hacker - I simply don't understand
how to avoid call-template, but of course I'l appreciate
the snippet of some code ( in the 'true' transformation language,
'procedural' , 'declaratibve' or whatever ) which will show, say,
calculation of max value of some list - written without
call-template AKA procedural hint.
This will be great to look at.
> 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.
Yes, and because call-template also compomises the same 'true' language,
could you please provide a snippet showing *what* is compromised ?
In case there is some misunderstanding ( as usual ) and / or the
greatest idea behind XSLT is not yet sound - please ignore this letter.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list