Re: Worry about using lexical order for preferences.

[christopher ferris <chris.ferris@east.sun.com>]

Dale,

A NodeList is an ordered collection. There are DOM methods
that return a NodeList such as:

getElementsByTagName 
	Returns a NodeList of all descendant Elements with a 
	given tag name, in the order in which they are encountered 
	in a preorder traversal of this Element tree. 

From the DOM level 2 spec:

"The DOM also specifies a NodeList interface to handle ordered 
lists of Nodes, such as the children of a Node, or the
elements returned by the getElementsByTagName method of the 
Element interface, and also a NamedNodeMap interface to handle 
unordered sets of nodes referenced by their name attribute, 
such as the attributes of an Element."

Note that order of attributes is "not significant" as per the
XML 1.0 specification:
	http://www.w3.org/TR/2000/REC-xml-20001006#sec-starttags

Cheers,

Chris

"Moberg, Dale" wrote:
> 
> Hi
> 
> One idea under consideration in TPA WG is
> to use the CPP lexical order for preferences
> among those elements having duplicated
> capabilities (such as several possible
> delivery channels and so on).
> 
> I noticed yesterday that a popular
> implementation of DOM API in Java (Xerces)
> has a number of methods returning
> multiple elements that do not preserve
> lexical order. For example, the "getAttributes"
> method returns a NamedNodeMap
> in which the nodes are alphabetically
> ordered, so that index 0, for example,
> returns the alphabetically first
> attribute by name of attribute and not the
> lexically first attribute (I guess
> I'd better mention that lexical order here
> just means the order in which
> it occurs in the file/stream).
> 
> So while I have not checked out every
> method (and I think this will be a DOM
> problem, because SAX callbacks do
> follow lexical order as far as I can tell),
> I am wondering whether we should
> be more explicit about preference. Sorry
> to add another item.
> 
> (I should also mention that
> DOM implementations will probably
> be popular for dealing with CPP
> processing because of the need to jump around
> with IDs while figuring out whether
> and how the capabilities match.)
> 
> Dale Moberg
begin:vcard 
n:Ferris;Christopher 
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XML Technology Development
adr:;;One Network Drive;Burlington;Ma;01824-0903;USA
version:2.1
email;internet:chris.ferris@east.Sun.COM
title:Sr. Staff Engineer
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard