Re: [xml] namespace declaration problems

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.


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.


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

  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 Veillard      | Red Hat Network
veillard redhat com  | libxml Gnome XML XSLT toolkit | Rpmfind RPM search engine

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