-
Type:
Task
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: V4.0_WD01
-
Fix Version/s: V4.0_WD01
-
Component/s: JSON Format
-
Labels:None
-
Environment:
[Applied]
-
Proposal:
-
Resolution:
According to odata-json-format-v4.0-wd01-2013-03-05-RH.doc (section 4.1.1)
Values of types Byte, SByte, Int16, Int32, Single, and Double are represented as JSON numbers.
but that does not account for NaN, Infinity and -Infinity.
Now the ABNF (odata-abnf-construction-rules-v4.0-wd01.html) states that these values can be encoded as: 'NaN', 'INF' and '-INF'.
However I understood that the ABNF rules are applicable to values in URLs, not in JSON (unless explicitly stated in the JSON doc, as is the case with geo types).
Also note that the ABNF allows Double values to end with "d", and Single values to end with "f".
Here then, we see an apparent contradiction. NaN, INF, -INF, Double values ending with "d", and Single values ending with "f" are permitted by the ABNF rules, but not permitted in a JSON number.
The JSON spec (http://www.ietf.org/rfc/rfc4627.txt) section 2.4 quite clearly states:
Numeric values that cannot be represented as sequences of digits
(such as Infinity and NaN) are not permitted.
Trailing "d" and "f" are already disallowed in JSON as the specification explicitly refers to the JSON number representation.
The representation of other primitive types in JSON refer to ABNF rules following the pattern xxxBody, but singleBody and doubleBody are not referenced in the JSON spec. To avoid possible future misunderstandings I moved the nanInfinity alternative to the rules single and double in ABNF revision 223.
I hesitate to use string literals for representing NaN, INF and -INF in JSON payloads, making single and double properties sometimes string-valued.