Re: Why is Except limited to local fragments?

>> 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.

Sorry, the description of Z, i.e., "Z is a node-set obtained by the
following steps:", is wrong.  It would be something like "Z is a node-set
or octet stream obtained by the following steps:".

>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?

XPath defines the "document order" of nodes and the order is what I
intended.

>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.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com