Re: [xml] redicting parts of trees

[Kasimier Buchcik <kbuchcik 4commerce de>]

Hi,

On Thu, 2005-05-19 at 09:03 -0400, Daniel Veillard wrote:
> On Thu, May 19, 2005 at 01:27:22PM +0200, Kasimier Buchcik wrote:
> > Hi,
> >
> > On Mon, 2005-05-16 at 18:12 +0200, cazic gmx net wrote:
> > > Hi,
> >
> > Time for a next step.
> > I attached the current sketch of an adopting mechanism. It's not
> > tested - just compiles.
>
>   didn't reviewed the code yet. Just a first step.
>
> > If an appropriate ns-decl was not found, it will declare a new namespace
> > on:
> >
> >   - if @parent != NULL, and @parent has an element node in the
> >     ancestor-or-self axis, then on @parent's top-most element node.
> >   - if @parent == NULL, then on the "oldNs" field of the destination
> >     document-node. This is important if @node is an attribute node.
>
>   Hum, that's a problem. oldNs is not serializable, so you would end up
> with document broken when serialized because they use undeclared namespaces.

Yes, this is intended. Some words about it's usage: if @parent is not
given, @node needs to be reconciliated with a yet-to-write corresponding
function, prior to serialisation or linking to a tree. If used by
DOM wrappers, @parent is not given. Think of it as a _safe_ unlink
function, which assures that ns references are not stale.
The already mentioned option to anchor on @node itself, if possible,
could disable the use of "oldNs".

> I undertsnad it works for you special case, but the only reliable behaviour

In my case we will map the ns references to intern wrapper xmlNs
entries. We won't use any of the reconciliation stuff. Anchoring on
"oldNs" is supposed to help wrappers which do not handle ns-references
by themselves.

> is to add it to the node itself if it's an element and raise an error

Hmm, the "only reliable behaviour"... except for the described "oldNs"
mechanism, do you already see any problems with anchoring the ns-decls
on @parents top-element?

> otherwise.  In your special case, just check nsDef of the node before and after
> the operation is done, should be quite simple.

Simple, but not intended. Additionally not correct, since the axis from
the anchor element to the referenced node must not shadow the added
ns-prefix.

With raising an error is this case, adoption wouldn't work on
attribute- and fragment-nodes. Maybe for fragment-nodes we could
anchor the ns-decls on the fragment-node itself.

However, we could add an option to let it work as you describe; although
I don't see the point in writing an adopt function that does not support
single attribute nodes.
Maybe Rob Richards and Martijn Faassen could give some feedback about
the way we should go here - after all I see it as a "help-the-wrapper"
function.

> > - Whether to user @parent's top-most element node as the anchor for new
> > ns-decls, or @node's nearest element node could be set per option as
> > well. It's not in yet.

[...]

>   This is very complex code. Maybe it's unavoidable considering the
> huge amount of work needed at each step. I wonder if splitting the function
> in more digestible chuncks like one for processing Element, one for Attributes
> and the loop wouldn't be easier to maintain.

Yeah might be good, although I'd like to have an optimised version at
the end. We should consider not only splitting the code, but to
fork to different handlers: one if @node is an element or
fragment, one if it's an attribute, and a third otherwise. We need
that complexity only for a branch of element nodes.

Hope you'll find some time to revise the parts in it. Ah, and
have a look at the dict stuff, is it OK now?

Regards,

Kasimier