Skip to content
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

If processing mode is json-ld-1.0, IRI-like terms should still be allowed to differ from their expanded forms #581

Open
niklasl opened this issue Dec 4, 2023 · 0 comments

Comments

@niklasl
Copy link
Contributor

niklasl commented Dec 4, 2023

In JSON-LD 1.1, IRI Expansion within a Context defines a rule with a Warning:

If a compact IRI is used as a term, it must expand to the value that compact IRI would have on its own when expanded. This represents a change to the original 1.0 algorithm to prevent terms from expanding to a different IRI, which could lead to undesired results.

This is reflected in the JSON-LD 1.1 Create Term Definition algorithm, which, in step 14.2.4 first says:

If the term contains a colon (:) anywhere but as the first or last character of term, or if it contains a slash (/) anywhere

But then step 14.2.4.2 unconditionally says:

If the result of IRI expanding term using local context, and defined, is not the same as the IRI mapping of definition, an invalid IRI mapping error has been detected and processing is aborted.

This of course works as expected if the processing mode is json-ld-1.1.

But if the processing mode is json-ld-1.0, step 14.2.4.2 should not throw an error. This is even specified in the test suite. The expansion tests 0026 and 0071, both of type jld:PositiveEvaluationTest, jld:ExpandTest, are explicitly for :specVersion "json-ld-1.0". It appears a verbatim implementation would fail on this.

If that is correct, this step of the algorithm needs an "Unless the processing mode is json-ld-1.0" condition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Errata
Development

No branches or pull requests

2 participants