Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Numbers and booleans as @type #188

Closed
cygri opened this Issue · 11 comments

5 participants

@cygri
Collaborator

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
Owner

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
Collaborator

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
Owner

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
Owner

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
Collaborator

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
Collaborator

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
Owner

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
Owner

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
Owner

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 lanthaler referenced this issue from a commit
@lanthaler lanthaler Add conformance section to JSON-LD API spec
I also added statements to all algorithms saying that they expect well-formed JSON-LD documents.

This addresses #184 and #188.
def0f68
@lanthaler
Owner

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

@lanthaler lanthaler closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.