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>


Hi,

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.

Thanks,
John Boyer

-----Original Message-----
From: Christian Geuer-Pollmann
[mailto:geuer-pollmann@nue.et-inf.uni-siegen.de]
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> 
wrote:

> The expectation of comment infestation in the XPath element content
was
> 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
concatenates
> all text nodes descendants.

Hi John,

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

Thanks,
Christian
Received on Tuesday, 7 May 2002 14:49:51 GMT

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