[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: process order (still...)
Subject: Re: process order (still...) From: Mike Brown <mike@xxxxxxxx> Date: Thu, 13 Apr 2000 00:54:40 -0600 (MDT) |
David Carlisle wrote: > correcting myself > > Sorry you mislead me by throwing in a reference to processing order:-) > > I just gave a correct (I hope) explanation of why @* gives unpredicatble > results 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. So, count(@*) should never vary, but generate-id(@*[1]) in one implementation might be equal to generate-id(@*[5]) in some other implementation. But... why? What is the point of leaving attribute order up to the parser? And why would a parser decide to put things in something other than the order the attributes appear in the document? 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? [re: xsl:for-each processing order being 'document order'] > But this phrase appears to imply that if you go > for-each select="chapter" rather than apply-templates select="chapter" > the processor does have to process the entire document in order. 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. > Note that this issue is completely different from the original question > about attribute order where that actually affects the completed result, > not just the order in which internal processing occurs. Another why... Why would the order in which processing occurs not be the order in which things get added to the result tree? The issue isn't completely different, in my opinion. Now that I understand that 'document order' means different things for different types of nodes, and assuming (perhaps contrary to your assumptions) that processing order is synchronous with result-tree-building order, it does follow that different result trees could be created by the original poster's example, which was something like: <xsl:for-each select="@*"> <xsl:value-of select="concat(name(.),'=',string(.))"/> </xsl:for-each> This doesn't address the ambiguity I introduced above (relative order of attributes of an ordered set of elements), nor does it address the fact that result trees are not the same as serialized result trees ... the XSLT spec doesn't really say what the order of serialization is. :) - Mike ___________________________________________________________ Mike J. Brown, software engineer, Webb Interactive Services XML/XSL stuff: http://www.skew.org/ http://www.webb.net/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
process order was: Getting all the , David Carlisle | Thread | Re: process order (still...), David Carlisle |
Re: Printing out variables with esc, G. Ken Holman | Date | RE: process order (still...), Pawson, David |
Month |