This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29435 - [ser3.1] JSON Serialization of numerics
Summary: [ser3.1] JSON Serialization of numerics
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Serialization 3.1 (show other bugs)
Version: Candidate Recommendation
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-08 17:28 UTC by Michael Kay
Modified: 2016-03-01 11:15 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2016-02-08 17:28:53 UTC
I parsed and then reserialized a JSON file containing records of the form:

{"_id":5285039,"name":"Black Bear Spring","country":"US","coord":{"lon":-110.288139,"lat":31.386209}}

The serialized form of the record (well, a similar record...) looks like this:

{"name":"Gray County","coord":{"lon":-100.802002,"lat":35.416698},"country":"US","_id":5.52243E6},

Turning a 7-digit ID value into exponential notation seems unfortunate, but it appears to be what our spec requires.

I wonder if we could change the rules so that a numeric value that is exactly equal to some integer Z is serialized by casting to xs:integer and then applying the string() function to the integer? At the very least we should permit such a serialization.

(Perhaps only if the integer is within some implementation-defined range not smaller than -10^15 to +10^15).
Comment 1 Andrew Coleman 2016-03-01 11:15:57 UTC
The WG agreed to allow implementers to serialize numbers using any legal JSON lexical form.
The change has been applied to the spec.