RE: History: Question on C14N list of nodes instead of subtrees

Hi Merlin,

In some ways your results are a bit of a relief in that the performance
profiles are clearly not the result of O(n log n) processes.  At least
part of the problem sounds like the XPath implementation (or some way it
is being used) is suboptimal.  Even with an optimal XPath
implementation, I think the transform could be made far faster.  The
problem is that it would require a fair bit of effort such that the
resulting performance profile would not be 'interoperable'.
Unfortunately, our interoperability requirements focus on correctness of
the output bitstream, not performance profiles.  Although I had
originally expected that vendor tools would be written to achieve
optimal performance, it seems clearer now that we will have to 

a) architect some new transform (after XML DSig 1.0) that is easier to
make efficient
b) specify a performance profile that must be met for conformance.

For what its worth, the #include/#exclude formulation is quite a
significant improvement and demonstrates perfectly why the most concise
notation is not always the best choice!  Still, if the 'arbitrary time
units' you mentioned happen to be milliseconds, then I would think the
#include/#exclude formulation still needs optimization.  It would be
helpful to know what happens if you switched to using XPath just to
identify subtree roots to include or exclude, then use internal
programming to formulate the actual final node-set.

John Boyer
PureEdge Solutions Inc.

Received on Thursday, 31 January 2002 17:47:39 UTC