Skip to content

Numbers and booleans as @type #188

Closed
cygri opened this Issue Nov 7, 2012 · 11 comments

5 participants

@cygri
cygri commented Nov 7, 2012

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
JSON-LD Public Repositories member

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
cygri commented Nov 7, 2012

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
JSON-LD Public Repositories member
msporny commented Nov 20, 2012

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
JSON-LD Public Repositories member
msporny commented Nov 20, 2012

PROPOSAL 1: +1
PROPOSAL 2: +1

@tidoust
tidoust commented Nov 20, 2012

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
cygri commented Nov 20, 2012

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
cygri commented Nov 20, 2012

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
JSON-LD Public Repositories member

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
JSON-LD Public Repositories member

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
JSON-LD Public Repositories member

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 added a commit that referenced this issue Dec 3, 2012
@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
JSON-LD Public Repositories member

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 Dec 4, 2012
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.