OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Nasty XPath expressions

[ Lists Home | Date Index | Thread Index ]

> From: Michael Kay [mailto:michael.h.kay@ntlworld.com]

<snip/>

> And a point of detail, which I think Evan Lenz already 
> commented on: XPath
> 1.0 doesn't say the nodes must be sorted in document order, 
> and there are
> many cases where sorting is unnecessary. For example, many 
> operations only
> require selection of the node that is first in document 
> order, which can be
> found without doing a sort.

I think confusion has come in due to an inconsistency between the notion of
a node-set being unordered, and the fact that XSLT can process node-sets as
if they are ordered. For instance, the "for-each" element will process the
nodes in the node-set returned by its "select" expression in document order
(unless it contains child "sort" elements, in which case they determine the
order of processing).

This seems odd that XSLT can treat node-sets as if they are ordered, even
though they are not. I think this is probably what has led to the
misconception (which I shared) that node-sets are ordered.

I'm curious as to the reasoning behind specifying that XSLT implementations
must have some opaque knowledge of the document order of nodes in a
node-set, yet not expose that information in the node-set itself. Was this
done simply to protect XPath implementations that are not XSLT-based from
having to preserve document order in node-sets?





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS