JSON-LD Working Group Telco — Minutes

Date: 2019-11-15

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Gregg Kellogg, Dave Longley, Ivan Herman, David I. Lehn, Benjamin Young

Regrets:

Guests:

Chair: Rob Sanderson

Scribe(s): Pierre-Antoine Champin

Content:

Rob Sanderson: There was no minutes in the previous call.

Benjamin Young: last week’s meeting was informal, too few people.

1. Issues

1.1. @version and floating point values

Rob Sanderson: https://github.com/w3c/json-ld-syntax/issues/296

Rob Sanderson: https://github.com/w3c/json-ld-syntax/issues/297

Ivan Herman: we have voted for a feature freeze a long time ago.
… We shouldn’t change the version format now;
… this is not a bug, this is a feature request.

Rob Sanderson: as I understand, the argument against a floating point value is that
… implementations might not do the right thing when comparing 1.1 to 1.1 .
… So that could be considered as a bug.

Gregg Kellogg: I don’t see this as a feature request; it raises a potential problem with the spec.
… That said, I don’t think we should change it.

David I. Lehn: I stand by my comment that we should add a FAQ for this

Gregg Kellogg: The argument is described in details in the issue.
… One argument is that CBOR internal representation may cause problem.
… But I’m not for changing it.

Benjamin Young: I think we should add a note, to warn implementers against a naive handling of this number.

Rob Sanderson: +1 to gkellogg – we don’t put implementation considerations in the spec

Gregg Kellogg: in JSON it is unambiguous.
… The problem arises when it is converted to an internal representation,
… which is an implementation problem.

Benjamin Young: That’s why a note might be appropriate.

Gregg Kellogg: agreed

Rob Sanderson: I would suggest that such a note appear in the Best Practices document.
… Adding implementation notes in the spec seems like a slippery slope.

Ivan Herman: +1 to azaroth

Action #1: add note on representation of @version not being semantic versioning, and noting issues with comparing floating point values (Gregg Kellogg)

Gregg Kellogg: it seems a little trivial for BP.
… And the BP document is more targeted at data publishers than implementers.

Proposed resolution: Reject syntax#296 won’t fix as the spec isn’t broken, but add a note in the spec about implementation concerns (Rob Sanderson)

Rob Sanderson: +1

Ivan Herman: +1

Pierre-Antoine Champin: +1

Dave Longley: +1

David I. Lehn: +1

Gregg Kellogg: +1

Benjamin Young: +1

Resolution #1: Reject syntax#296 won’t fix as the spec isn’t broken, but add a note in the spec about implementation concerns

1.2. Keyword pattern should error when used as a term

Rob Sanderson: https://github.com/w3c/json-ld-syntax/issues/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

1.3. Media types / IANA

Rob Sanderson: I reached out to Heather Flanagan and Michelle Cotton.
… They found the problem interesting and said they would look at it.
… But I didn’t get any response.
… I suggest that we do not consider it as a blocker for going to CR.

Dave Longley: I think we agreed to that on the last call.

2. Test Suite location

glellogg: we had discussed about mirroring the test-suite at W3C,
… and returning the correct headers.
… This is our last chance to change the location of the test suite in the spec.

Ivan Herman: What I can do is a redirect from a directory at w3.org to github.
… Or I can set each individual test as a redirection, with the appropriate headers,
… but that would be a pain if there are many of them.

Gregg Kellogg: only a few (~20) have headers requirements.
… But we can set the headers in github.

Pierre-Antoine Champin: .. Other WG have solved this problem by hosting them elsewhere.

Gregg Kellogg: if we can put a .htaccess file on github,
… we can sync it on W3C – and have it apply the .htaccess.

Benjamin Young: do we expect the test suite to change much in the future?

Gregg Kellogg: in CR, we may have a lot of changes.
… (discussion about how the CG would handle that after the WG)

Ivan Herman: I’m in favor of leaving it in github,
… even if implementations have to fake something about the headers.
… I’m concerned about the burden of hosting them on w3.org.

