Re: process order (still...)
> Okay so according to XPath, the order of attribute nodes is undefined > except for the fact that like namespace nodes, they occur before any child > nodes (text, comment, p.i., or element nodes) of the element node > they are associated with. Yes, they are ordered, but the order varies between parsers. > So, count(@*) should never vary, true > but generate-id(@*) in one > implementation might be equal to generate-id(@*) in some other > implementation. Irrespective of attribute order the strings generated by generate-id are not guaranteed to be the same across different implementations, or even different runs by the same implementation. They are only guaranteed to give the same value on the same node during a given run. > But... why? What is the point of leaving attribute order > up to the parser? Because attributes have no inherent order. If the XML source tree is coming from some in memory model then the attributes will have to just be arbitrarrily output in some order. In particular many systems just store attributes in some hash table, so they go in as they go in but they come out in whatever order the algorithm that walks the hash table spits them out. > And why would a parser decide to put things in something > other than the order the attributes appear in the document? see above, Appart from DOM manipulations just consider attribute defaulting from a DTD. If the DTD supplies an attribute a parser will add it, but nothing in the XML spec says whether the attribute should be first or last or in alphabeic order, each parser will just add it somewhere in its internal model, and when that is exposed as the input tree to XSL you will see different results on different systems. > 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's attribute nodes would come before //img's? yes. > You seem to be implying that apply-templates would not be subject to the > same requirement, but section 5.4 of the XSLT spec says the same thing for > xsl:apply-templates as section 8 says for xsl:for-each: The nodes are > processed in document order, unless a sorting specification is present. Surely you don't expect me to read the spec! I just learn XSL by answering questions on this list, then waiting for people to correct me. (In that case I think `processed in document order' has to mean `processed in any order at all, but results added to output tree in document order, otherwise something is wrong with the world) > Another why... Why would the order in which processing occurs not be the > order in which things get added to the result tree? Because when I buy my 1024 processor parallel processing machine I want to pass 1023 sibling nodes to all get processed at the same time and returned whenever each process finishes, then the remaining processor slots the returned subtrees into the final result tree in the correct place, as they come up. So the final tree has the `correct' order but the actuall processing hapened on each node whenever it happened. Allowing this is the main reason for not allowing template processing to have side effects, so disallowing it again in the text of the rec seems, er, strange. > it does follow that > different result trees could be created by the original poster's example, > which was something like: > > <xsl:for-each select="@*"> yes that will give different results on different systems. David XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
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