RE: [xml-dev] Interoperability [long]

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

> -----Original Message-----
> From: David Brownell [mailto:david-b@pacbell.net]
> Sent: Thursday, November 15, 2001 6:36 PM
> To: Champion, Mike; xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Interoperability [long]
> 

> 
> Huh?  The DOM spec preserves both.  I don't follow.  Since it
> preserves both, what's the problem?  Implementation bugs?

Hmmm ... I wonder if I'm confused myself, and sorry for relying on my
failing memory.... let's go back to the Level 2 Core spec and perform some
hermeneutics:

"As far as the DOM is concerned, special attributes used for
declaring XML namespaces are still exposed and can be manipulated just
like any other attribute. However, nodes are permanently bound to
namespace URIs as they get created. Consequently, moving a node within a
document,
using the DOM, in no case results in a change of its namespace
prefix or namespace URI."

I interpreted that as meaning that the DOM implementation doesn't do any
"magic" to fix up the namespace when it is moved.  Maybe I've confused the
final spec with earlier WG discussions ...at any rate, this may or may not
be what you expect when moving a <p> element from an HTML default namespace
to a FOO default namespace.  All I'm trying to do is warn people that they
may have a perfectly sensible vision of how this works that is not in accord
with the perfectly sensible vision specified in the DOM, so be very very
careful. It is not at all obvious how this SHOULD work, and DOM and XPath
took different approaches.  It's a shame that the W3C didn't knock some
heads together to make sure this didn't happen ... whoever is to blame (Tom
Bradford probably thinks I am!), it didn't happen.


"Similarly, creating a node with a namespace prefix and namespace URI, or
changing the namespace prefix of a node, does not result in any addition,
removal, or
modification of any special attributes for declaring the
appropriate XML namespaces. Namespace validation is not enforced;
the DOM application is responsible." 

So, creating an element with a namespace argument does not cause any
automatic addition of a namespace declaration/prefix. The "DOM application
is responsible" is what I consider the operative phrase here.  The DOM gives
you the tools with which to do the right thing, but the application
programmer, not the DOM implementation, has to actually make sure that
declarations, prefixes, etc. are in the tree where they should be.

"In particular, since the mapping between prefixes and namespace URIs is not
enforced, in general, the resulting document cannot be serialized naively.
For example, applications may have to declare every namespace in use
when serializing a document. DOM Level 2 doesn't perform any URI
normalization or
canonicalization. The URIs given to the DOM are assumed to be valid (e.g.,
characters such as whitespaces are properly escaped), and no
lexical checking is performed."

Level 3 *does* have a super-duper-cleanup-after-namespaces normalization
method, FWIW, and an published algorithm to do this.  

"Absolute URI references are treated as strings and compared
literally. How relative namespace URI references are treated is undefined.
To ensure interoperability only absolute namespace URI references (i.e., URI
references beginning with a scheme name and a colon) should be used. Note
that because the DOM does no lexical checking, the empty string will be
treated as a
real namespace URI in DOM Level 2 methods. Applications must use
the value null as the namespaceURI parameter for methods if they wish to
have no namespace."

Ooops, I got NULL and empty string mixed up again ... slap my wrist!!
Anyway, the point is that you can use the DOM to create invalid namespace
URIs, and the DOM implementation is not obligated to slap YOUR wrist when
that happens.

>"writing XML from DOM is
> out of scope" whenever I raised similar issues.  That's why 
> it's rather important not to put such things prematurely out of scope ...
:)

Sigh.  No argument there ... but did the world want to wait another year or
two for Level 2 while we figured this all out?  [well, some would say "yes"
...]  As I recall, we figured: "An application *can* do the right thing with
the DOM Level 2 API if the author really understands the namespace spec. It
will be hard for an implementation to somehow figure out how to do the right
thing, and time consuming to specify an API that lets the user cleanly
specify their intent without understanding the details of the namespace
rules, so this is Good Enough for Level 2."  Anyway, the serialization
issues are addressed in Level 3.