Subject: Re: Antwort: comments. (Re: key() Re: Saxon VS XT) From: Paul Tchistopolskii <paul@xxxxxxx> Date: Sat, 12 Aug 2000 09:55:17 -0700 |
> > 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Antwort: comments. (Re: key() R, David Tolpin | Thread | Re: Antwort: comments. (Re: key() R, Paul Tchistopolskii |
[ANN] Change Stylesheet Power Toy, Chris Bayes | Date | RE: Embedding HTML document in XSL, Sunitha |
Month |