Gregg Kellogg: https://w3c.github.io/json-ld-api/tests/remote-doc-manifest.jsonld

Gregg Kellogg: there are tests related to the content-type, or some headers;
… so implementers will require to setup an HTTP proxy to actually tests those things.

Rob Sanderson: In the Annotation testing, how did we make headers-related tests?

Benjamin Young: we used web platform tests.

Rob Sanderson: could we use web platform tests for the few of our tests that require setting headers?

Ivan Herman: the web platform tests targets in-browser APIs, this is not what we do.

Benjamin Young: Activity Streams set up their own server for the test suite.

Gregg Kellogg: that’s what json-ld.org did.
… We could consider developing a shim for the benefit of testers.

Rob Sanderson: using localhost, and convincing the system that it is something else, is usually nightmare.

Gregg Kellogg: the current workaround works, so let’s stick to it

3. CfC for CR

Rob Sanderson: there are no more issues; once the note we have decided to add is added, we can go to CR

Gregg Kellogg: ivan has a script for updating the contributors;
… maybe it should be run to take into account recent changes in WG membership?

Ivan Herman: I can do that, but that is editorial. We can discuss CR regardless.
… What we must decide is the minimum date of the CR end.
… This is a commitment to not move out of CR before that date.
… When are we confident to have a full recommendation?

Gregg Kellogg: we should leave enough time to implementors.

Ivan Herman: this is a minimal date, but that does not prevent us from delaying it,
… if someone comes up and asks us to wait.

Rob Sanderson: this is why I would prefer to set it earlier than later.

Proposed resolution: Earliest end of CR to be February 17th 2020 (Rob Sanderson)

Benjamin Young: +1

Rob Sanderson: +1

Gregg Kellogg: +1

Dave Longley: +1

David I. Lehn: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Resolution #3: Earliest end of CR to be February 17th 2020

Rob Sanderson: for the call for consensus, do we need to wait for the note for #296?

Gregg Kellogg: it is editorial.

Ivan Herman: I agree, this is not a problem.

Rob Sanderson: so we can start the CFC now, until?

Ivan Herman: last chance to make changes to the wiki page
… I think that, with Thanksgiving, 10th of December is a reasonable publication date
… (discussion on ReSpec)

Proposed resolution: Request transition to CR, closing date of CfC is Monday 25th Nov, publication date of December 10th (Rob Sanderson)

Rob Sanderson: +1

Dave Longley: +1

Benjamin Young: +1

Pierre-Antoine Champin: +1

Gregg Kellogg: +1

David I. Lehn: +1

Ivan Herman: +1

Resolution #4: Request transition to CR, closing date of CfC is Monday 25th Nov, publication date of December 10th

4. AOB?

Ivan Herman: will we have a primer or any other document?
… If it will not happen, we can close the WG early once the REC is out.

Benjamin Young: the BP was on Adam and me,
… Adam is gone and I have said yes to many other things;
… I intend to put more time into it, and submit it to CG.

Pierre-Antoine Champin: I have to check with Victor Charpennay about the CBOR-LD note

Rob Sanderson: in the CR phase and after, there won’t be a lot of things for the WG to do
… We can have 1/2h meeting in that time, and focus on the BP document.

Benjamin Young: if any of you had some BP things, an article you wrote, a presentation you gave,
… putting this in the BP issue would be super helpful.
… It would be good to get feedback from the WG during future meetings.

Gregg Kellogg: I may have some blog posts that could be repurposed in BP.

Rob Sanderson: action azaroth to fill out requirements on wiki page

Action #2: fill out requirements on wiki page (Rob Sanderson)

Ivan Herman: something else; in the Wiki page, there is a “Requirements satisfied” section

Gregg Kellogg: all requirements are captured as issues

Ivan Herman: so using github magic, it should be possible to add a single link to all of them

5. Resolutions

6. Action Items