- From: by way of Paul Grosso <jjc@jclark.com>
- Date: Wed, 12 Jan 2000 09:50:31 -0600
- To: www-xml-canonicalization-comments@w3.org
I have an action item to explain the minority opinion for XML C14N's not including Unicode I18N. Unicode C14N and XML C14N are logically indepedent processes. Making XML C14N include Unicode C14N is non-modular and non-orthogonal. Not only are they are logically indepedent but they are in practice performed at completely different times: Unicode C14N is performed early (when documents are created), or at least is supposed to be according to the W3C Character Model; XML C14N is performed at a much later stage (typically on the fly). XML C14N is supposed to be useful for conformance testing as well as digital signatures. Requiring vendors to create a complex and subtle (and thus potentially buggy) piece of code just to test conformance is both unnecessary and inappropriate. I suspect in practice people using XML C14N for conformance testing will simply not implement the Unicode C14N part. Relative to the rest of XML C14N, I believe Unicode C14N is relatively complex and resource intensive. It will make a significant difference to either code size or speed (you can probably implement slowly in a little code, or fast in a lot of code). In the context of its use for digital signatures, XML C14N needs to be performed in scenarios where processing resources are strictly limited. Requiring Unicode C14N in such scenaries is problematic, especially since it will in most cases be unnecessary because of the early-normalization policy of the W3C character model. I feel this decision has a significant chance of creating a split in the market. I believe many applications for which Unicode C14N is unncessary or inappropriate will simply not implement it, whatever the spec says. If the decision was reversed, I believe no such danger exists. I would also point out that a version of XML C14N (my original C14N spec) that does not require Unicode C14N has been very widely implemented and deployed for a long time. Making a substantial change like this at the last stage in the process is a mistake. James
Received on Wednesday, 12 January 2000 10:50:33 UTC