- From: John Boyer <JBoyer@PureEdge.com>
- Date: Thu, 31 Jan 2002 14:47:07 -0800
- To: "merlin" <merlin@baltimore.ie>
- Cc: <reagle@w3.org>, <w3c-ietf-xmldsig@w3.org>
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. Thanks, John Boyer PureEdge Solutions Inc.
Received on Thursday, 31 January 2002 17:47:39 UTC