Adaptive serialization: doubles

[ChristianGruen]

We should make the serialization spec more liberal when it comes to the representation of double values. The prescribed output format is format-number(?, '0.0##########################e0'), which is very strict and often confusing when maps and arrays are serialized. Maps resulting from JSON conversions often contain doubles without users noticing it (related: #1583).

We should make the behavior implementation-dependent or align it with the serialization of JSON data (without losing its additional features to e.g. serialize function items or sequences). Backward compliance shouldn’t be an important issue, as the method was mainly introduced for debugging purposes.

[michaelhkay]

The idea was that, because the method is there for debugging purposes, you should be alerted to the fact that the values are floating point.

[ChristianGruen]

The idea was that, because the method is there for debugging purposes, you should be alerted to the fact that the values are floating point.

It is not quite clear me why there is a special rule for doubles, but not for other types (when 1 is output, the item might have been an integer, a byte, a decimal or a text node. "a" could have been a string or a URI, and so on).

One argument for being more liberal could be that this is a debugging feature, and we have not formalized the output of fn:trace or $err:stack-trace either. Maybe we should even allow processors to output items as xs:double(‘1234‘), xs:byte('1'), and so on.