- From: Takeshi Imamura <IMAMU@jp.ibm.com>
- Date: Mon, 17 Jun 2002 12:45:29 +0900
- To: merlin <merlin@baltimore.ie>
- Cc: reagle@w3.org, xml-encryption@w3.org
Merlin, >>> 2. Copy Y in place of e in Z. >> >>According to XPath's data model, this is not possible because Y and Z are >>yielded from different documents. Merlin's technique, i.e., serializing Y >>and Z and parsing the resultant octet stream, would be needed. > >Hi Takeshi, > >I respectfully disagree with you here, although if you can >refer me to where the XPath document states that this is not >possible, I'll willingly relent. The XPath spec does not state that it is impossible, but it does not also state that it is possible. >Joseph's text implies that you take the document structure and >a node set over it and copy these nodes into another document, >duplicating the structure where possible. I don't see anything >that precludes this; how it is done is left, as it should be, >to the implementor. I understand what Joseph and you intend, but I don't think that it is so easy to describe. That is because the XPath data model does not suppose that any nodes are copied or imported from another document. What does "copy these nodes into another document, duplicating the structure where possible" mean formally? How can it be broken down using the XPath vocabularies? If we define our vocabularies for describing it, it would be OK. However, I'm not sure whether that is worth doing, considering efforts for it. >Are you suggesting that decrypt-and-replace is not possible? If >so, why are you not asking that the entire concept be removed >from the specification? No. It is possible. I'm not concerned about its possibility but its description. >By explicitly leaving this non-normative text vague, as Joseph >does, any given implementation can do what it needs to do. If >it cannot perform this operation, then it does not support >the decrypt-and-replace mode. > >What you suggest; i.e., serialize and parse; does not >correspond to decrypt-and-replace, it corresponds to the >creation of a new document. That's not what we are trying to >specify; we're trying to specify, as abstractly as possible, >how to replace nodes in the original document with a decrypted >node set, without actually mandating any given implementation. Thanks, Takeshi IMAMURA Tokyo Research Laboratory IBM Research imamu@jp.ibm.com
Received on Monday, 17 June 2002 00:52:14 UTC