Re: [Json] [Technical Errata Reported] RFC8259 (7617)

[Guillaume Fortin-Debigaré <[e-mail]>]

>
> I don't think this is a problem with the JSON RFC. The dispute here is
> about JSON.stringify(), part of the ECMAScript specification. Consult:
>
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify
>
> There are many such choices in there:
>
> JSON.stringify({test: 0})
> '{"test":0}'
> JSON.stringify({test: -0})
> '{"test":0}'
> JSON.stringify({test: Infinity})
> '{"test":null}'
>

You just made me realize that JavaScript parses "-0" as negative zero,
despite stringifying the latter as "0". The fact that it is not
interoperable with itself is quite ironic.

That said, I only mentioned JavaScript as an example of
non-interoperability. My point is that even when software implements IEEE
754 binary64, it may not be interoperable due to this edge case.

The document does say "A number is represented in base 10 using decimal
> digits."
>

It does. but that wording is vague. For example, I had a discussion with my
work colleague the other day where they argued that the "e" part in a JSON
number may be parsed differently whether it is in uppercase or lowercase,
which would require special support in our product. This seems unlikely to
me outside of a parsing bug, but I've seen stranger things. A more likely
interoperability issue also arises when dealing with whether trailing zeros
should count as significant figures or not, which may matter for physicists
and data scientists. The negative zero case however is the only one that I
have noticed that actually contradicts the current text however, hence this
report.

In any case, I figured that since this issue was caused by incomplete
interoperability guidance that it would be a good opportunity to clarify
other potential interoperability issues with numbers at the same time, just
like you guys did with the parsing of surrogate characters in the previous
update.