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...)



> 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(@*[1]) in one
> implementation might be equal to generate-id(@*[5]) 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[1]'s attribute nodes would come before //img[2]'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

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