Re: New Version of XPath Filter

Hi Aleksey,

I must admit that I have not yet implemented this transform, but I guess 
(with respect to my own implementation) that "calculating" S' is additional 
overhead or something like this. For me personally, even the performance is 
not the primary goal. BUT - I guess that this new XPath2 filter will be 
more easily understandable for XML Signature newbies. The concept from 
XPath1 to evaluate the XPath against each node and then decide based on the 
boolean whether to include it or not is very complicated to understand for 
people new to the topic and using it correctly, is even more complicated. 
Took long time until I understood these obfuscated "count(foo)>count(bar)" 
XPath expressions.

My personal impression is that this new transform will make life easier for 
our users.

Regards,
Christian

--On Montag, 8. April 2002 12:02 -0700 Aleksey Sanin <aleksey@aleksey.com> 
wrote:

> I need to think about profiling this scenarios. Probably you are right
> about performance. However, personally I don't think that it's a good
> idea to write general standard with performance as a top priority. My
> expirience shows that performance improvements are usually very
> complicated, not simple to explain and very difficult to maintain.
>
> Calculating S' is one additional step and this step adds complexety to
> the proposed scheme. I like the initial idea: describe XPath transform in
> terms of sets operations. It really simplifies understanding and makes
> everything clear. I suggest you to take a look at this from a "user"
> point of view: "I've constructed XPath expression but transform added
> some nodes to it. Why???" And remember that users never read docs :)
>
> And I think you agree with me that your solution for the second scenario
> I described (when only node "b" is required) has worse performance then a
> solution w/o S'.
>
> Aleksey.

Received on Monday, 8 April 2002 17:09:30 UTC