Re: [xml] namespace declaration problems

[Daniel Veillard <veillard redhat com>]

On Mon, Mar 11, 2002 at 02:49:35PM +0100, Uwe Fechner wrote:
> Hello Daniel,
>
> we are still struggling with the handling of the lifetime
> of dyn vars of type xmlNsPtr. (structs, that hold a namespace)
>
> > struct xmlNs {
> >     struct _xmlNs  *next;   /* next Ns link for this node  */
> >     xmlNsType      type;    /* global or local */
> >     const xmlChar *href;    /* URL for the namespace */
> >     const xmlChar *prefix;  /* prefix for the namespace */
> > };
>
> > An XML namespace. Note that prefix == NULL is valid, it defines the
> > default namespace within the subtree (until overridden).
>
> Variables of this type can be created with xmlNewNs:
>
> > xmlNsPtr xmlNewNs    (xmlNodePtr node,
> >                       const xmlChar *href,
> >                       const xmlChar *prefix);
>
> but I think, that they are also created automatically by parsing
> an xml-file, that containes namespaces, and by cloning nodes with
> the param deep.

  yes, like any other kind of libxml node type.

> As far as I understand, they are freed automatically if you free
> a document and there is a reference to an xmlNs on one of the 
> nsdecl-lists of an element.

  in the nsDecl field of an element, yes

> If all these assumptions are true, that I have to keep a list 
> of the vars of type xmlNsPtr, that are used in orphan nodes, that
> are not included in any document tree, and free them manually 
> with xmlFreeNs at the end.

  Okay to be extremely clear:
    xmlNsPtr is a XML Namespace *Declaration* node.
    it is the internal representation of an xmlns= or xmlns:xxx= attribute
    Each element keep the list of namespace declaration nodes *declared*
    on that node as the nsDecl list.
    All the elements or attributes using that namespace declaration
    must be per the XML Namespace specification logically in the subtree
    of the node declaring that namespace. Those elements have their ns
    field point to that declaration on their ancestor.

> Conclusion:
>
> Life would be much easier for us, if libxml2 would keep a list of
> namespaces for each document

  it does that list is dristributed in the tree at the place where
  the namespaces are declared

> and a list of namespaces, uses by 
> orphan nodes (=document fragments or dangeling nodes).

  There is no notion of orphan node. If you have an node with a namespace
(i.e. the ns field) pointing to an element which is not an ancestor
of that node then, yes you're in trouble and you must control closely
how this is handled. 

> Than it would be possible, to keep the namespaces unique and to free
> them as a group, if you don't need them any longer.

  This does not work. And it's not the way the namespaces nodes are expected
to be handled. If you take a subtree where namespace nodes are declared 
and that subtree have no reference to namespaces outsiide that subtree then
you can safely copy and paste it to another document. 

> Each element node keeps a list of namespace definitions on it, in the
> field nsDef.

  Yes

> What are these entries used for?

  for reference by ancestors of that node in their ns field to indicate 
they pertain to that namespace.

> As far as I know, they are used for generating the namespace declaration
> attributes in the output string, if you export the xml tree to a file.

  That's NOT their main goal.

> Is it important, to keep them up-to-date?

  extremely, yes.

> If it is important, than I don't understand, why xmlAddChild doesn't make
> any entries in the nsdef list of the parent node.

  I don't understand the context of your question.

> Could you add this functionality to xmlAddChild, or would it break existing
> code?

  I don't understand the context of your question.

  You seem to be confused and mixing namespace *declarations* which are like
attributes uniques to a node stored in nsDef and namespace *reference* used
to indicate taht a node (attribute/element) pertains to a given namespace.

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/