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
- Resolution #1: Reject syntax#296 won’t fix as the spec isn’t broken, but add a note in the spec about implementation concerns
- Resolution #2: Close #297 wontfix, change is too extensive, and
@version
deals with most of the problem as is - Resolution #3: Earliest end of CR to be February 17th 2020
- Resolution #4: Request transition to CR, closing date of CfC is Monday 25th Nov, publication date of December 10th