-
Notifications
You must be signed in to change notification settings - Fork 63
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
Type and schema definitions for @context are too loose #2022
Labels
validation
Topic related to Normative Parsing, Validation, Consumption
Comments
JKRhb
added
the
validation
Topic related to Normative Parsing, Validation, Consumption
label
May 18, 2024
github-actions
bot
added
the
needs-triage
Automatically added to new issues. TF should triage them with proper labels
label
May 18, 2024
egekorkan
removed
the
needs-triage
Automatically added to new issues. TF should triage them with proper labels
label
May 18, 2024
Pasting this in Playground results in JSON-LD validation error |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Dealing with the @context definition once more, I noticed that our JSON Schema currently allows for @context definitions that contain objects with non-string values (e.g.,
{"foo": 42}
, see here and the example TD below). However, passing the same TD into a JSON-LD processor (see here) leads to an error since according to JSON-LD, all values have to be strings.I therefore wonder if we could on the one hand fix the JSON Schema to enforce the usage of valid JSON-LD within TDs and, on the other hand, if we should make the type definition in the TD Specification a bit stricter for TD 2.0. While there are some restrictions on the shape of the key-value pairs of the Maps within the
@context
, I think there is no MUST requirement for a map entry to have values of typestring
. So maybe this is something we can revisit for the next version.Example Thing Description
The text was updated successfully, but these errors were encountered: