- From: Joseph Reagle <reagle@w3.org>
- Date: Tue, 9 Apr 2002 16:15:06 -0400
- To: aleksey@aleksey.com, John Boyer <JBoyer@PureEdge.com>
- Cc: merlin <merlin@baltimore.ie>, w3c-ietf-xmldsig@w3.org
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