Re: "Re: [xml] namespace handling"

[Daniel Veillard <veillard redhat com>]

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.

> 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

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/