? DOM committee to "address this issue"? [xml-dev->Re: The Peace Process: DOM and namespaces...]

(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
explicitly asserted.
 ? 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
"wide" :)

                  msxml/dcxml (betatwo)       sun (ea2)                     
oracle (1_0_0_3)                          ibm* (2.0.0)
encoded name:     Node.getNodeName,           Node.getNodeName              
NSAttribute,NSElement.getQualifiedName    Namespace.getName
local part:       IXMLDomNode.getBaseName,    NamespaceScoped.getLocalName  
NSAttribute,NSElement.getLocalName        Namespace.getNSLocalName
namespace URI:    IXMLDomNode.getNamespace,   NamespaceScoped.getNamespace  
NSAttribute,NSElement.getGetNamespace     Namespace.getNSName
prefix:           IXMLDomNode.getPrefix,      ?                              ?
                                        ?
universal name:   ?                           ?                             
NSAttribute,NSElement.getExpandedName     Namespace.getUniversalName
expanded name:    ?                           ?                              ?
                                        Namespace.createExpandedName

(* with whom i commiserate 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
> doable.
>

Received on Saturday, 13 February 1999 15:59:24 UTC