Re: XML decryption transform number 13

Frankly, I'm not sure how the text in [1] actually helps implementors. What 
does "copying" nodes from node-sets X and Y to node-set Z mean -- aren't 
X's and Y's nodes in different underlying documents? It seems that what 
we're trying to do is help implementors fix up the resulting XML document, 
using language that remains consistent with the XPath data model. This may 
be a futile effort.

Ari Kermaier


>This is a difficult issue to mediate. Ultimately, whether this level of
>abstract specification is acceptable is if other implementors are able to
>implement the algorithm in an interoperable way. Aleksey and Jiandong, how
>do you feel. Do you think the text as described in [1] is adequate?
>
>On Sunday 16 June 2002 11:45 pm, Takeshi Imamura wrote:
> > 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.
>
>Takeshi, could you then indicate which specific text you would like to see
>in place of my text in 4.3.2?
>
>[1]
>http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/#sec-Decrypt-Replace-Imp

Received on Tuesday, 18 June 2002 11:35:28 UTC