Re: Why is Except limited to local fragments?

On Wednesday 06 March 2002 16:31, merlin wrote:
> It might be prudent to require that, if an enc:EncryptedData is present
> with a non-XML Type attribute, then it must be the (sole root element of
> the input | only enc:EncryptedData in the input). Otherwise, operation
> is ambiguous; we don't define an order for performing decryptions,
> and the current language will return the data from the first non-XML
> ciphertext processed.

I'm not sure what you mean by "operation is ambiguous" and "don't define an 
order for performing decryptions." I think I understand your point: it's 
difficult to envision someone having:
<foo>
  <EncryptedData MimeType="msword"/>
  <EncryptedData MimeType="png"/>
</foo>

but there might be one... and then with respect to the "only 
encEncryptedData in the input", I think the input could have more than one 
EncryptedData, but that input less those excepted would have to be equal to 
one?

> Also, text that I'd suggest adding about the Except URI would be along
> the lines of:
>
> When dereferencing Except URIs, the application MUST behave as if the
> root document node of the input node set is used to initialize the
> XPointer evaluation context, even if this node is not part of the node
> set. Unlike XML-Signature, the URI may be evaluated against a different
> document from the signature document. If the input is a different
> document then, as per the XPointer spec, use of the here() function is an
> error.

Ok:

http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt.html#processing
$Revision: 1.32 $ 


-- 

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/