Cart
[Home] [By Thread] [By Date] [Recent Entries]
> - 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. Huh? The DOM spec preserves both. I don't follow. Since it preserves both, what's the problem? Implementation bugs? > - 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. Yeah, but I remember constantly getting "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 ... :) > - 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 .... Now I'm totally confused. Since when is that true? DOM nodes must be created with namesepaces, which stick to them like glue. Moving a node around doesn't change the namespace URI, or add one. There was a discussion when DOM first got namespace support, and I seem to recall one vendor insisting on that "early binding" approach rather than matching the "late binding" approach that'd match XML text better ... - Dave
|
