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


-- 
*Note: I will be attending the W3C AC and WWW2002 meetings from 
May 5-10, and taking holiday from 13-16. I will not be as responsive 
during the former period, and off-line during the latter. I will fully 
respond to any email as soon as possible  after my return.

Received on Wednesday, 1 May 2002 15:52:38 UTC