W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2000

RE: XSL WG comments on XML Signatures

From: John Boyer <jboyer@PureEdge.com>
Date: Thu, 16 Mar 2000 13:57:54 -0800
To: "Jonathan Marsh" <jmarsh@microsoft.com>
Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>, <w3c-xsl-wg@w3.org>
Message-ID: <BFEDKCINEPLBDLODCODKGEPDCBAA.jboyer@PureEdge.com>
Right, I had assumed that he intended to carry on with his assertion that I
could not use id(), which clearly wasn't true.  If he did intend to switch
to tag names (which on second read it seems he did), then your example shows
that no multiple parse is needed there either.

Basically, there is nothing conceptually wrong with having a parse function.
Any XPath implementation must expose a parse method of some kind that
returns a node-set in a form that the implementation's eval() function will
understand.

Exposing that function to the XPath expression author is, then, not such a
big leap.  Still, it is not a deal-stopper for me if parse() is eliminated.
I remain convinced that serialize() is necessary since the whole point of
this is to take a subset of the nodes of an input document and output a
digestable version of the input - the excluded nodes.

John Boyer
Software Development Manager
PureEdge Solutions, Inc. (formerly UWI.Com)
jboyer@PureEdge.com


-----Original Message-----
From: Jonathan Marsh [mailto:jmarsh@microsoft.com]
Sent: Thursday, March 16, 2000 1:12 PM
To: 'John Boyer'; James Clark; Martin J. Duerst
Cc: IETF/W3C XML-DSig WG; w3c-xsl-wg@w3.org
Subject: RE: XSL WG comments on XML Signatures


> -----Original Message-----
> From: John Boyer [mailto:jboyer@PureEdge.com]

> It's also going to be very awkward.  Instead of something like
>
>   e1|e2|e3|e4
>
> you will have to write
>
> parse($input,true())/e1|parse($input,true())/e2|parse($input,t
> rue())/e3|pars
> e($input,true())/e4
>
> <John>
> Parsing 4 times in this case is simply not necessary:
>
> parse($input,true())/descendant-or-self::node()[id("e1")|id("e
> 2")|id("e3")|i
> d("e4")]

This is not equivalent to James' example.  I think the following is,
however:

  parse($input,true())/node()[self::e1 or self::e2 or self:e3 or self::e4]

I can't think of a situation right now where multiple parses would be
necessary, but some of the cases could get pretty byzantine:

  a | b//x

becomes:

  parse($input,true())/descendants::node()[(self::a and not(parent::*)) or
(self::x and ancestor::b)]

Generic XPath implementations will be optimized for the simple case and may
perform better.

Also, just because parse() need only be called once, doesn't preclude users
from calling it more than once, which could be quite costly.
Received on Thursday, 16 March 2000 16:55:53 GMT

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