[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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: Thu, 10 Aug 2000 01:49:52 -0700
saxon apply template
----- 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. 


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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.