Cart
[Home] [By Thread] [By Date] [Recent Entries]
> -----Original Message----- > From: David Brownell [mailto:david-b@p...] > Sent: Thursday, November 15, 2001 6:36 PM > To: Champion, Mike; xml-dev@l... > Subject: Re: 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.
|
