Re: [xml] redicting parts of trees

[Kasimier Buchcik <kbuchcik 4commerce de>]

Hi,

On Thu, 2005-05-19 at 12:43 -0400, Rob Richards wrote:
> Kasimier Buchcik wrote:
>
> > 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.
> >  
> To make sure I am following this correctly as these messages are getting 
> damn long:
> The problem is what to do if node is not an element and no parent is 
> passed in, correct?

Yes, plus, if, and where we should and re-create ns-declarations for
stale ns-references.

> For an element, xmlReconciliateNs can be used after its set to the new 
> document.

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.

> 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?

> For fragments, the process should be done the same way. The namespace 
> CANT be declared on the fragment node.

I's not about declaring, not about _storing_. It could be _stored_ on
the attribute itself if there was a field for it; as it could be
stored an the xmlDoc as well.

> > 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.
> >  
> I agree about breaking it up too, though not sure what you mean about 
> forking. It is only going to get more complex as it still needs to 
> handle the entity refs, IDs, etc..

Well, it gets as complex as it needs to be. Currently we have not come
to a conclusion which namespace-way to go, so the code might get more
simple if we remove options or decide to go a more simple way. The
result should not be affected by a "too-complex" argument (personally
I don't understand why you call it complex).

With "forking" I meant: just create a specialized function for simple
cases, which could either be exposed to the API as well or called from
the main adopt-function.

Thanks for the comments! It's good not to have to decide those things
alone!

Regards,

Kasimier