Numbers and booleans as @type

[cygri]

Consider this snippet:

{"@type":1}

The Expansion algorithm doesn't address this case specifically, so I presume the JSON object is not modified during expansion. Same for true and false as @type values. However, this would be illegal:

{"@type":[1, true, false]}

This seems to be inconsistent. Why are numbers and booleans allowed as individual type values, but disallowed in arrays?

[lanthaler]

The JSON-LD grammar section says:

If the node definition contains the @type key, it's value must be either a string having the lexical form of absolute IRI, compact IRI, a term defined in the active context expanding into an absolute IRI, or an array of any of these.

So this is clearly not a valid JSON-LD document and therefore the playground throws an exception.

I do not know whether we should include all validity checks in the algorithms or work under the assumption that only valid JSON-LD documents are processed by these algorithms. Thoughts?

[cygri]

Okay. I must admit I haven't read the grammar section yet, so this probably explains a few of my confusions.

Saying the same thing twice normatively in a spec is always bad.

I would suggest defining a “well-formed JSON-LD document” or something like that, in the grammar section (or in Conformance); then state at the beginning of the algorithm that the input of the algorithm is a well-formed JSON-LD document (making that term a hyperlink, obviously).

FWIW, I find the title “JSON-LD grammar” for that section a bit confusing, as it's not an actual grammar. It's just a definition. “Well-formed JSON-LD Documents” would work better for me.

Also, I increasingly believe that “JSON-LD Syntax” should be treated as a more Primer/Tutorial-style document, and all the normative “meat” (data model, well-formedness definitions, algorithms, APIs) moved to the “Processing” spec. That would free the Primer spec from having to spell out everything in complete detail, and allows a focus on accuracy, clarity, completeness and correctness in the Processing spec.

[msporny]

PROPOSAL 1: Define what a 'well-formed JSON-LD document' means in the Conformance section.
PROPOSAL 2: Add text to the beginning of all algorithms noting that a valid JSON-LD document SHOULD be provided as input to each algorithm. Keys and values that would cause a valid JSON-LD document to become invalid will most likely be dropped during processing.

[msporny]

PROPOSAL 1: +1
PROPOSAL 2: +1

[tidoust]

PROPOSAL 1: note a "JSON-LD document" as defined in the conformance section must follow the constraints defined in the Grammar section and thus is already "well-formed". I do not mind using "well-formed" as prefix if that helps people understand we're always talking about "well-formed" JSON-LD documents. Overall, I'm 0 on this.

PROPOSAL 2: +1. It's still a good idea if algorithms are explicit about error handling, but your proposal certainly does not prevent that.

[cygri]

PROPOSAL 3: State in the definition of each applicable algorithm that the input is a (well-formed) JSON-LD document. State in the conformance section of the API/Algorithms/Processing document that the spec does not constrain the behaviour of JSON-LD processors for JSON documents that are not (well-formed) JSON-LD documents.

[cygri]

PROPOSAL 1: 0 as per @tidoust's reason—a non-well-formed JSON-LD document is simply a JSON document.
PROPOSAL 2: -0.9, I feel that littering SHOULD and MAY all over the spec is really the wrong way of allowing for error recovery
PROPOSAL 3: +1

[lanthaler]

PROPOSAL 1: 0, agree with François
PROPOSAL 2: -0.5, I find the following statement quite irritatating: "Keys and values that would cause a valid JSON-LD document to become invalid will most likely be dropped during processing."
PROPOSAL 3: +1

[gkellogg]

PROPOSAL 1: I find value in "we'll formed". Even though a non-well-formed JSON-LD document can be considered just JSON, it could be a JSON-LD 2.0 document too; allowing a JSON-LD 1.0 processor to make sense of this is useful.

PROPOSAL 2: 0, (not the most likely bit). We could drop the SHOULD and just have an informative note advising implementations to honor Postel's rule.

PROPOSAL 3: +1

[lanthaler]

RESOLVED: State in the definition of each applicable algorithm that the input is a (well-formed) JSON-LD document. State in the conformance section of the API/Algorithms/Processing document that the spec does not constrain the behaviour of JSON-LD processors for JSON documents that are not (well-formed) JSON-LD documents.

[lanthaler]

I have added these statements in def0f68. Unless I hear objections I will proceed and close this issue in 24 hours.