RE: process order (still...)

[Kay Michael <Michael dot Kay at icl dot com>]

> Okay so according to XPath, the order of attribute nodes is undefined
> 
> So, count(@*) should never vary, but generate-id(@*[1]) in one
> implementation might be equal to generate-id(@*[5]) in some other
> implementation. 
> 
> Also, it seems to be complicated by the fact that element 
> nodes do have a
> natural order. Take for example the node-set returned by this XPath
> expression for an imaginary XHTML document: "//img/@*" ... Could I be
> assured that //img[1]'s attribute nodes would come before //img[2]'s?
> 
> Another why... Why would the order in which processing occurs 
> not be the order in which things get added to the result tree?
> 
This discussion is getting more and more confused. Three points:

1. The order of attributes in an XML element is immaterial. I can't find
anything in the XML spec that says so (the XML spec is very weak on defining
its information model), but this is one of the very few things that all
XML-based information models (the DOM, the XPath model, the infoset,
canonical XML) actually agree on.

2. The results of generate-id() from one implementation are totally
unrelated to the results of generate-id() from any other implementation.
E.g. xt might give the result
"Xae45bf66" while Saxon gives "b11c14a2" for the same node. This therefore
doesn't prove anything. A better illustration is that Saxon will give
different results from
name(@*[1]) depending which XML parser you use, because different XML
parsers present the same attributes in different order.

3. The XSLT processor is free to do things in any order it likes so long as
it gives the same results. If you instantiate the literal result element
<x><a/><b/><c/><d/></x> then the result tree will contain
<x><a/><b/><c/><d/></x>, but there is nothing to say that <a/> was
instantiated chronologically earlier than <d/>. This fact is significant if
you write, say
<a value="{java.input:read()}"/><b value="{java.input:read()}"/>
because read() has a side-effect of changing the current position in the
input file, so the order of execution actually makes a difference. In this
case it is undefined whether <a> will contain the first character read and
<b> the second, or vice versa.

Mike Kay 


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