5 ms·

> JSON fails to define "what is a string?" and "what is a number?" Can you elaborate on this? It seems pretty clear from the spec to me: stuff starting with "

> JSON fails to define "what is a string?" and "what is a number?" Can you elaborate on this? It seems pretty clear from the spec to me: stuff starting with " is a string, stuff starting with - or a digit is a number.

paulddraper 3y ago
"What is a number?" Min value? Max value? Precision (and in what base)?
- stkdump 3y ago
  Simple, the RFC even calls that out: assume 64 bit float as specified by IEEE and as basically supported everywhere. Why should JSON do anything else than the rest of the world does?
- otabdeveloper4 3y ago
  64 bit IEEE 754 floating point, as per the spec. Anything else is non-standard.
  - paulddraper 3y ago
    Datadog APIs use 64 bit ints. PostgreSQL also doesn't follow your "standard".
    - otabdeveloper4 3y ago
      The "standard" is called JSON, and it's not mine, it's made by the IETF. Don't know what a "Datadog" is, and I don't care about Postgres idiosyncrasies.
      - Dylan16807 3y ago
        Okay, let's quote the RFC then. > A number is represented in base 10 using decimal digits. It contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part. > This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. That sure doesn't sound like numbers are 64 bit floats, according to the spec.
        stkdump 3y ago
        > That sure doesn't sound like numbers are 64 bit floats, according to the spec. It can't be 64 bit floats, because they are represented as decimal numbers, not binary. You will be surprised to also hear that most base conversion algorithms used are not exact, and so different implementations might give different results in the LSB(s) for some numbers for performance reasons. Here practicality prevails, because making the standard stricter would make its implementation much harder in many environments. And for many applications it isn't a problem. I am sure btw that most file formats that use decimal representations for floating point numbers have this property, otherwise exact base conversion would be more prominently accessible in more programming languages. I have some hope that this will change in the future, as exact base conversion (lossless round trip) will gain momentum now that it landed in standard C++. Once most common programming languages have this feature, there isn't a big reason to not modify the standard anymore to enforce lossless round-trip.
      - paulddraper 3y ago
        > I don't care I got that.
nomel 3y ago
The stuff between the "" is important: it must be unicode.
- o11c 3y ago
  Except not really. Under what circumstances are surrogates allowed? Under what circumstances are controls allowed?
  - stkdump 3y ago
    >8.1. Character Encoding > JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8 [1]. I don't know what you mean by controls (you mean unicode control characters, for which the spec explicitly states that they are to be escaped?), but since JSON should really only be exchanged as UTF-8, surrogate pairs play no role. [1] https://www.rfc-editor.org/rfc/rfc8259 https://www.rfc-editor.org/rfc/rfc8259

paulddraper 3y ago

"What is a number?" Min value? Max value? Precision (and in what base)?

stkdump 3y ago
Simple, the RFC even calls that out: assume 64 bit float as specified by IEEE and as basically supported everywhere. Why should JSON do anything else than the rest of the world does?
otabdeveloper4 3y ago
64 bit IEEE 754 floating point, as per the spec. Anything else is non-standard.
- paulddraper 3y ago
  Datadog APIs use 64 bit ints. PostgreSQL also doesn't follow your "standard".
  - otabdeveloper4 3y ago
    The "standard" is called JSON, and it's not mine, it's made by the IETF. Don't know what a "Datadog" is, and I don't care about Postgres idiosyncrasies.
    - Dylan16807 3y ago
      Okay, let's quote the RFC then. > A number is represented in base 10 using decimal digits. It contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part. > This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. That sure doesn't sound like numbers are 64 bit floats, according to the spec.
      - stkdump 3y ago
        > That sure doesn't sound like numbers are 64 bit floats, according to the spec. It can't be 64 bit floats, because they are represented as decimal numbers, not binary. You will be surprised to also hear that most base conversion algorithms used are not exact, and so different implementations might give different results in the LSB(s) for some numbers for performance reasons. Here practicality prevails, because making the standard stricter would make its implementation much harder in many environments. And for many applications it isn't a problem. I am sure btw that most file formats that use decimal representations for floating point numbers have this property, otherwise exact base conversion would be more prominently accessible in more programming languages. I have some hope that this will change in the future, as exact base conversion (lossless round trip) will gain momentum now that it landed in standard C++. Once most common programming languages have this feature, there isn't a big reason to not modify the standard anymore to enforce lossless round-trip.
    - paulddraper 3y ago
      > I don't care I got that.

nomel 3y ago

The stuff between the "" is important: it must be unicode.

o11c 3y ago
Except not really. Under what circumstances are surrogates allowed? Under what circumstances are controls allowed?
- stkdump 3y ago
  >8.1. Character Encoding > JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8 [1]. I don't know what you mean by controls (you mean unicode control characters, for which the spec explicitly states that they are to be escaped?), but since JSON should really only be exchanged as UTF-8, surrogate pairs play no role. [1] https://www.rfc-editor.org/rfc/rfc8259 https://www.rfc-editor.org/rfc/rfc8259