Closed gkellogg closed 4 years ago
I don't think this is reasonable to do at this stage. We've already loosened the requirement to have @version
at all. While I don't like making technical debt, I would be VERY surprised if JSON-LD 1.10 was ever a real thing, triggering the 1.1 == 1.10 issue. Given current run rate, 1.10 will be in about 40 years time, assuming there isn't a 2.0 before then. Thus the changes are mitigating against a risk that is almost certain to never occur.
When we discussed this last time, the decision was that @version: 1.1
exhibited the right behavior and future WGs could decide whether to do something different.
Further, I don't see any reason why @version
shouldn't have a new value for each version. That's the point, no? So I don't see any new evidence that the current spec is broken.
Alternatively: Could we reserve only two terms -- @context
and @version
?
I don't think this is reasonable to do at this stage. We've already loosened the requirement to have @version at all. While I don't like making technical debt, I would be VERY surprised if JSON-LD 1.10 was ever a real thing, triggering the 1.1 == 1.10 issue.
+1 to that. Actually... a future WG would simply make an error by using 1.10 instead of, say, 1.11.
So I don't see any new evidence that the current spec is broken.
+1 again.
The @version
issue is related, but not central to @gkellogg's proposal here.
This issue was discussed in a meeting.
RESOLVED: Close #297 wontfix, change is too extensive, and <code>@version</code> deals with most of the problem as is
@version;
@version
didn’t exist, 1.0 and 1.1 processors would generate different results by ignoring things.@version
is not 1.1?@version
deals with most of the problem as is (Rob Sanderson)@version
deals with most of the problem as is (Rob Sanderson)@version
deals with most of the problem as is
As recently discussed in https://github.com/w3c/json-ld-syntax/issues/296#issuecomment-553517533, the Create Term Definition algorithm issues a warning when a term has the pattern of a keyword, but isn't a keyword (
@1*ALPHA
).The syntax document says "a term SHOULD NOT start with an @ character followed exclusively by one or more ALPHA characters".
However, the reason
@version
was introduced was to prevent a 1.0 processor from mis-interpreting a 1.1 context. If we want to avoid having each new version use a different value for@version
(or any specific numeric value as illustrated by #296), simply ignoring such terms could leave room for future misrepresentation.We should revert to previous usage to say that terms MUST NOT take the form of a keyword (
@1*ALPHA
) and generate an error. This still allows IRI-like things to be ignored with a warning, such as{"@id": "@url"}
but would only prohibit@url
from being used as a term, itself.We could then modify the expected value of
@version
to be any numeric value (suggest1.1
, but test can simply be that it has a numeric value) and avoid potential issues in floating-point comparisons after transforming to an internal representation).