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

RE: New Version of XPath Filter

From: John Boyer <JBoyer@PureEdge.com>
Date: Mon, 8 Apr 2002 10:46:20 -0700
Message-ID: <7874BFCCD289A645B5CE3935769F0B52328544@tigger.PureEdge.com>
To: "merlin" <merlin@baltimore.ie>, <aleksey@aleksey.com>
Cc: <reagle@w3.org>, <w3c-ietf-xmldsig@w3.org>


Hi Merlin and all,

Instead of italics, we could keep the same letters and use bold,
possibly with a soft color.  The main idea would be that 'I' is read as
a set name, not a word referring to me.

As for the actual new draft, I just finished a complete read and could
find no errors. Excellent attention to all the details. This probably
sounds very nerdy, but it was exciting to read (Beethoven's 9th started
playing in my head as I got through the final example).

Obviously, I cannot say enough good about the work :-)

Cheers,
John Boyer


-----Original Message-----
From: merlin [mailto:merlin@baltimore.ie]
Sent: Monday, April 08, 2002 10:38 AM
To: aleksey@aleksey.com
Cc: reagle@w3.org; w3c-ietf-xmldsig@w3.org
Subject: 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/aleksey@aleksey.com/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 <aleksey@aleksey.com>
>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
Received on Monday, 8 April 2002 13:46:54 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:15 GMT