Comment on Exclusive Canonicalization

Comment on : http://www.w3.org/Signature/Drafts/xml-exc-c14n

A performance requirement I'd like on exclusive canonicalization is that it 
be equal to or faster than Canonical XML. Since it is seemingly doing less, 
this seems like a natural result, and since it appears folks will be using 
this algorithm frequently to detach a payload, efficient (single?) child 
element canonicalization would be a good thing.

Presently, Canonical XML requires one to keep the state of ancestors (their 
namespace declarations and whether they've already been rendered (if they 
are in the subset)). Exclusive canonicalization doesn't require one to worry 
about ancestor xml:foo attributes which is ok, but that ancestor context 
still needs to be processed so there's little savings there. While the 
"PertinentNamespaceDeclarations" is nice in that it doesn't keep namespace 
declarations never used, it requires additional descendent processing to 
determine if the namespace is visibly utilized. As specified in the spec, 
("one method for implementing"), this is certainly more expensive. The best 
implementation I've heard of would to have preprocess the whole document 
(not including parsing) at least once.

Consequently, I'd like to remove processing of "the XML parse subtree rooted 
by PN contains an element E that is in the document subset and visibly 
utilizes N." I don't think this hinders anything and it's equivalent to 
Canonical XML. I can't think of anyway to make it faster while staying 
within the XPath model. (If people wanted to diverge, one could consider the 
old Canonical XML [1], but that would take us back to prefix rewriting I 
think...)

[1] http://www.w3.org/TR/2000/WD-xml-c14n-20000119.html


--
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Friday, 27 July 2001 18:14:45 UTC