TF-JSON/Semantics of JSON
To define a representation of RDF in JSON, the TF-JSON might require an account of the semantics of JSON: What exactly does a JSON document serialize? This page states such a semantics, based entirely on RFC 4627. This sometimes requires reading between the lines of that document.
Syntax of JSON
The syntax is defined in RFC 4627.
Question: Are there any glitches there that the WG needs to keep in mind?
Semantics of JSON
A JSON text is a serialized object or array.
An object is an unordered collection of zero or more name/value pairs.
A name is a string. The names within an object SHOULD be unique.
An array is an ordered list of zero or more values.
A value is an object, array, number, or string, or one of the following three literal names:
A string is a sequence of zero or more Unicode characters.
A number is any decimal number (including fractions). Note that IEEE floating point “numbers” that cannot be represented as sequences of digits (such as Infinity and NaN) are not permitted.
Question: What about -0?
According to RFC 4627:
- An implementation may set limits on the size of texts that it accepts.
- An implementation may set limits on the maximum depth of nesting.
- An implementation may set limits on the range of numbers.
- An implementation may set limits on the length and character contents of strings.
Question: What are the reasonable limits here? Can I cut strings down to the empty string?
Duplicate names: Almost all popular implementations do not handle objects with duplicate names, so they SHOULD (very strongly) be avoided.
Question: Does this mean they raise a syntax error, or (silently) throw away some information?
Numbers and booleans: Popular implementations tend to treat non-fractional numbers as Integer, and fractional numbers as Double, in the programming language's type system. The
false literal names are usually mapped to the boolean type.
Null values: Users may not be fully aware of the difference between a
null-valued name/value pair, and an absent name/value pair. If possible, this distinction should not carry significant application semantics.
Question: What about this different in the presence of another value for the name, particularly if it comes from using a prototype?