- From: Joseph Reagle <reagle@w3.org>
- Date: Wed, 29 May 2002 17:02:36 -0400
- To: merlin <merlin@baltimore.ie>
- Cc: "Takeshi Imamura" <IMAMU@jp.ibm.com>, xml-encryption@w3.org
On Wednesday 29 May 2002 04:06 pm, merlin wrote: > Right, but if you are constructing an XPointer then the > dummy node still exists from an XPath-processing perspective > so if you wish to write full XPointer exceptions, the form > #xpointer(/dummy/Blah) will be needed. I think this is a > rare and documentable case. Ok, apologies for my brain block on the iteration, step 4 is very clear. > It is, as I say, contrived. The inner Data element containing > arbitrary data is first encrypted (EncryptedData#2). Then > EncryptedData#1 is generated and its ciphertext is put in a > new Data element that happens to have the same Id as the one > that is now encrypted. So there never was an invalid document. > Now, run this through the decryption transform as currently > specified and the behaviour is indeterminate. Would doing something as simple as saying "select the first e in document order" for each iteration solve this problem?
Received on Wednesday, 29 May 2002 17:03:50 UTC