June: Next steps for xmldsig

I thought I'd send another "next step" since it allows me to keep the pace 
and for folks to correct me when I've missed/drop something. Some of this 
summary covers the period I was traveling for a couple of weeks, so do let 
me know if this isn't how you see things! <smile/>

CORE

- I have to figure out what the value of the Encoding attribute should have 
(string or anyURI) but otherwise all is well.

XPATH-FILTER2
- Christian had proposed a different approach (i.e., the "labelling 
scheme") which he found more intuitive and permitted some optimizations.
- I didn't hear agreement that folks found it more intuitive; and while it 
improved performance in some cases, those weren't the cases others (e.g., 
Merlin) were most concerned with.
- John indicated the sort of optimizations Christian was recognizing 
(coupling the transforms with a c14n phase) were useful, could the spec 
mandate this sort of thing? Reagle responded he's not sure how, but he'll 
be aggressive on the row in the interop matrix for performance.
- Additionally, Aleksey has suggested that XPath1.0 could be tweaked to 
accommodate improvements without some of the specification found in XPath 
2.0. The benefits of this ends up depending on whether one wants external 
(fast) subtree expansion. (If a scenario needs it, then there's a 1.5-2x 
performance improvement, if not there's a great performance hit.) Aleksey 
proposed a parameter for this "#noChildsExpansion". However, I didn't hear 
any responses to that proposal.
- In summary, the sort of consideration we're giving to optimizations are 
fantastic! But you can only go so far before most of the differences are 
contingent upon the XML document, the XPath expressions being evaluated, 
and the character of the implementation. Since I haven't heard any 
agreement on a substantive change to XPath 2.0 as is, I'd recommend we 
continue on and focus on making sure it is possible to implement fast by 
reporting performance in the interop matrix. If folks want to make a 
change, they should propose a specific "plug-and-play" (diff) to the spec.

EXC-C14N

- In Proposed REC now. There were some reports of performance being faster, 
some were slower, but I'm confident that we don't propose anything that is 
intrinsicly more costly that can't be addressed with optimization.

Received on Monday, 3 June 2002 14:13:50 UTC