On Thursday 02 May 2002 13:22, merlin wrote:
> I prefer #2 as well; I think perhaps some of the problems of
> same-document references are simply insoluble, and we should
> probably provide a statement to that effect.
This can be a very complex issue. Yesterday, I asked questions akin to this
more generically [a], and if you want to get a sense of how tricky some of
these insertion/deletion operations can get, have a look at [1]. The "XPath
caveat" arose when I was asking similar questions ("why are we doing all
those odd steps when we could just manipulate the nodes?"). However, I
think if we can do those steps well, that is the right approach.
[1] http://lists.w3.org/Archives/Public/www-tag/2002May/0001.html
From: Joseph Reagle <reagle@w3.org>
To: w3c-xml-cg@w3.org
Date: Wed, 1 May 2002 15:52:03 -0400
Cc: plh@w3.org, www-tag@w3.org
Message-Id: <20020501195203.D3306859F4@aeon.w3.org>
Subject: Attaching/Detaching XML Who is Addressing these issues?
During the past month as we prepared to advance xml-encryption and exc-c14n
we encountered a number of questions that I haven't yet found an answer I
understand, and I'm wondering if folks think they have already been, or do
need to be answered, and if so, who should answer them? These questions
relate to the attachment/detachment of XML from other XML. One can think of
the addition and detachment of SOAP bodies as the example scenario.
1. If I place an element within a target instance with differing xml:base,
xml:lang or xml:space attributes, how do I "reset" the value of these
attribute to "nul". In some instances, I might be able to set them to a
specific value appropriate to their instance; however if the original
external XML had no values, it would be wrong for them to have a new value.
2. If I need to decorate the (formerly external) root element with xml:
attributes in order to counter those of its new ancestor, it's schema might
not permit these attributes. (Signature and Encryption don't.) Should we
recommend that all root elements in W3C specs permit these elements for
such cases?
3. XInclude gives a good idea about what one must do when when inserts
included infosets into the source (target) infoset. How do you detach the
included infoset. Which infoset items are "fixed up" on removal?
4. In the XInclude case, if I have a fragment identifier in an included
infoset that identifies an element in that included infoset, and I then
include the included infoset in the source infoset to get the result
infoset, I believe IDREFs don't point to the original included Infoset, nor
the resulting infoset. What if I want them to point to those that were also
ported along and also now live in the result infoset? Also, I believe a
consequence of XInclude is that it's Infoset will be quite different than
what would think it is based on the serialized instance. (For example, if
there' s ID collision, "the same [normalized value] may have different
values for their [references] properties." [1]) This would be rather
counter-intuitive when one considers it's serialized (c14n'ized) form...?
How would on serialize it? (I expect the XInclude spec is consistent on
this bit, and I'm just confused...) Should we recommending that packaging
applications (like SOAP) should not rely upon such "cross infoset" IDREFs?
(I wonder if HREFs/URIs have similar problems...?)
[0] "For each token in the [normalized value] property, the [references]
property contains an element information item with the same properties as
the first element information item in the result infoset with an attribute
with [attribute type] ID and [normalized value] equal to the token."
[1] http://www.w3.org/TR/xinclude/#references-property