Re: [xml] redicting parts of trees


Von: cazic gmx net
Datum: Sun, 15 May 2005 20:35:47 +0200 (MEST)
Von: cazic gmx net
Datum: Sun, 15 May 2005 14:37:00 +0200 (MEST)
Von: Daniel Veillard <veillard redhat com>
Datum: Sun, 15 May 2005 06:53:34 -0400

On Sun, May 15, 2005 at 12:59:54AM +0200, Martijn Faassen wrote:



  Hum, the DOM3 function doesn't help us much either from a namespace
point of
view, it only gives a Document target, not a node target, so
fixup can't be done with just that API. Well smart namespaces fixups
be done, but there is still the possibility of adding all inscope
on the node being adopted. Maybe the principle of least surprise rules
and it's better to make a more generic (in the sense you can then put
node anywhere in the document) and more standard API like that one.

We are in need of an adopting mechanism for our Delphi DOM wrapper as
I started an initial non-recursive implementation on the C side, for I
that doing this you will less object a candy I want to add to it, which
wanted to have for a long time.


Maybe we should think about an option to the standard behaviour as well:

- Safe method: reconciliate namespaces (with the brach-top
  as the anchor for new namespaces) at time of adopting;
  - this would not be supported for single attribute nodes
  - this could lead to many redundant namespace declarations

- Unsafe method: don't reconciliate; the user will manually reconciliate
  after he inserts the node

Another possibility for the "unsafe" version would be to reactivate the
"oldNs" field of xmlDoc to anchor the not-in-scope namespace declarations
temporarily. This, together with a reconciliation prior to intersion,
avoid creation of possibly redundant declarations and stale references.
this is seen from a DOM wrapper perspective, where there's always a
available to anchor such things; so, maybe, the function should get a name
that clearly identifies it as being targeted for wrapper implementations.

I attached a first sketch for an adopt function. It tries the "oldNs"
approach. It does not unlink the brach yet; I don't know if it should, or
rather expect the branch to be unlinked already. The function is not tested,
so just comments on its semantics please ;-)

I have the feeling that someone might object an addition to the code-base,
which clearly leaves room for handling namespaces differently. So maybe this
all ends up in a intermediate C layer for me; there won't be room for a "DOM
wrapper helper" C file, will it?



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