On Tue, 11 Dec 2001, James Strachan wrote:
> If we had this XML
>
> <foo>X <bar>Y</bar> Z</foo>
>
> And we evaluated the XPath expression
>
> * | text()
>
> We'd get
>
> Element(<bar>),. text('X'), text('Z')
>
> Rather than
>
> text('X'), element(<bar>), text('Z')
>
> So the document order is wrong. Basically because the XPath expressions are
> evaluated in full and appended together by the union operator, rather than
> intermingled in document order.
>
> I've heard Michael Kay say in the past that maintaining document order is
> one of the hardest parts of XSLT.
>
> In simple terms for common path expressions like * | @* | text() or
> whatever, we need to evaluate all of the expressions in the union on each
> node as we navigate - rather than walking the tree entire for each
> expression then concatenating the results together .
>
> I'm a bit heavily loaded until the towards the end of next week, does anyone
> fancy diving in and taking a look? This could be quite hard to fix...
In werken.xpath, I played with a DocumentComparator that simply walked
the entire document head-to-toe, and created an index that lets you
decide if Node-X comes before Node-Y. Expensive operation, but then
it allows perfect post-selection re-ordering into document order.
Unions can get tricky when you do
$foo/bar | $baz/cheese
where $foo and $baz may be ordered any way, relative to each other.
-bob
_______________________________________________
Jaxen-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jaxen-interest
