Re: Decryption Transform processing question

>My original intent was to give an example with xpointer-based
>relative URIs; #xpointer(here()/....). This will work for
>single-phase processing but will fail for iterative
>processing unless we serialize and parse X before we
>do anything (in which case here() is meaningless and
>XPointer will always be interpreted consistently although
>bizarrely; that dummy element will exist as far as XPointer
>is concerned).
>
>With single-phase processing we don't need that change
>in the interpretation of same-document references and
>XPointers will not be interpreted in the context of a
>dummy element.

I probably understand what you say about XPointers, I don't still
understand the relation between single-phase processing and unnecessity to
change interpretation of same-document references.  If a signature is of
type detached, we have to change the interpretation anyway.

>Also, the parsing model that we specify (from XML signature)
>is explicitly non-validating, and there is no DTD, so
>ID resolution in the new document will not be consistent.

Except is an element for referencing an EncryptedData element with the Id
attribute, so I think that there is no problem even if a DTD is not given.

>Is iterative decryption useful?

I believe so.  Even if it does not seem useful, I don't think that we
should preclude any possibility.

>I think we have a choice between iterative decryption and
>XPointer-based exceptions. If we choose iterative decryption
>and XPointers, then we must start with a serialize/wrap/parse
>step so that XPointers are interpreted consistently, and
>we must note that #xpointer(/*) will resolve to a dummy
>element.
>
>Regardless, we should probably provide a note that the output
>node set tree will actually be rooted by an absent dummy
>element. This will be important for subsequent XPath transforms.

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

Received on Friday, 3 May 2002 04:34:00 UTC