Major Description
Conversion to base 10 is required for XML, and that means floating point numbers converted from binary to base 10 are going to lose information sometimes vs. their binary IEEE 754 or other representation.
But.... We or a user via UDF could provide a conversion function hexBinaryToDouble, then you could get something like this:
<myValue>
<ieeeHex>40FE208000000000</ieeeHex>
<value>1.234e5</value>
</myValue>
The <value> element is there to exhibit the value in a human-understandable way, but the parsing would actually unparse from the raw ieeeHex element which is a hex dump of the actual value bits.
On unparsing, if the base 10 value has been modified, and no longer matches the base-10 equivalent of the raw value, then the binary data could be recomputed from the new base 10 value.
Due to big/little endian issues, we probably want to do this from 64-bit integers, not hexBinary. That way the conversion functions are byte order independent.
Note about EXI (DAFFODIL-1959) - if we are converting data from binary to EXI representation or back for unparsing, it would be great if no conversion to base 10 text was required. This raises an issue however, of a different DFDL schema being appropriate when using EXI vs. when using XML text (or any other base-10 text representation).