Re: New Version of XPath Filter

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.

Merlin

r/[email protected]/2002.04.08/09:52:50
>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
>instead.
>
>    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
>include
>    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
>new
>    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
>application
>    suppose to keep original document in memory or the transform simply fails?
>
>
>Aleksey Sanin <[email protected]>
>http://www.aleksey.com/xmlsec
>
>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.
   http://www.baltimore.com