Value space of rdf:JSON datatype

[gkellogg]

Updates for #62 delved into updating the definition of the value space of the rdf:JSON datatype to use more primitive concepts from INFRA (arrays, maps, strings, booleans, and null) as well as number from ECMAScript.#62

The existing value space is based on the JCS representation of the JSON literal value. The proposed update could look like the following:

The value space

is a single JSON value in the form of an array, map, string, number, boolean, or null.

• Array entries may be any of the above JSON values.
• Map keys are strings with values, which may be any of the above JSON values.

Two JSON values are considered equal if they are the same string, number, boolean, or null; if they are both arrays with entries which are pairwise equal; or if they are both maps with equal map entries.

[afs]

array, map, string, number, boolean, or null.

As a general principle - I'm in favour of linking to original definitions where possible rather than incorporating material or normative referencing derived works which may diverge because they are for a specific or different purpose.

For JSON, RFC 8259 - I think that is the original definitive place (it would mean "map" -> "object"). RFC 8259 is the current STD-90.

(certainly for "string" - because a JSON string is not an RDF string or xsd:string)

[pfps]

But just what are the JSON values, particularly number?

[afs]

What are the requirements?

https://www.w3.org/TR/json-ld11/#terms-imported-from-other-specifications

where number goes to
https://tc39.es/ecma262/#sec-terms-and-definitions-number-value

but is that what the value space for a JSON fragment is for?

If it is "JSON processors treat them the same" then https://www.rfc-editor.org/rfc/rfc8259.html#section-6
and apply (some of) RFC8785 because the ultimate abstract value is not important.

[gkellogg]

array, map, string, number, boolean, or null.

As a general principle - I'm in favour of linking to original definitions where possible rather than incorporating material or normative referencing derived works which may diverge because they are for a specific or different purpose.

For JSON, RFC 8259 - I think that is the original definitive place (it would mean "map" -> "object"). RFC 8259 is the current STD-90.

(certainly for "string" - because a JSON string is not an RDF string or xsd:string)

First, we need to decide if we want to go for this decomposed notion of a JSON value for the value space. I'm fine with sourcing RFC8259, which would get out of the problem of having to go to ECMAScript for numbers.

JSON-LD (and INFRA) tend to use the term "map" rather than "object", as "object" is overly general. We can use the term "map" while still referencing the "Object" section in the RFC8259.

Regarding strings, certainly the strings referenced as JSON values (or within a JSON serialization) reference "strings" from RFC8259, and may include their own escape sequences. While "\uDEAD" may be represented (it technically can be in JSON-LD 1.1), this would be an aspect of the JSON value, rather than the lexical representation which would not allow a surrogate natively. JSON-LD 1.2 would likely be updated to exclude surrogates. It should be clear, and we may need to state it as such, that a JSON string is disjoint from an RDF string.

Of course, the other alternative is to not go with the decomposed notion of a JSON value as the value space, in which case we're dealing exclusively with RDF strings containing a JSON serialization. Note that the existing value space uses JCS/RFC8765 for the canonical form of JSON, which has similar requirements for character representation as our own, and requires implementations to terminate if a "loan surrogate" is found.

[afs]

do the two styles agree on what matches for numbers? (I think JCS does because it (in effect) goes through binary)

[pfps]

JCS has the decided advantage of only processing a subset of JSON. Unless rdf:JSON is limited to that subset depending on JCS may not be possible.

[afs]

I-JSON: RFC 7493

[gkellogg]

JCS was used by JSON-LD to create the RDF serialization of a JSON value in the Object to RDF Conversion algorithm, so it never did allow for surrogates, although JCS was not finalized at that time, so the definition of canonical lexical form may not strictly define that restriction. Any strict update to the rdf:JSON definition within JSON-LD would use JCS directly, and further limit code points similar how we've one in RDF Concepts and disallow surrogates explicitly. Obviously, this is what I-JSON did.

[pfps]

I-JSON has a lot more restrictions than just nice strings. Is rdf:JSON supposed to have these other restrictions too? If so, these other restrictions need to be stated explicitly.

The nice strings restriction needs to be either stated or true. I think that it is not true currently.

[afs]

"A lot"?

It is those things that make for accurate consistent parsing.

[pfps]

Number restrictions to IEEE floating point double.
No duplicate member names.

Ok, so not a lot in absolute terms. But a large part of the JSON syntax is affected.

[afs]

It is the areas where there is no common, stable, implemented values.
Unless @pfps has a proposal?

[gkellogg]

JSON doesn't allow duplicate keys (member names), either, although it is not typically an error condition; the last key wins. Limitations of I-JSON (and JCS) on string and number representation should not be a problem, as they're effectively already in place in JSON-LD due to the tacit correspondence to JCS.