"RE: Support of IEEE float; Canonical XML""

Taki,

I understand and agree (for the most part) with all you said below. I will restate my last comment more clearly, then try to refine the argument for IEEE floating point:

Preserve.lexicalValues should be defined to require that floating point values be represented in character form. When Preserve.lexicalValues is not set, floating point values should be represented in IEEE binary format.

The concern about loss of precision when floating point values represented in IEEE binary format make a round trip between EXI and XML is a quality of implementation issue, not a requirement on the binary representation.

A high quality implementation can and will preserve the exact bit-for-bit value of an IEEE float in the round trip from binary to (XML Schema defined) character back to binary (except for certain NaN's, as noted). Rounding errors are a danger with a poor quality implementation, they are not inherent in the process.

There is no need or any good excuse for EXI to be as bad as XML - after all, the whole point of EXI is to be better than XML with respect to efficiency - so why is it so terrible to take advantage of the opportunity to be better than XML in numeric fidelity, in the presence of potential poor implementations? And, in the bargain, get much better performance (and Direct Read/Write) when binary API's become available.

Again:
XML is inherently vulnerable to floating point rounding problems in the presence of a poor quality implementation. This is a bug. There can be no fix. EXI is currently specified in such a way as to be bug compatible with XML in this respect. Its not necessary or useful.

With a high quality implementation, each of XML, EXI as currently defined and EXI with Preserve.lexicalValues redefined as above have exactly the same characteristics with respect to floating point fidelity and compatibility with XML security.

---

With respect to canonicalization, the current text of Best Practices does not exactly reflect your comments below, but that is easily fixed. In particular, when mentioning EXI C14N, it is vital that Preserve.lexicalValues not be required.


Paul Pierce


> Hi Paul,
> 
> Preserve.lexicalValues is one of the EXI options which allows us to remain
> compatible with existing XML security standards. We currently specify it as
> a best practice when using EXI with existing XML security standards.
> 
> Please note that in every EXI option configuration, EXI enables the reconstruction
> of the same infoset after round-trip (either XML->EXI->XML or EXI->XML->EXI) to
> the degree required by the fidelity setting indicated by the option. What this
> means is that it is still necessary for data values to be able to round-trip to
> the text representation without loss of precision.
> 
> We appreciate your perspective on the Best Practices document as it relates EXI
> to the use of XML Security in particular. When the EXI WG started working on the
> Best Practices document, XML Signature/Encryption specifications had already
> been published as REC. It would have been irresponsible if we did not describe
> the way EXI can be used with the existing XML Security specifications. If we were
> allowed to start from scratch without such existing assets, we might have chosen
> some other ways similar to the one that you suggested, as the recommended method.
> It is precisely because of this legacy constraint that we feel that we are
> obliged to pursue the possibility of EXI C14N jointly with XML security WG in
> order to make sure the ideal practice will be eventually determined and become
> available. We agree that when an EXI C14N standard exists and is widely
> implemented, we can recommend it as a best practice. However, at this point,
> people are using XML C14N, so we need to provide best practices for using EXI
> and XML C14N together. This doesn't mean we are saying that using XML C14N is a
> best practice. We just providing best practices for using EXI and XML Security
> together because we know people will need to do that today.
> 
> Although we intend to maintain the current description in the Best Practices
> document for now, we plan to allude the possibility of EXI C14N -- as a more
> efficient option than the current XML C14N.
> 
> Regards,
> 
> Taki Kamiya (for the EXI Working Group)

Received on Wednesday, 3 June 2009 21:18:03 UTC