Lazy eval version

[gkellogg]

Describe implicit behavior as being for JSON-LD 1.1, with overrides available if processingMode set explicitly to json-ld-1.0.

For w3c/json-ld-api#161.

---

Preview | Diff

[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: w3c/json-ld-api#161
Gregg Kellogg: Also #284
Gregg Kellogg: w3c/json-ld-framing#76
Gregg Kellogg: w3c/json-ld-api#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.