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

RE: XSL WG comments on XML Signatures

From: Brown, Sam <sbrown@saonet.ucla.edu>
Date: Thu, 16 Mar 2000 13:18:59 -0800
Message-ID: <1EF0C92BCCDAD2118FD40020480E269B01B0B786@10eEXCHANGE.SAONET.UCLA.EDU>
Cc: IETF/W3C XML-DSig WG <w3c-ietf-xmldsig@w3.org>
Hi all,

Just curious.  How would a vendor's product like PenOp's electronic
signature software work into the XML signature syntax?  Any thoughts on
this?

Have a blessed day.:)

Sam Brown
UCLA Arthur Ashe Student Health & Wellness Center
Information Systems Manager
(310) 206-6356

-----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:22:14 GMT

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