[xml] =?ISO-8859-1?Q?=22Re=3A=20=5Bxml=5D=20namespace=20handling=22=27?=


Daniel Veillard wrote:
On Tue, May 13, 2003 at 10:54:26AM +0200, Kasimier Buchcik wrote:

 Was okay with namespaces from 1998, completely useless with current
namespaces which are scope based I'm afraid.

I see. I didn't know that. Such a pity.
Could you clarify the processes that handle scope based namespaces?

  The xmlNsPtr is attached only on the node where it is defined and 
the mapping is in effect only in the subtree. C.f. the Namespace in XML
W3C Recommendation.

 I don't think I'm ready to completely break libxml2 and libxslt code
to handle namespaces in a very different way. It would also impact 
all the APIs which work with xmlNsPtr, really no I don't think it's
an option at this point.

Hmm, I don't know if we mean the same here, since the list on xmlDoc 
still would consist of a xmlNsPtr chain. IOW node->ns would still be a 

  I need to be able to know exactly what subtree the namespace covers
and be able to save the namespace definition at the right place when
serailizing back the tree. The namespace definition must be attached to
the node defining it.

Yes, the namespaces on the tree would have to be normalized, thus 
putting namespace declarations into the tree where needed. This is a 
process equivalent to a reconciliation. This means that we have to 
normalize the tree *only* before serializing, not every time a node is 
attached. This is exactly what I meant.

xmlNsPtr, but the destination would be in the chain on the xmlDoc and 
not somewhere in the tree, where managing namespaces seems to complicate 
things. I wonder what the difference for libxslt would be? So if we 
assume that nothig changes from the view of a "node->ns", what would be 
the main drawbacks?

  It would "just" screw up all the serialization and make impossible
things like
     <b xmlns:n="foo">
     <b xmlns:n="bar">

  Basically it would make libxml non-conformant.

This issue is crucial for us, since we need to perform a lot of work 
with DOM 2, which produces too much namespace declarations by now and is 
slowed down by reconciliation processes.

    1/ don't use DOM2
    2/ if you know that your namespaces decalarations are unique
       and global to the documents, keep them on the root node.

  But asking for a non-conformant behaviour because of "much namespace
declarations" or speed issues due to adoption of an improper interface
does not make sense to me, sorry :-\


I don't think this is non-conformant behaviour. I still see no things 
that would be broken. Please clarify. What exactly would break?


Kasimier Buchcik

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