Re: [xml] Fwd: Patch: Null prefix namespaces not cloned

[Kasimier Buchcik <K Buchcik 4commerce de>]

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