• To: vdv@d...
• Subject: Re: Quick Xpath
• From: David Carlisle <davidc@n...>
• Date: Thu, 18 Jul 2002 10:24:39 +0100
• Cc: vdv@d..., mfeblowitz@f..., jeni@j..., garland_foster@s..., dareo@m..., xml-dev@l...
• In-reply-to: <1026944989.19731.492.camel@ibook> (message from Eric van derVlist on 18 Jul 2002 00:29:49 +0200)
• References: <4DBDB4044ABED31183C000508BA0E97F040ABDAE@f...> <1026942770.19731.423.camel@ibook> <1026944989.19731.492.camel@ibook>

> What I don't find obvious in the recs is why this "reverse order"
> property is lost when you assign the node set "preceding-sibling::*" to
> a variable, but all the XSLT processors seem to behave consistently in
> this respect.

beware it's different in Xpath2 (and works as you thought) but in XPath1
node sets are sets, and being sets they don't have an order.
so _all ordering_ is lost if you return a node set value.
copy-of for-each and friends order their supplied node set into document
order as part of their processing.

David

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.

• References:
  • RE: Quick Xpath
    • From: Mark Feblowitz <mfeblowitz@f...>
  • RE: Quick Xpath
    • From: Eric van der Vlist <vdv@d...>
  • RE: Quick Xpath
    • From: Eric van der Vlist <vdv@d...>

• Prev by Date: Re: Quick Xpath
• Next by Date: Re: Quick Xpath
• Previous by thread: RE: Quick Xpath
• Next by thread: Re: Quick Xpath
• Index(es):
  • Date
  • Thread