Update to make terms that have the form of a keyword errors.

[gkellogg]

If we decide we want to make keyword-like terms an error, this PR does that for the API.

For w3c/json-ld-syntax#297.

---

Preview | Diff

[pchampin]

Actually "MUST NOT have the form of a keyword" would be enough,
since all actual keywords also have the form of a keyword.
But it might be better to be explicit about the fact that we reject both actual keywords and would-be keywords.

[gkellogg]

That was my thinking. An implementation can always choose to do this optimization.

[gkellogg]

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: w3c/json-ld-syntax#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