Subject: Re: Worry about using lexical order for preferences.
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
eList eXpress LLC