This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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



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

Rgds.Paul.




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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]