W3C home > Mailing lists > Public > xml-encryption@w3.org > September 2002

Re: decrypt transform processing rules

From: Ari Kermaier <arik@phaos.com>
Date: Thu, 26 Sep 2002 11:24:30 -0400
Message-ID: <006e01c26570$d0529210$3401a8c0@phaosarik>
To: "merlin" <merlin@baltimore.ie>
Cc: "W3C XML-ENC WG List" <xml-encryption@w3.org>

----- Original Message -----
From: "merlin" <merlin@baltimore.ie>
To: "Ari Kermaier" <arik@phaos.com>
Cc: "W3C XML-ENC WG List" <xml-encryption@w3.org>
Sent: Thursday, September 26, 2002 10:22 AM
Subject: Re: decrypt transform processing rules

> Hi Ari,
> r/arik@phaos.com/2002.09.24/19:36:37
> >Dear All,
> >
> >It seems to me that it should be possible to eliminate the
> >and re-parsing of the result node-set in the decryptXML(N,E) function as
> >described in [1]. Since the decryptNodeSet(N,E) function already mandates
> >serialize/wrap/parse/unwrap for each replacement node-set, why not
> >the namespace and inherited "xml:" attribute augmentations at that point?
> >Then decryptXML(N,E) could simply replace the EncryptedData elements with
> >their corresponding replacement node-sets and return the result node-set.
> The decryption transform can't actually modify the input
> document; it must return a copy. The easiest way to do this
> is c14n/parse.  An implementer is free to actually do this
> by just copying the input node set (or modifying it, if it is
> known that it is a transient node set) as long as the result
> is the same as if c14n/parse happened.

I see, good point!

Received on Thursday, 26 September 2002 11:26:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:04 UTC