Re: xmldsig-filter2 rationale questions

On Tuesday 30 April 2002 12:22, [email protected] wrote:
> 1. If runtime performance is an issue, would it also be a possibility to
> integrate the XQuery activities as XML-Signature transfomations?

I'm not sure how that would necessarily improve things. (It might, but I 
don't know.) Regardless, I'm sure someone could specific such a XML Query 
Filter, but we haven't yet had any need for it.

> 2. If functionality like having node-set intersections and unions is an
> issue, would be possible to consider additional mathematical node-set
> operations for a future version of XPath? (I still consider it a
> work-around having to use something like count(SET) = count(SET |
> ELEMENT) to test an element-in-set relation ;-)

The new operations aren't issues in and of themselves, their solutions to a 
previous issue and useful additions to boot. The xmldsig-filter2 shouldn't 
require"count" to have to appear in an XPath expression, as one can now 
express an eveloped signature selection as:


   <XPath Filter="subtract"
    xmlns="http://www.w3.org/2002/04/xmldsig-filter2"
    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
      here()/ancestor::dsig:Signature[1]
   </XPath>

instead of:

   <XPath xmlns:dsig="&dsig;">
   count(ancestor-or-self::dsig:Signature |
   here()/ancestor::dsig:Signature[1]) >
   count(ancestor-or-self::dsig:Signature)</XPath>