RE: Support of IEEE float; Canonical XML""

Hi Paul,

The problem of numeric precision loss is most likely to occur not when the
data starts with EXI, but when it originates in XML and gets transcoded to EXI
then back to XML.

The WG observed that any finite-length base-2 number can always be converted
to an equivalent finite-length base-10 number, but not vice versa. There
are finite-length base-10 numbers that when converted to base-2 number need
infinite digits to describe exactly the same numbers. An example is a decimal
number "0.1", of which the binary representation is "0.000110011001100.....".

We hope this helps explain the issue of precision loss that may be entailed
by the use of IEEE float.

Having said that, I would like to note that IEEE float can still be used with
EXI by exploring user-defined datatype representation capability [1] to extend
the EXI format, in order for EXI to be able to recognize and process IEEE float
data as part of the stream.

[1] http://www.w3.org/TR/exi/#datatypeRepresentationMap

Regards,

Taki Kamiya (for the EXI Working Group)


-----Original Message-----
From: public-exi-comments-request@w3.org [mailto:public-exi-comments-request@w3.org] On Behalf Of Paul Pierce
Sent: Wednesday, June 03, 2009 7:47 PM
To: Taki Kamiya; EXI Comments
Subject: "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, 24 June 2009 16:58:24 UTC