Subject: Re: Worry about using lexical order for preferences.
Dale, That's a pretty important point about DOM. We should fix our definition. One possibility is an attribute whose values are 1, 2, 3,... Can anyone think of something better? Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* "Moberg, Dale" <Dale_Moberg@stercomm.com> on 01/30/2001 09:30:16 AM To: ebxml-tp@lists.ebxml.org cc: Subject: Worry about using lexical order for preferences. 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
Powered by
eList eXpress LLC