RE: [xml-dev] Interoperability [long]

["Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>]

> -----Original Message-----
> From: Ronald Bourret [mailto:rpbourret@rpbourret.com]
> Sent: Thursday, November 15, 2001 5:00 PM
> To: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Interoperability [long]

> . I process DOM trees (which do use multiple namespaces) in a
> similar manner.
> 
> What am I missing here?

The gotchas in DOM/namespace processing, as I recall from about three years
of DOM WG meetings wrestling with this wretched subject are (my
psychological defenses have probably erased some of the more painful
memories, so help me out here ...):

- The DOM WG naively believed a literal reading of the namespace spec and
treats prefixes as mere syntax sugar and URIs as the "real thing".  This
causes problems when interoperating with specs that treat prefixes as being
significant.

- Elements created with a namespace URI may not have a prefix, and you may
have to invent one when you need one, e.g., when serializing.

- The DOM lets you create elements with an invalid namespace URI, partly
because the very notion of "invalid namespace URI" is not well defined, and
partly because requiring continual checks against all the numerous
well-formedness constraints (no "--" in, comments, no illegal Unicode code
combinations in content, etc) would require DOM implementations to be very
slow; the decision was made to perform these checks at normalization or
serialization time).  Anyway, you can create an element in a NULL NS URI,
and that is not NS-well-formed.

- since DOM nodes don't intrinsically know their namespace (unlike XPath
nodes, as I understand it), the namespace of a node when moved around in the
tree may change in undesireable ways unless you take lots of care to make
sure that it is in the same namespace scope in the source and target
locations, or that you *intended* to make that HTML <p> element a <p>
element in the "foo" namespace ....

- Mixing nodes created with Level 1 namespace-blissfully-ignorant methods
and Level 2 namespace-aware methods can lead to undefined and
non-interoperable scenarios.  The DOM Level 2 spec says, translated into
suitable W3C-ese, "there be dragons, abandon all hope ye who venture there."

Basically, the namespace spec provides a lot of handy rigging in a read-only
environment, but you'll find that you have more than enough rope to hang
yourself once you start creating elements in non-declared namespaces or
moving elements between namespaces with the DOM.  St. George himself
couldn't rescue you if you muck around with namespaces and entities
simultaneously ...