W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2002

Re: New XPath Filter Transform

From: merlin <merlin@baltimore.ie>
Date: Fri, 08 Mar 2002 17:24:55 +0000
To: "John Boyer" <JBoyer@pureedge.com>
Cc: reagle@w3.org, "TAMURA Kent" <kent@trl.ibm.co.jp>, w3c-ietf-xmldsig@w3.org
Message-Id: <20020308172455.28D504422C@yog-sothoth.ie.baltimore.com>

Hi John,

I read the context part, and I think it is correct; I just misunderstood
the application of the resulting subtrees. I think that include should
be specified as set intersection, as exclude is set subtraction. Set
replacement would, I think, be non-intuitive and, in my opinion, bad.
We can get set replacement behaviour using set intersection and an input
nodeset from URI #xpointer(/).

It would seem that the current exclude behaviour honours preceding URIs
and transforms, whereas the current include behaviour ignores them. I
don't like the dichotomy.


>Hi Merlin and Kent,
>Merlin's response actually doesn't match the spec as currently written.
>The result can have any nodes from the input document, and yes, Kent, the inpu
>t is immaterial except for giving us a way to obtain a document root node.
>Please see the first paragraph of Section 3.3 "Input and Evaluation Context of
> Signature Filter Transform":
>"...The XPath evaluation context for the node-set will be:
>A context node equal to the root node of the document whose node-set was provi
>ded as input to this transform..."
>John Boyer, Ph.D.
>Senior Product Architect
>PureEdge Solutions Inc.
>-----Original Message-----
>From: merlin [mailto:merlin@baltimore.ie]
>Sent: Friday, March 08, 2002 8:45 AM
>To: reagle@w3.org
>Cc: TAMURA Kent; w3c-ietf-xmldsig@w3.org; John Boyer
>Subject: Re: New XPath Filter Transform 
>I believe that "include" is set intersection of the input
>node set with the xpath-selected regions; "exclude" is set
>subtraction. So, no; the resultant node set cannot contain
>a node which is not contained in the input node set.
>>I'll defer your question to John but apoligize that I didn't publish the 
>>editorially tweaked version (with some renaming, schema, and namespace). 
>>The latest version is at:
>>  http://www.w3.org/Signature/Drafts/xmldsig-xpath/
>>On Thursday 07 March 2002 00:29, TAMURA Kent wrote:
>>> In message "New XPath Filter Transform"
>>>     on 02/02/07, Joseph Reagle <reagle@w3.org> writes:
>>> > Thoughts? (On these syntax issues, or implementation performance)
>>> >
>>> > [1] http://www.w3.org/Signature/Drafts/xmldsig-transform-xpath.html
>>> Does this transform ignore the input nodeset except the root
>>> node?  Does a resultant nodeset contain a node which is not
>>> contained in the input nodeset but it is selected by
>>> SignatureFilter XPath expression?
>>Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
>>W3C Policy Analyst                mailto:reagle@w3.org
>>IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
>>W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
>Baltimore Technologies plc will not be liable for direct,  special,  indirect 
>or consequential  damages  arising  from  alteration of  the contents of this
>message by a third party or as a result of any virus being passed on.
>This footnote confirms that this email message has been swept by
>Baltimore MIMEsweeper for Content Security threats, including
>computer viruses.
>   http://www.baltimore.com
Received on Friday, 8 March 2002 12:25:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:37 UTC