Re: Why is Except limited to local fragments?

On Friday 08 March 2002 03:03, Takeshi Imamura wrote:
> I basically agree on this, but I think we should state such a restriction
> on X in Section 2.1.2.  I tried to make some tweak to Section 2, which is
> attached below.  Could you check if I misunderstand anything?
> (See attached file: 20020308.html)

Looks good, now in the editors' draft [1]. My two questions:

1. Do we even need to talk about Z? According to decryptIncludedNodes, Z is 
always a nodeset, but it's not even mentioned in the "if XML" in step 2, 
and it is mention in the "if octets" in step 3.
2. I'm a little confused by this wording, "If an xenc:EncryptedData element 
node being decrypted is the first node in X, the value of its Type 
attribute MUST NOT be  xenc;Content. Otherwise, the value MUST be  
xenc;Element or  xenc;Content."

Can we be confident that we have the ordering of the nodes in X?

Perhaps we should give a little motivation (to help me and eventually 
others understand). Perhaps,

If an xenc:EncryptedData element node being decrypted is the first node in 
X, the value of its Type attribute MUST NOT be  xenc;Content. This prevents 
an ill-formed XML document with element content appearing at the start of 
the document. If the xenc:EncryptedData is not the first node in X, the 
value MUST be  xenc;Element or  xenc;Content. This prevents binary data 
from appearing out of place in an XML document. 

??

-- 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Friday, 8 March 2002 13:22:50 UTC