Re: [xml] redicting parts of trees


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

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"

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 

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



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