OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-tp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Worry about using lexical order for preferences.


Looks like xerces provides the elements in a way that
is compatible with using lexical order when using
the methods and datastructures Chris mentioned.

> -----Original Message-----
> From: Moberg, Dale 
> Sent: Tuesday, January 30, 2001 9:59 AM
> To: 'christopher ferris'
> Cc: ebxml-tp@lists.ebxml.org
> Subject: RE: Worry about using lexical order for preferences.
> 
> 
> OK, lexical order is not always preserved so I thought
> it was worth noting. I have not checked how the
> getElementsbyTagName is implemented yet (though
> my code is using it...) I will take a look at what
> it does on the sample registry CPP and see 
> whether it adheres to the spec you 
> mention. Still seems like we are being awfully
> minimalistic here, but maybe we can get by.
> 
> Dale
> 
> 
> > -----Original Message-----
> > From: christopher ferris [mailto:chris.ferris@east.sun.com]
> > Sent: Tuesday, January 30, 2001 9:48 AM
> > To: Moberg, Dale
> > Cc: ebxml-tp@lists.ebxml.org
> > 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
> > 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC