XPath Filter 2.0 speed test progress

"John Boyer" <[email protected]>
Newsgroups gmane.ietf.xmldsig
Message-ID <[email protected]>

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:[email protected]]
Sent: Tuesday, May 07, 2002 11:35 AM
To: John Boyer
Cc: [email protected]
Subject: RE: here() context and comment nodes


--On Dienstag, 7. Mai 2002 10:37 -0700 John Boyer <[email protected]> 
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.