-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Numbers and booleans as @type #188
Comments
The JSON-LD grammar section says:
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? |
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. |
PROPOSAL 1: Define what a 'well-formed JSON-LD document' means in the Conformance section. |
PROPOSAL 1: +1 |
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. |
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. |
PROPOSAL 1: 0 as per @tidoust's reason—a non-well-formed JSON-LD document is simply a JSON document. |
PROPOSAL 1: 0, agree with François |
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 |
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. |
I have added these statements in def0f68. Unless I hear objections I will proceed and close this issue in 24 hours. |
Consider this snippet:
The Expansion algorithm doesn't address this case specifically, so I presume the JSON object is not modified during expansion. Same for
true
andfalse
as @type values. However, this would be illegal:This seems to be inconsistent. Why are numbers and booleans allowed as individual type values, but disallowed in arrays?
The text was updated successfully, but these errors were encountered: