Re: [xsl] Re: The Solution -- Re: how to rearrange nodes based on a dependency graph?

Subject: Re: [xsl] Re: The Solution -- Re: how to rearrange nodes based on a dependency graph?
From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
Date: Fri, 21 Dec 2001 10:25:12 -0800 (PST)
--- Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> As beautifully as this is designed, the only sad thing is that
> it can't work without using some Microsoft (or other) extension.
> Apparently the node-set function is available in many xslt
> processors, but then why is it not part of the specification?
> 
> It is my reading, correctme if I'm wrong, that the only reason
> why this node-set function needs to exist in the first place is
> because the result tree fragment has some ugly restriction. The
> XSLT spec mumbles about it being only accessible through string
> functions etc. The node-set apparently turns that result tree
> fragment into real XPath-inspectable trees.
> 

Not being one of the creators of XSLT 1.0 I can't comment on the reasons for this
decision. It is true, that without the xx:node-set() function, XSLT 1.0 is 50%
crippled. Many single-transformation solutions would not be possible without this
function. Therefore, its use and the resulting (slight) portability problem is a
fact of life... :(

This is the only reason I'll have to maintain two XSLT functional programming
libraries -- one for MSXML and one for Saxon.

This same phenomenon of deciding not to include (actually disregarding) a useful
feature -- this is going to be repeated with the omission of support for
higher-order functions in XPath 2.0.

> Furthermore, the only place where this is really needed is for
> the concatenation of the node sets from pSorted and vNextLevel.
> That should have been easily possible in basic XPath. I tried
> rewriting:
> 
>        <xsl:variable name="vrtfNewSorted">
>          <xsl:copy-of select="$pSorted"/>
>          <xsl:copy-of select="$vNextLevel"/>
>        </xsl:variable>
> 
> to this:
> 
>        <xsl:variable name="XvrtfNewSorted"
>                      select="$pSorted|$vNextLevel"/>
> 
> but apparently this orders things in the document order, not
> in the order specified. It's weird that the XPath spec talks
> about node sets when in reality they are ordered. And all of
> this only to prevent the user from rearranging the ordering.

Sets are un-ordered by definition. Document order is a "canonical ordering" so that
everybody will enumerate a set in a standard way. In the same way in mathematics we
may enumerate a set of numbers by their increasing value. Everybody knows that this
is just for convenience and that sets do not have order. 

Obviously, there had to be such canonical ordering. 

The xx:node-set() function is necessary in case nodes must be re-ordered and used
later during the same transformation.

Cheers,
Dimitre Novatchev.

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

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


Current Thread