On Wed, Feb 22, 2006 at 12:19:33PM +1300, Andrew Miller wrote: > Quoting Daniel Veillard <[EMAIL PROTECTED]>: > > 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 > > that > > > 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 > > right. > 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 -- Daniel Veillard | Red Hat http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
