Add caveat on numbers being represented as double #161
Conversation
…e to represent as integers.
Co-Authored-By: gkellogg <[email protected]>
index.html
Outdated
| (<a>numbers</a> with a non-zero fractional part, i.e., the result of a modulo‑1 operation, | ||
| <span class="changed">or which are too large to represent as integers,</span> |
There was a problem hiding this comment.
I think it is important to specify what kind of integer this is (XSD, JSON, programming language integer, ...).
It looks like the XSD spec defines the value space of xsd:integer as an infinite set, which means that there is no maximum (or minimum) value.
Next to that, the JSON RFC also does not place a strict limit on integer/number sizes, but merely allows limits to be set by software.
Unless this has been defined somewhere already, I think it would be good to define integer sizes in the JSON-LD spec. To be consistent with most programming languages, values for 32-bit integer sizes may be useful. Perhaps this can be a soft limit, to be in line with JSON.
Side-note: Next to mentioning values that are too large, values that are too small should also be considered.
There was a problem hiding this comment.
Are there such limit in the RDF model? I do not remember having one, in which case I do not think that, formally, JSON-LD could impose any limit...
There was a problem hiding this comment.
Text was added to refer to Data Round Tripping for limitations on integer representations.
|
This corresponds to w3c/json-ld-api#79, and is a practical consideration of round-tripping issues. In theory, JSON numbers can be of arbitrary length, but in practice, implementations use IEEE floating point representations for numbers (JS in particular, but also Ruby). Consequently, there is a limit to the size of an integer that JSON can represent with fidelity to be < However, it may be that we don't need to reflect such interoperability issues in the Syntax document. |
…integers in JSON.
if they're too large to represent as integers.