RE: Nasty XPath expressions
> From: Michael Kay [mailto:michael.h.kay@n...] <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?
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format