Re: [xml] redicting parts of trees

[Kasimier Buchcik <kbuchcik 4commerce de>]

Hi,

On Thu, 2005-05-19 at 15:40 -0400, Rob Richards wrote:
> Kasimier Buchcik wrote:
>
> > Re-creating ns-declarations for every stale reference, yes. As far as I
> > understood it well, Daniel wanted to have the reconciliation being
> > performed on-the-fly. If we decide to go xmlReconciliateNs's way, then
> > we can get rid of that code part and call xmlReconciliateNs; although
> > that will we 2 tree traversals then.
> >  
> Right really wasnt thinking of the element adoption in my response so 
> had just thrown that out there.
> On-the-fly would be best if possible.

OK.

> > > For attributes, wouldn't these be considered as being in document scope? 
> > > So the namespace could be declared on the document element and things 
> > > reconciled if/when it gets appended to an element. If the document 
> > > doesnt have a document element then issue error.
> > >    
> >
> > Yes, we could do it this way as well, although, to me it seems a bit to
> > unpredictable to fail if there's no document-element, and not otherwise.
> >
> > The mechanism would be the same as declare it on "oldNs" of the
> > document, the _only_ difference being that it would end up in the
> > serialized result; should we not consider auto-adding as less
> > ns-declarations as possible?
> >  
> >
> > I's not about declaring, not about _storing_. It could be _stored_ on

Corrections, this should read: "I's not about declaring, it's about
_storing_".

> > the attribute itself if there was a field for it; as it could be
> > stored an the xmlDoc as well.
> >  
> basically was referring to the same thing. Dont think doing anything 
> like this to a fragment is a good idea.

Yeah, seems not safe, since frag->nsDef would be used, which is normally
untouched and could be incorrectly be handled by existing code, which
does not check for the type of node.

> Thinking about this more, I tend to start leaning towards no lone 
> Attribute adoption and issuing an error for this case. The 
> implementation of handling lone attributes with namespaces is going to 
> vary. To make use of this new adopt function could result in a lot of 
> code re-write, while writing custom code for adopting a single attribute 

OK. We could leave the attributes out as not supported.

> is not that much work. In terms of DOM, handling the namespace will be 
> similar to how it implemented its createAttributeNS method.

If you handle it as Element.createAttributeNS then it should not demand
a ns-declaration to be in scope while not serialized. Just for my
interest: how do you handle the references to ns-declarations here?

> For a fragment, store it directly on the elements. Attributes directly 
> are not valid for fragments so no problem there. I'd rather have the 
> serialized document be more verbose (i.e. possibly redundant namespaces) 
> and safe - as it doesnt break anything and works in all cases - than 
> having to try to juggle them all when finally appending the adopted 

OK. But it's really not juggling, if you declare the missing ns, then
you don't do anything other as when you store it internally on whatever
struct, you just make it visible to serialization _earlier_ and probably
at a _redundant_ position.

Let me show a scenario - wrappers view, so without a given @parent:
  - adopt some nodes with:
      @node == <foo><b:bar/><foo/>, with b bound to "urn:test:foo"

  - for every @node we will get:
      <foo xmlns:b="urn:test:foo"><b:bar/><foo/>

  - if added to the destination tree it could look like this.
    <dest xmlns:b="urn:test:foo">
      <foo xmlns:b="urn:test:foo"><b:bar/><foo/>
      <foo xmlns:b="urn:test:foo"><b:bar/><foo/>
      <foo xmlns:b="urn:test:foo"><b:bar/><foo/>
    </dest>

  - if added to the tree you normally have to call xmlReconciliateNs(),
    since you don't know if the added node was just removed from the
    same document, or comes from an import. Or your implementation
    always call xmlReconciliateNs immediately after removal of nodes,
    which creates the same redundant declarations.    

So although the prefix was defined in the destination tree, which will
be the common case in my opinion, you accept such an amount of redundant
ns-declarations? Imagine there's 1000 of them, or more?

On the other side, if the missing declaration xmlns:b="urn:test:foo" was
stored internally _somewhere_ instead, we would get:

  - adopt some nodes with:
      @node == <foo><b:bar/><foo/>, with b bound to "urn:test:foo"

  - for every @node we will get:
      <foo><b:bar/><foo/>
      and a xmlns:b="urn:test:foo" stored internally on the document

  - if added to the destination tree it could look like this.
    <dest xmlns:b="urn:test:foo">
      <foo><b:bar/><foo/>
      <foo><b:bar/><foo/>
      <foo><b:bar/><foo/>
    </dest>

    With bar->ns still referencing the stored xmlNs struct.

  - if added to the tree a xmlReconciliateNs would attach bar->ns to
    dest->nsDef, avoiding redundant declarations.

So quite some less declarations.

Don't take me wrong, I don't want to push you to any other decision,
since I'm not using PHP and our implementation is not dependant on 
this mechanism. I just want to point out, what it is, that you are
accepting with this mechanism.

> subtree. This would then at least be inline with using xmlNewNs which 
> would probably the way most DOM implementations use in their 
> createElementNS method. Makes appending the nodes much easier rather 

xmlNewNs creates a namespace declaration attribute in the DOM point of
view. Node.createElementNS is _not_ dependant on any existing
namespace declaration attribute in the document. You could add a zillion
of elements bound to different namespace, without adding a single
ns-declaration. The namespace serialization mechanism of the DOM
would create them for you prior to serialization.
The Node.namespaceURI() and Node.prefix() are totally disconnected from
any ns-declaration. This is why DOM's normalization mechanism works at
all and cannot be implemented with Libxml2 without massive complexity,
which would extend even the function sketch I provided.

> than having to guess how the element was created to figure out if 
> anything special needs to be done to handle their namespaces.

What do you do you really do currently to handle their namespaces,
besides calling xmlReconciliateNs, which would be called with
the new mechanism as well?

> Worst case for an element, if the xmlReconciliateNs semantics of 
> handling namespaces is not used, is to allow an an argument to disable 
> all namespace handling so that  xmlReconciliateNs can just be called 
> after its done.

OK. If normalizing in different ways we will give total control of
how.

Thanks! :-)

Is slowly boils down to using just the xmlReconciliateNs mechanism
to declare all missing ns-declarations on the given node, as Daniel
first suggested - although you have been warned ;-)

Regards,

Kasimier