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

Re: New Version of XPath Filter

From: merlin <merlin@baltimore.ie>
Date: Mon, 08 Apr 2002 18:38:28 +0100
To: aleksey@aleksey.com
Cc: reagle@w3.org, w3c-ietf-xmldsig@w3.org
Message-Id: <20020408173828.6892443BEA@yog-sothoth.ie.baltimore.com>

Hi Aleksey,

1. Agreed.

2. We choose to perform expansion from nodes to node trees outside
the XPath processor to maximize the possible execution speed. It
is much faster to evaluate and expand //Foo than to evaluate
//Foo//self::node(). Remember, the only goal of this transform is
speed; it doesn't provide any new capability.

3. The transform operates as you'd expect; the external document
is parsed and the filter applied. The only difference is that here()
is an error. This allows us to efficiently select subtrees of 
external documents; e.g., document.xml->intersect(id('foo')),
which selects the data that document.xml#foo would, if we permitted
that construct.


>I have few comments/questions:
>    1) (minor) I spent some time figuring out that the following phrase
>                "and the input node set I"
>    is not the
>                "and the input node set /"
>    (italic 'I' looks similar to slash). I would suggest to use regular font
>    2) May be I missed this discussion, but I do not understand why we need
>    to have S'. Seems to me that if the author of the expression wants to
>    ancesstors then he/she can do it by changing the expression. From my point
>of view,
>    the transform should operate on the plain previous nodes set "I" and the
>    node set "S".
>    3) I did not found any mention about what happens if the transform is
>applied to
>    a document different from the one that has the signature. Does the
>    suppose to keep original document in memory or the transform simply fails?
>Aleksey Sanin <aleksey@aleksey.com>
>Joseph Reagle wrote:
>     Merlin sent me a version of the specification integrated with his
>     proposal
>     [1]. Please comment! ( The only thing I did was tweak some of the
>     formatting, and name it back to XPath Filter 2.0. I find it easier to
>     explain there's the 1.0 version in the spec, and this is the
>     replacement.
>     But perhaps I am alone on this?)
>     [1] http://www.w3.org/Signature/Drafts/xmldsig-xpath/
>     $Revision: 1.6 $ on $Date: 2002/04/08 16:36:58 $

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.
Received on Monday, 8 April 2002 13:38:40 UTC

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