Re: New Version of XPath Filter

On Monday 08 April 2002 19:56, Aleksey Sanin wrote:
>  From my point of view, this new transform *restricts* XPath expressions
> functionality and makes things more complicated. However, nobody agrees
> with me so probably things will stay "as is".

As a less subsuntative aside (avoiding largers questions and whether we 
call this an XPointer transform -- I tend to agree with Merlin/John and 
prefer to call it XPath Filter 2.0) I've made a few editorial tweaks.

1. Marked all of Merlin's edits as "accepted".
2.  Made a few tweaks on definitions, including input document as, "the 
document is the document that contains all the nodes available to 
processing by this transform." For instance, it used to say [1], it now 
says [2].
3. Changed the em CSS so it's not italic and bold. Does that help?
em {font-weight: bold; font-style: normal;}


[0] http://www.w3.org/Signature/Drafts/xmldsig-xpath 
 $Revision: 1.7 $ on $Date: 2002/04/09 20:09:35 $ GMT by $Author: reagle $ 
[1] "The input required by this transform is an XPath node-set representing 
an input document. If the input document is an octet stream, then the 
application MUST convert the octet stream to an XPath node-set (including 
comment nodes)."
[2] "The input required by this transform is an XPath node-set over the 
input document. If the input document is an octet stream, then the 
application MUST convert the octet stream to an XPath node-set that 
contains all of the document nodes (including comment nodes)"

-- 

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/

Received on Tuesday, 9 April 2002 16:15:13 UTC