RE: Questions on Attr, NamedNodeMap, and namespaces

Cathi Davey wrote:

> 1.  In the spec for the Core Level 1, under the Interface Attr, it says
> "the Node attributes parentNode, previousSibling, and nextSibling have a
> null value for Attr objects."   Does this mean that every attribute has
> an attr object? If so, it's not a child or an attribute right?  The
> value of the attribute is an attr object.

Yes, each (XML) attribute results in an object that exposes the Attr 
interface. I assume that this is what you mean by "has an attr object". I'm 
not sure what you mean by "it's not a child or an attribute".

Although the Attr interface inherits from the Node interface, this was a 
matter of convenience in designing the DOM and is a bit misleading. In 
particular, Attrs are not part of the document tree -- all other Nodes are. 
The reason for this is that the attributes of an element are not ordered 
(thus previousSibling and nextSibling are null) and to treat them as 
children of an Element node would be incorrect (thus parentNode is null).

Does that answer your question?

> 2.  NamedNodeMap - What do you mean by a map?

It means that any object implementing the NamedNodeMap interface can map a 
name to a Node. Think of it as a hash table of Nodes, keyed by node name.

> 3.  How does dom handle namespaces?  How do you check for foo:bar?
> (Given that foo is just shorthand for a longer id)

Currently, it doesn't, so how namespaces are handled is implementation 
specific.

If the implementation doesn't handle namespaces at all, the name of an 
element or attribute node will be the prefixed name found in the XML 
document.

If the implementation does handle namespaces, then there are 
implementation-specific functions for getting one or more of the following: 
the prefix, the namespace URI, the unprefixed name, the prefixed name, and 
the URI-qualified name. Thus, if you want namespace-aware code to work with 
more than one DOM implementation, you'll need to encapsulate this behavior. 
(I haven't checked what Node.getNodeName() returns in namespace-aware 
implementations, but I wouldn't be surprised if it was the unprefixed 
element/attribute name.)

Furthermore, no DOM implementation that I know of allows you to set any of 
this stuff on a node, so building DOM trees that use namespaces is out for 
the moment. The best you can do is construct nodes with prefixed names and 
add xmlns attributes as necessary. The result will not be useable by an 
application that is expecting unprefixed names or to be able to use the 
implementation-specific namespace functions. However, it can be serialized 
as a namespacing-using XML document.

As far as I know, the following Java DOM implementations support 
namespaces: Data Channel (MS), Oracle, IBM, and Sun. The version of OpenXML 
that I have does not, but they are planning on adding support. Docuverse 
also does not -- they are waiting for a standard solution.

-- Ron Bourret

Received on Friday, 9 July 1999 11:28:55 UTC