PR Request for JSON-LD 1.1

[iherman]

Document title, URLs, estimated publication date

• JSON-LD 1.1
  • The Latest CR: https://www.w3.org/TR/2020/CR-json-ld11-20200417/
  • Expected publication date: 2020-05-05
• JSON-LD 1.1 Processing Algorithms and API
  • The Latest CR: https://www.w3.org/TR/2020/CR-json-ld11-api-20200417/
  • Expected publication date: 2020-05-05
• JSON-LD 1.1 Framing
  • The Latest CR: https://www.w3.org/TR/2020/CR-json-ld11-framing-20200417/
  • Expected publication date: 2020-05-05

Abstract

• https://www.w3.org/TR/2020/CR-json-ld11-20200417/#abstract
• https://www.w3.org/TR/2020/CR-json-ld11-api-20200417/#abstract
• https://www.w3.org/TR/2020/CR-json-ld11-framing-20200417/#abstract

Status

• https://www.w3.org/TR/2020/CR-json-ld11-20200417/#sotd
• https://www.w3.org/TR/2020/CR-json-ld11-api-20200417/#sotd
• https://www.w3.org/TR/2020/CR-json-ld11-framing-20200417/#sotd

Link to group's decision to request transition

• https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2020/2020-04-17-json-ld#resolution2

Changes

• https://www.w3.org/TR/2020/CR-json-ld11-20200417/#changes-from-10
• https://www.w3.org/TR/2020/CR-json-ld11-api-20200417/#changes-since-1-0-recommendation-of-16-january-2014
• https://www.w3.org/TR/2020/CR-json-ld11-framing-20200417/#changes-since-1-0-draft-of-30-august-2012 (Note: there were no changes on this document in CR phase.)

Requirements satisfied

No new requirements since the CR transition. For the CR exit criteria, see the "Implementation" section below.

Dependencies met (or not)

No extra dependencies since CR.

Wide Review

The WG has tracked the reviews in GitHub using issues.

• https://github.com/w3c/json-ld-api/issues?q=is:issue+is:closed+label:wr:spec-updated
• https://github.com/w3c/json-ld-syntax/issues?q=is:issue+is:closed+label:wr:spec-updated
• https://github.com/w3c/json-ld-framing/issues?q=is:issue+is:closed+label:wr:spec-updated

Issues addressed

See previous list of issues.

Formal Objections

None.

Implementation

A separate document collects all implementation reports submitted for the three documents:

• https://w3c.github.io/json-ld-api/reports/

Some comments to the report:

• Every feature pass the CR criteria (i.e., at least two independent implementation).
• The test suite includes entries for all features, including features for the previous version of JSON-LD (covered by the previous version of the Recommendation). The tables mark explicitly the features that are specific to the 1.1 version.
• The test suite includes entries for non-normative features, too. Those have been grayed in the table.
• Not all implementations implement all categories/documents; this depends on the implementation goals. E.g., the streaming parser for transforming to and from RDF does not implement framing, the various JSON-LD transformation, or the extraction of JSON-LD from HTML data blocks.
• There three implementation that implement all features with at least 94% of completeness.
• The WG would like to consider the test suite as a living document; new or updated reports for existing or completely new implementations may be submitted at a later point.

Patent disclosures

See https://www.w3.org/2004/01/pp-impl/107714/status

Additional notes

1. The Working Group has, in preparation, a charter proposal for a maintenance Working Group. That proposal is currently under horizontal review in Strategy, and the WG hopes to be able to submit it to an AC approval on or right after the PR has been published.

2. The upcoming Process 2020 has an additional feature for PR-s:

   A Proposed Recommendation may identify itself as intending to allow new features (class 4 changes) after its initial publication as a Recommendation, as described in § 6.2.11.4 Revising a Recommendation: New Features. Such an allowance cannot be added to a technical report previously published as a Recommendation that did not allow such changes.

   This Working Group would definitely like to evolve the future versions of this Recommendation along those lines (some features have already been identified as "postponed" see, e.g., for the syntax or for the API). The group seeks the Director's advice on how to make sure this is possible under the aforementioned maintenance group charter (i.e., whether such statement, or something along those lines, could be added to the PR publication itself or whether the language of the charter makes it possible already).

---

Cc: @gkellogg @pchampin @dlongley @BigBlueHat @azaroth42

[swickr]

While reviewing this transition request PLH and I found w3c/json-ld-syntax#340 and we tried to locate the WG discussion that supported the WG's conclusion that the addition of the explicit text in the syntax spec about the behavior of prefix:false is an editorial change. We were not successful in that quest. Therefore my question now is: in which steps of the processing algorithm is it clear that the new text in the syntax document comes from the prior CR expression of the algorithm?

