This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: process order (still...)


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]