Subject: Re: Antwort: comments. (Re: key() Re: Saxon VS XT) From: Paul Tchistopolskii <paul@xxxxxxx> Date: Thu, 10 Aug 2000 01:49:52 -0700 |
----- Original Message ----- From: David Tolpin > Great poetry is very difficult to create, but is a great pleasure to > read. Yes, there is one language which provides a built-in support for writing 'poetry'. I mean of course perl. Just kidding. > 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. > 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 ). At the moment I think that any key() could be written as pipe(s), but probably not any pipe could be written with key() (s). I simply don't even understand how "stream of <lines> | grouping page with footer" usecase could be done with key(). Mind to show? I mean I have provided the usecase. There was a mistyping PAGE_WIDTH should be actually PAGE_HEIGHT... but I think the rest is clear? I think that key() -> pipe trasition is at least more obvious than pipe ->key(). To me this means that pipe is more generic entity. Maybe I'm wrong - we could continue with some more usecases, if you have some. To explain maybe better , what I'm talking about: Another example of 'first-class' and 'second-class' constructions could be apply-templates and for-each. I think almost any for-each Xpath { body } could be converted into apply-templates mode = "f" template match = Xpath mode="f" { body } ( pull becomes push, BTW. because apply-template also allows xsl:sort - it seems that this transition is OK ). I don't see the equaly easy way to express apply-template with for-each. To me this means that in terms of 'ideal' XSLT virtual machine apply-template is more generic than for-each. For sure there could be some tricky usecases. I just don't see them yet. > However, if XSLT provide a way to describe complex superpositions > of transformation (of which sequence is just the simplest case), > it would great. Unfortunately, I don't see now how to do it without > sacrificing clarity of the language. There is 'practical' clarity and there is 'real' clarity ( I'm saying this even I agree that 'clarity' is subjective ). For example, in C compiler, the 'register' roadsign appeared only because DEC PDP 11 CPU had 6 registers and Dennis could not resist from using them. I doubt that modern optimizing compilers pay too much attention to this 'register' artifact. The real 'clarity' for C could be placing garbage collector into stdio and have a function prototypes. 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, David Tolpin |
How dynamic is XSL?, Søren Neigaard | Date | RE: How to make the user selecting , Chris Bayes |
Month |