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


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
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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]