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



Quoting Daniel Veillard <veillard redhat com>:

On Tue, Feb 21, 2006 at 12:53:32PM +1300, Andrew Miller wrote:
Quoting Daniel Veillard <veillard redhat com>:
I don't understand the patch especially the node->doc != doc test, please
elaborate, thanks !

The first check tests for cases where it doesn't make sense to search for
the
namespace, and sets the ns to NULL in those cases. If the prefix is NULL,
it is
clearly not sensible to search for a match by prefix(remember namespace is
defined if we get to that code). The document equality check is there
because
prefixes from one document don't make sense in another document.

   Hum, that copy operation try to preserve the prefix as far as I remember,
you are not changing that, aren't you ?

I agree it might be worth trying the prefix, and then performing an
equality test on the namespaceURI, and only setting ns to NULL if they don't
match. That way, we avoid creating two entries with the same prefix and
namespace where we only need one.

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

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.


I added the root->parent->type == XML_ELEMENT_NODE check into the while
loop
because xmlNewNs seems to want an element, and otherwise we traverse past
the
document element and get the document.

   Okay that makes sense.

Daniel

Best regards,
Andrew Miller


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Attachment: libxml2-prefixfix.patch
Description: Text Data



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