[xml] "Re: [xml] namespace handling"'

[Kasimier Buchcik <kbuchcik 4commerce de>]

Hi,

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
>   <a>
>      <b xmlns:n="foo">
>         <n:c/>
>      </b>
>      <b xmlns:n="bar">
>         <n:c/>
>      </b>
>   </a>
>
>   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.
>
>
>   Options:
>     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 :-\
>
> Daniel

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

Thanks,

Kasimier Buchcik