search

w3c / transitions

W3C Transitions
https://www.w3.org/Guide/transitions/
72 stars 30 forks source link

PR Request for JSON-LD 1.1 #239

Closed iherman closed 4 years ago

iherman commented 4 years ago

Document title, URLs, estimated publication date

Abstract

Status

Link to group's decision to request transition

Changes

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.

Issues addressed

See previous list of issues.

Formal Objections

None.

Implementation

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

Some comments to the report:

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 commented 4 years ago

While reviewing this transition request PLH and I found https://github.com/w3c/json-ld-syntax/pull/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 commented 4 years ago

CC: @gkellogg

azaroth42 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Transition approved.

plehegar commented 4 years ago

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/