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

[Paul Tchistopolskii <paul at qub dot com>]

> > 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. 
> 
> There is no such thing as a pipe between XSLT and XSL FO.
> XSLT converts something into XSL FO. What happens later
> has no relation to XML. Where do you see several steps piped?

I can explain, but I prefere not to. I can explain after ... 4-6 months.

I suggest you'l just think a bit about extending the logical pipe 
of XSL with  one more component. Or with two more 
components. I know that you have participated in at least 
2 projects which were both doing the same: passing some 
large tree from one transformation to another. Internally.

Are you questioning the idea of  turning complex 
transformation into superposition of several  simple 
transformations? I know  that  you was not questioning 
this concept just a few months ago - well, maybe 
now you see something new. I'm just trying to understand 
*what* is that 'new' - and I can not get the answer. 

If you are not questining the idea - pipes just give you the 
logical way to make that transition and as I have said 
many  times already THIS HAS NOTHING TO DO WITH  
XSLT SYNTAX. Pipes is a concept. The way of thinking.
The simple way of designing complex XSLT transformations.
I don't see any importat need in 'special syntax' . As I already 
said it is just a bit more convinient for me to have multiple 
stylesheets. Not a rocket science. Well, it appears I've
started repeating myself and this is a bad sign.

<aside>
I'm anyway not using XSLT syntax - I don't understand 
why there is no 'else'. Maybe 'else' is also procedural
hint? What will be XSLT if we'l drop out all the 
'procedural hints'  ? I doubt it will make XSLT a 'true'
transformation language. ( Which you are talking about 
but without any samples ).
</aside>

> > > 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'.
> > 
> Pipes ARE new syntax. One needs a way to describe a pipe (A|B|C|tie D). 
> The way it describes it is a language. The language for pipes is either becomes
> a part of XSLT or an extension to it.

I  *never* said  anything like this. All I'm saying is that 
'thinking pipes' could help ( and I explained that on 3 
particular examples). I don't understand how 
XSLT syntax could be 'extended' to describe pipes 
and I don't  want to think about that, because it is pointless.

I think what you are saying has no relation to my letters.

> Paul,
> 
> the question is not whether to use call-template, key, pipes or not for
> the sake of their conceptuality or purity. Anything that gives result
> may and must be used. 
> 
> The point is that there is no difference other than personal preferences
> between (call-template/key staff and using pipes) -- they do the same
> thing to the declarative ideas of XSLT and have equally harmful. But
> useful. Pipes are just another language for the same techniques. And
> it is not necessarily a better language, since pipes have only limited
> functionality compared to call-template/key, while providing the 
> same level of drawbacks.

call-template / key are XSLT syntax constructions. ( first looks unavoidable,
second is optional ).

pipes have nothing to do with XSLT syntax. 

How can you compare apples to oranges and produce some reasonable 
conclusions out of that comparsion - I of course don't understand, that's 
why I'm asking for some snippets of the code or pseudocode. 
 
> There are may be cases when pipes are the most convenient, while
> at other times they are just a pain in the neck. Whether they must
> be made a part of XSLT or not is an open question.

I don't think you are talking to me here. I'l be glad to 
get a quote from my letters that makes you talking 
this, because I don't understand why ( and never 
said ) that the 'way of thinking' should be a 
'part of XSLT' 

Rgds.Paul.




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