? DOM committee to "address this issue"? [Re: The Peace Process: DOM and namespaces...]
James.Anderson at mecomnet.de
Sat Feb 13 20:59:34 GMT 1999
(in response to a note which appeared on xml-dev)
After reading remarks to the effect, that all principal parser providers had
released, or would soon release, parser versions with namespace support, I
retrieved several versions to "see what I could see." four to be exact: xml4j,
msxml/dcxml, sun, and oracle.
I observed, in effect, four different language bindings for the (as yet
unspecified) model for namespaces and decided, well, to go back to work.
Upon seeing this message, however, I would like to note that it would be a
welcome contribution from the respective implementers if they would offer some
account as to why their respective interface is the way to go.
In general, I was perplexed that the namespace URI appears to be on its way to
becoming a property of the node (element or attribute), rather than of the
node's name. What processing scenarios are people working eith for which this
interface makes sense? :
? wholesale transplantation of "nodes" from one namespace to another (ie
independent of the names)?
? matching nodes based on uri without regard to names?
? if one mutates a nodes namespace, does this affect the namespace of
explicitly qualified attribute names?
? what sort of uri mutations are proposed and how is coherence maintained
between the element name, attribute names (uri's and prefixes) where all are
? i didn't find facilities in all cases to operate on nodes with universal
names, but where i did, i was uncertain how does one would use use something
like getAttribute(uri x name) or getInheritedAttribute(uri x name) to find
attributes in "no namespace"?
I was also disappointed, that the interfaces, as best i could surmise, offer
as yet not quite interoperable mechanisms for working with namespaces.
(watch out, here comes another one of my tables; please set your windows on
msxml/dcxml (betatwo) sun (ea2)
oracle (1_0_0_3) ibm* (2.0.0)
encoded name: Node.getNodeName, Node.getNodeName
local part: IXMLDomNode.getBaseName, NamespaceScoped.getLocalName
namespace URI: IXMLDomNode.getNamespace, NamespaceScoped.getNamespace
prefix: IXMLDomNode.getPrefix, ? ?
universal name: ? ?
expanded name: ? ? ?
(* with whom I commisserate for having taken appendix a seriously :)
Looks like the DOM comittee is in for an interesting week...
How about an addenda to dom-level-1 which is just the java languange binding
for the (as yet unspecified) namespace-aware name/attribute/element interface,
also to include some arguments for the decision to model names within the
application either as atomic or as explicit (string X string).... ?
Chris Lovett wrote:
> An interesting thread. First, the DOM committee is addressing this issue
> this week. IMHO the degree in which XML namespaces succeed will determine
> the breadth and depth of the success of XML in general, and not just XSL -
> so I eagerly await what the DOM committee comes up with.
> We have a namespace implementation in our DOM which we are shipping in IE5,
> and I think IBM and Sun also have a solution. I didn't fully understand all
> the arguments presented here - but our experience is that although
> namespaces are not trivial to implement in an efficient manner, it is
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev