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