Re: Decryption Transform processing question

On Wednesday 17 July 2002 04:12 am, Takeshi Imamura wrote:
> This text is good to me, too.  As for serialization, I don't think that
> we have to specify any serialization algorithm.  This means that whatever
> algorithm an implementation assumes, it should be compliant with this
> section.

Ok, [1] now includes the text. I'd still like to include some simple 
rationale as to why this is done/necessary: "(e.g., serialization and 
reparsing ensures all nodes correspond to the same document)". I'm not sure 
if that's your rationale so I welcome suggestions. 

[1] http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/
$Revision: 1.220 $

> >> I agree that greater detail would aid interoperability; however, I'm
> >> not sure how to express the details. How about:
> >>
> >>   4.3.2 A Decrypt and Replace Implementation (Non-normative)
> >>
> >>   Where X is the [XPath] node set corresponding to an XML document
> >>   and e is an EncryptedData element node in X.
> >>
> >>      1.  Decrypt e in the context of its parent node as specified in
> >> the Decryption Implementation (section 4.3.1) yielding Y, an [XPath]
> >> node set.
> >>      2.  Include Y in place of e and its descendants in X.
> >>
> >>   The actual implementation of step 2 is outside the scope of this
> >>   document; however, the result MUST be equivalent to replacing e with
> >>   the octet stream resulting from its decryption in the serialized
> >> form of X and reparsing the document.
> >>
> >> I'm not so keen on the old 'Z' text because we're specifying
> >> a function that has the express purpose of mutating X, not
> >> returning a new node set.
> >
> >That's fine with me, my question then is with respect to this
>
> serialization,
>
> >do you care *how* it is serialized? (Is this necessarily Canonical XML?)
>