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

On Wed, Feb 22, 2006 at 12:19:33PM +1300, Andrew Miller wrote:
Quoting Daniel Veillard <veillard redhat com>:
On Wed, Feb 22, 2006 at 11:17:30AM +1300, Andrew Miller wrote:
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
we do anything about it.

I have attached an updated patch that adds a function to search by both
namespace and prefix,

  I don't understand why you need a new function. Search by prefix and
then check the result URI it is associated to, assuming the prefix is
in scope. That avoids duplicating code and adding yet another specialized
API, libxml2 already has too many entry points. I didn't understand the point
your new function, which is possible since you copied over the comment from
the existing prefix based search. It's very easy to get wrong with
namespaces, and there can be only one value of the namespace name for the
prefix in scope, so I don't understand how an API based on both can be
Once the document is serialised, this is correct. However, the DOM specification
says quite clearly that the DOM is not supposed to enforce this in memory:

"In particular, since the mapping between prefixes and namespace URIs is not
enforced, in general, the resulting document cannot be serialized naively."

Therefore, you cannot assume that there is only one namespace URI for a given
prefix at any point in time any more than you can assume thay about any other
arbitrary pair of attributes. It is especially common for applications to use
an empty prefix for everything(i.e. more than one namespace) until they are
ready to serialise the document, and only sort out prefixes at this time.

DOM is broken ... Libxml2 don't claim to implement DOM, and I certainly don't
want to promote an API at the libxml2 level which is clearly broken from
an XML Namespace spec point of view.
  Try to find a way to generate a correct document in memory, as libxml2
serialization won't go though the crazy work of trying to reconciliate
a potentially impossible to serialize in-memeory document and would lead
to things like:

   <foo xmlns:bar="bar" xmlns:bar="bar2" bar:att="1" bar2:att="2"/>

no thanks, pushing a broken API on the premise that a very hard work
somewhere else might cope with the inconsistency later on is not acceptable,
sorry ! Sure libxml2 may allow to produce broken documents, but an API
which is clearly in violation of the spec that libxml2 claims conformance to
sounds a really bad idea to me. The library should by default try to avoid
conflicting with the specs it conforms to, if it makes DOM implementations
on top of it harder, I'm sorry about this but the core specs first ...


Daniel Veillard      | Red Hat
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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