Re: Why is Except limited to local fragments?

>> I basically agree on this, but I think we should state such a
>> on X in Section 2.1.2.  I tried to make some tweak to Section 2, which
>> 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
>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
>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

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

Tokyo Research Laboratory
IBM Research

Received on Monday, 11 March 2002 02:24:18 UTC