[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: process order (still...)

Subject: RE: process order (still...)
From: Kay Michael <Michael.Kay@xxxxxxx>
Date: Thu, 13 Apr 2000 10:27:26 +0100
xml dom parser process order
> 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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.