Re: Decryption Transform processing question

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

Received on Thursday, 2 May 2002 15:19:13 UTC