Hi, On Wed, 2006-02-22 at 11:17 +1300, Andrew Miller wrote:
[...] > >From DOM Level 2 Core specification: > "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. 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. 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." Note that Libxml2 - as-it-is - does not work the DOM way, since the xmlNode->ns entries reference xmlNode->nsDef entries (ns declaration attributes) inside the tree. So the ns-URI and ns-prefix is not carried by an element, but only by the ns-decl. One way of making this DOM thingy work is to handling the xmlNode->ns references in a custom way internally in your wrapper. One needs to ensure that no xmlNode->ns points to a xmlNode->nsDef entry in the tree. This includes remapping all xmlNode->ns entries to internal xmlNs entries after parsing the document. This way you can move around your nodes without caring about stale links to xmlNode->nsDef entries. I'm sure your are already aware of this; I just want to point out that the behaviour described above (ns-URI and ns-prefix detached from ns-decls), is still possible; we do this in our wrapper for writeable trees (for read-only trees, there's no need to remap the ns-references). > So I think that the correct behaviour is to search by namespace and prefix > everywhere. If we don't find a match with the same namespace and prefix, we > create a new namespace object(even if there is another entry with the same > prefix or same URI, but not both the same). This means we can have two > identical prefixes with the same URI, and it is only at serialisation time > that > we do anything about it. > > I have attached an updated patch that adds a function to search by both > namespace and prefix, and uses this instead of the document equality check. I > think that there are probably a number of other places we should be using it > as > well, but I don't have the time to go through and fix them all now. I have run > it through my gdome based test program, as well as the libxml2 regression > tests > and the part of the CellML API testsuite I have implemented so far(which is > based on an XML API layered on top of gdome, and uses namespaces in a way > which > hit the bug before). No tests which previously passed have failed. Did you already look at xmlDOMWrapCloneNode() ? It is an initial and unfinished implementation of a cloning/importing mechanism for DOM wrappers. The function is designed to allow custom namespaces-handling, so this could be a place where a solution for your issues could be anchored. Regards, Kasimier _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
