RE: process order (still...)

Well, this is probably not why attributes aren's considered to be
ordered, but at least from my perspective there is a good reason for it. 

>Mike Brown wrote 
[snip]

> 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.
> [snip]
> 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?

There is a semantic difference. Element nodes have the content -- the
semantic meaning of the document. At least in the document world, the
order in which content is written and presented frequently can affect
not only the meaning but the entire 'information design' (yes, some
writers do do this). 

Attributes, however, are more like 'meta-data' about the content. So
a "mark" and a "role" attribute on a list item have some meaning about
the list item, but don't necessarily interact with each other. The
order in which they are processed or used doesn't have any semantic
meaning to the information. 

I do agree that this can create some strange effects in terms of 
actual processing. I have actually run into a situation where this
created a problem in the output -- but that was because Microsoft 
HTML help insisted on attributes in a specific order in order to 
behave reliably, which from my perspective is bad design on their part.
I finally got around the issue by changing my template to process the 
attributes individually in a specific order. A little more verbose, but
it worked (and I'm always glad when I can say that). 

Sara


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list