Keyword pattern should error when used as a term

[gkellogg]

As recently discussed in #296 (comment), 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 (suggest 1.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).

[azaroth42]

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 ?

[iherman]

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.

[pchampin]

The @version issue is related, but not central to @gkellogg's proposal here.

[iherman]

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

View the transcript

Keyword pattern should error when used as a term
Rob Sanderson: #297
Gregg Kellogg: while discussing syntax#296, I pointed out why we chose to have a number in @version;
… ignoring keywords-like terms in the term definitions may cause the same problem in the future,
… so I proposed to reject them instead.
… If @version didn’t exist, 1.0 and 1.1 processors would generate different results by ignoring things.
… Publishers can prevent that by using a specific version.
… We are creating a pattern for future versions.
… So I agree we should close this issue as wontfix.
Dave Longley: do we throw an error if @version is not 1.1?
Gregg Kellogg: yes
… A future version would presumably allow 1.1 and something else (1.1, 2.0).
Proposed resolution: Close #297 wontfix, change is too extensive, and @version deals with most of the problem as is (Rob Sanderson)
Ivan Herman: +1
Rob Sanderson: +1
Dave Longley: re the problem raised in issue#296, internal representations might not evaluate exactly to 1.1 .
… What advice do we want to give to implementors?
Gregg Kellogg: I don’t think that this problem would happen in practice.
Pierre-Antoine Champin: 1.1 is not represented exactly in float representation, but I agree that the problem is very unlikely to happen
Benjamin Young: version numbers are not really numbers.
… I don’t think that future versions should use 1.* .
Proposed resolution: Close #297 wontfix, change is too extensive, and @version deals with most of the problem as is (Rob Sanderson)
Rob Sanderson: +1
Gregg Kellogg: +1
Gregg Kellogg: we should not put restrictions on future WG.
Pierre-Antoine Champin: +1
Benjamin Young: +1
Dave Longley: +1
Ivan Herman: +1
Resolution #2: Close #297 wontfix, change is too extensive, and @version deals with most of the problem as is
David I. Lehn: +1