We found test tp008 that appears relevant but that test notes that prefix:false is redundant in that particular case. Is there a test that shows a difference in behavior without a prefix entry and with prefix:false?

We see many changes in the processing algorithms in the API and Framing documents since the March version that was the subject of the previous transition request. These were also apparently considered editorial by the WG; however, they presumably came from questions that had been raised about the previous prose. Were any tests changed or added as a result of these clarifications? Were any implementations changed as a result of these clarifications?

[iherman]

CC: @gkellogg

[azaroth42]

Dear @swickr @plehegar,

There wasn't a formal resolution as we dispensed with them for editorial issues, but the WG discussed it in the 2020-03-20 meeting, for which I was the active chair:
https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2020/2020-03-20-json-ld#section2

As the definition of the processing for the flag is defined in the api document, my recollection is that the syntax document change was felt to be just an editorial reflection of that (unchanged) definition for pedagogical purposes, following the pattern established in the 1.0 specifications.

I'm sure that Gregg can provide further illumination!

[gkellogg]

We found test tp008 that appears relevant but that test notes that prefix:false is redundant in that particular case. Is there a test that shows a difference in behavior without a prefix entry and with prefix:false?

I don’t see where the test says that this is redundant. The test uses the following context:

{
 "@context": {
   "compact-iris": {"@id": "http://example.com/compact-iris#", "@prefix": false},
   "property": "http://example.com/property"
 }
}

The use of @prefix: false is needed, because otherwise comapct-iris could be used as a prefix, as "http://example.com/compact-iris#” ends with a fragment identifier, which is a gendelim.

GitHub indicates that this file was last changed over two years ago (July 23, 2018), and so was in-scope when the group decided that what mattered for being normative was that implementations pass the tests, and that any wording to support this was considered editorial.

We see many changes in the processing algorithms in the API and Framing documents since the March version that was the subject of the previous transition request. These were also apparently considered editorial by the WG; however, they presumably came from questions that had been raised about the previous prose. Were any tests changed or added as a result of these clarifications? Were any implementations changed as a result of these clarifications?

Our second CR was 2020-03-05. Since then we made the following changes that affect API tests

d9086e66 "Remove expand/e016, which is obsolete. This relates to changes to pr38 and pr39.”

2375e396 "Test html/e006 should be negative with "loading document failed”.”

988d2f7c "Update compact/pr02 context so that "protected" terms are futher differentiated.”

d292b6ae "Add expansion test where scoped context is a URL.” added expand/c034 to test remote scoped contexts

8299e263 "toRdf version of expand/c034.”

2418b1f4 "add test for the new error case” added expand/e052 to check that an empty term raises an exception, for which we had no test to back the normative restriction.

b55b0b98 "Move all expand/e0xx files to expand/erxx to avoid namespace issues to toRdf/e0xx which come from expand/00xx.”

b4297c52 aad6af40 a74c68bd e4681101 f1895db0 c0eee171 68226366 f6e3c567 91bab7bc f0197558 Synchronize expansion tests to toRdf

22ca62da "Add context recursion tests."

f829c791 "Update use of validate scoped contexts to skip only if false and the context is in the remote contexts array, which allows for validating scoped contexts when the term is defined up to the point that it has already been processed."

59bc33e1 e36c8d22 6dd160a0 "Add term scoping test”

3ed62e66 "Verify URI resolution relative to base without trailing slash”

2b8f6b03 "Add tests for invalid prefix values, Closes #432”

Most of these are to add missing coverage to describe normative behavior which was previously not tested.

f829c791for validate scoped contexts as part of PR #416 which was to deal with emergent context overflow issues. Not new behavior, but additional specification and testing to identify an issue which was implicit in the specs.

[swickr]

Thanks @gkellogg and @azaroth42. Regarding tp008 the test input says

"@Prefix false not really necessary, but doubly prevents term from being used as a prefix"

Regarding the question asked in Additional Note 2, though some new Working Group charters have been drafted that suggest the WG may use new Rec Track options that have been proposed for Process 2020 -- if those options are approved -- it is premature to include such forward-looking text in a Proposed Recommendation prior to the formal adoption of a new Process.

[swickr]

Transition approved.

[plehegar]

https://www.w3.org/TR/2020/PR-json-ld11-20200507/
https://www.w3.org/TR/2020/PR-json-ld11-api-20200507/
https://www.w3.org/TR/2020/PR-json-ld11-framing-20200507/