W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2002

XPath Filter 2.0 speed test progress

From: John Boyer <JBoyer@PureEdge.com>
Date: Tue, 7 May 2002 11:49:20 -0700
Message-ID: <7874BFCCD289A645B5CE3935769F0B523286E0@tigger.PureEdge.com>
To: "Christian Geuer-Pollmann" <geuer-pollmann@nue.et-inf.uni-siegen.de>
Cc: <w3c-ietf-xmldsig@w3.org>


Has anyone had a chance to look further into my prior email about speed
testing the new filter.

I remain concerned that the new method remains too slow.  I agree that
it 'rules' from a flexibility standpoint, but correctness of the result
is not the only software requirement that exists.

John Boyer

-----Original Message-----
From: Christian Geuer-Pollmann
Sent: Tuesday, May 07, 2002 11:35 AM
To: John Boyer
Cc: w3c-ietf-xmldsig@w3.org
Subject: RE: here() context and comment nodes

--On Dienstag, 7. Mai 2002 10:37 -0700 John Boyer <JBoyer@PureEdge.com> 

> The expectation of comment infestation in the XPath element content
> the biggest reason why we defined here() to return the element node
> parent when it didn't appear in an attribute.  Here's the one that
> originally shook my boots, so to speak:
> he<!-- Yikes -->re()/blah/blah/blah
> This is legal XML, so it has to be supported.  In general, take the
> 'string' corresponding to the Xpath element content, which
> all text nodes descendants.

Hi John,

OK, that's what I do. Interesting that the above is legal. Maybe we
include such an obfuscation into our interops ;-)

Received on Tuesday, 7 May 2002 14:49:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:37 UTC