lazy-evaluation of 1.1 mode

[gkellogg]

As discussed at the F2F, we will consider making version announcement a suggestion, rather than a requirement, particularly where the feature would either be ignored or flagged by an existing 1.0 processor. We will evaluate the issues for 1.0 processors encountering 1.1 features without version announcement on a case-by-case basis. Version announcement remains a best-practice.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Accept changes after changing clause for explicit 1.1 for API #161, lazy evaluation of processing mode

View the transcript

Lazy evaluation of 1.1 processing mode
Rob Sanderson: #161
Gregg Kellogg: Also w3c/json-ld-syntax#284
Gregg Kellogg: w3c/json-ld-framing#76
Gregg Kellogg: #170
Rob Sanderson: It would be easier for version migration compliance to handle @version keyword lazily, and let processors detect them based on the features that are being used.
Gregg Kellogg: When we discussed it, the idea was that we would do feature detection, and move up to 1.1 when we saw that.
… If you are explicitly in 1.0 mode, then you don’t run any 1.1 features. If one such feature would be 1.1, then a 1.0 processor would terminate.
… This would happen in any case on old processors if they see unknown (new) features.
… The PRs describe this slight change and the necessary steps.
Dave Longley: +1 to gregg’s description of how lazy eval works
Rob Sanderson: There was a question about the tests to see if there were any issues.
Gregg Kellogg: There weren’t any exceptions. I just added a couple of tests.
… I’ve updated many tests that used to the processing mode explicitly, and things seem to work correctly.
Dave Longley: As we will probably will have a JSON-LD 1.2 at some point, we don’t want to lock down the version in the algorithm.
Ivan Herman: +1 dlongley
Gregg Kellogg: I agree.
Rob Sanderson: +1 as well
Rob Sanderson: Is this written like that in the PRs?
Dave Longley: +1 to remove those clauses
Gregg Kellogg: Yes, the PRs make it so that processing mode can be “unset”, which allows the silent upgrade.
Dave Longley: +1 to merge the PRs with the above changes
Ivan Herman: +1 for me, too
Gregg Kellogg: The conformance section describes changes to proc mode as well, besides the algorithmic changes.
Proposed resolution: Accept changes after changing clause for explicit 1.1 for API #161, lazy evaluation of processing mode (Rob Sanderson)
Rob Sanderson: +1
Gregg Kellogg: +1
Ruben Taelman: +1
Dave Longley: +1
David I. Lehn: +1
Pierre-Antoine Champin: +1
Resolution #3: Accept changes after changing clause for explicit 1.1 for API #161, lazy evaluation of processing mode
Gregg Kellogg: Another useful thing would be a doc/post about the process to update to 1.1.
Ivan Herman: We have to clarify that this is not just lazy evaluation, but it is better than just that.

[gkellogg]

The WG resolved to close the issue as completed.