JSON-LD Working Group Telco — Minutes

Date: 2019-10-18

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Rob Sanderson, Ruben Taelman, Gregg Kellogg, Dave Longley, Jeff Mixter, Pierre-Antoine Champin

Regrets: Benjamin Young

Guests:

Chair: Rob Sanderson

Scribe(s): Ruben Taelman

Content:

Rob Sanderson: Call Last call of November will be skipped due to Thanksgiving.

1. Approve minutes of previous call

Proposed resolution: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-10-11-json-ld (Rob Sanderson)

Rob Sanderson: +1

Ruben Taelman: +1

Gregg Kellogg: +1

Dave Longley: +1

Ivan Herman: +1

Resolution #1: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-10-11-json-ld

2. Issues

2.1. Blanket approve “propose closing” to be closed

Rob Sanderson: https://github.com/orgs/w3c/projects/4?fullscreen=true&card_filter_query=label%3A%22propose+closing%22

Rob Sanderson: We should close all issues labelled with “propose closing”.

Proposed resolution: Close all completed editorial actions (Rob Sanderson)

Rob Sanderson: +1

Gregg Kellogg: +1

Ruben Taelman: +1

Jeff Mixter: +1

Ivan Herman: +1

Dave Longley: +1

David I. Lehn: +1

Resolution #2: Close all completed editorial actions

Rob Sanderson: People have weighed in on every issue, so we can safely close them.

2.2. Lazy evaluation of 1.1 processing mode

Rob Sanderson: https://github.com/w3c/json-ld-api/issues/161

Gregg Kellogg: Also https://github.com/w3c/json-ld-syntax/pull/284

Gregg Kellogg: https://github.com/w3c/json-ld-framing/pull/76

Gregg Kellogg: https://github.com/w3c/json-ld-api/pull/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.

2.3. @default for @type

Rob Sanderson: https://github.com/w3c/json-ld-framing/issues/74

Rob Sanderson: The only thing you can’t consider @default for is @type.

Gregg Kellogg: Also not @id.
… Framing was mentioned as the proper way to handle these cases, but it does not work right now.

Rob Sanderson: This fits with our general pattern to allow @type to allow more functionality and context, such as @container and @set.
… While our feature window is closed, we can consider this a bug.

Dave Longley: This is indeed an oversight, something we can fix.

Pierre-Antoine Champin: So the idea is that @type with @default would set the type on node object or value objects, or any of them?

Gregg Kellogg: I think only on node objects.
… We would have to check the algorithm.

Dave Longley: I think gkellogg is correct.

Rob Sanderson: Me too. Otherwise we would open up weird issues with @direction and @value.

Dave Longley: +1 to azaroth

Proposed resolution: Accept framing #74 as an oversight to be fixed for @type on node objects (Rob Sanderson)

Gregg Kellogg: +1

Jeff Mixter: +1

Rob Sanderson: +1

Ruben Taelman: +1

Dave Longley: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Resolution #4: Accept framing #74 as an oversight to be fixed for @type on node objects

2.4. Reframing relationships

Rob Sanderson: https://github.com/w3c/json-ld-framing/issues/73

Rob Sanderson: There’s a graph in the first example, and they want to restructure it so that the actor created has an event. But they can not do everything they want. This looks like a new feature, so we should defer this to the next version, or wontfix.

Gregg Kellogg: It begs the question: what is the purpose of framing?
… You could keep adding features to lead to a complex construct language.
… We should understand the boundaries of what framing is intended to do.
… best practices might describe how you can do more advanced things using sparql constructs.

Dave Longley: I would mark this as defer, for future discussion in a future version. We may not want to say outright that we don’t want this as a framing feature.

Rob Sanderson: We would likely say no, but agreed.

Proposed resolution: Defer framing #73 to future version, as new feature after the proposal window is closed (Rob Sanderson)

Dave Longley: +1

Rob Sanderson: +1

Ruben Taelman: +1

Gregg Kellogg: +1

Jeff Mixter: +1

Ivan Herman: +1

David I. Lehn: +1

Pierre-Antoine Champin: +1

Resolution #5: Defer framing #73 to future version, as new feature after the proposal window is closed

3. Misc

David I. Lehn: For best practices: jsonld.org site still points to old site, should we point to the new one?

Gregg Kellogg: Agreed, let’s do it like the prev specs.

David I. Lehn: How should we track new features after this WG?

Rob Sanderson: We should still file the issues, but don’t handle them at the moment.

Gregg Kellogg: We discussed this as TPAC, and it depends on evolution of WG into CG.
… We can pull back in the WG group into the existing CG.
… This would be a sustainable way to manage the issues in the CG, until a new WG is chartered.

Ivan Herman: I would postpone this issue for now.
… There are discussions that the process at W3C might change, before the charter of this group runs out.
… There may be a possibility to keep this WG alive at a low-scale, in maintenance mode.
… So I would wait a bit.
… People can still report issues in the repos. When we publish the recs, we will have to work out how to handle errata.
… I have tools from CSVW WG that we can reuse for errata.
… For now, just use WG repos.

Rob Sanderson: This was also discussed at chairs lunch.
… I can’t report on what was discussed.

Ivan Herman: I was there, but it was not really discussed.

4. CR Preparation

Ruben Taelman: what is timeline for implementations?

Ivan Herman: This will come back during the CR discussion, depends on where we are with that.

Rob Sanderson: You have best oversight on amount of editorial work to be done.

Gregg Kellogg: One of biggest remaining things is algorithmic folding, which pchampin works on.

Ivan Herman: It would be an editorial change.
… I would prefer to go to CR when that stuff is done.

Pierre-Antoine Champin: I agree, it’s only editorial, but there would be a substantial change.
… I wanted to wait until algorithms are stabilized.
… Because the folding stuff would be impacted by that.
… So once that’s done, we can go to CR.

Ivan Herman: So when?

Gregg Kellogg: End of November I think.

Ivan Herman: Can I set a proposal of 8th of November, we aim at voting to go to CR.
… Is that an acceptable goal?

Gregg Kellogg: I think we can do that.
… 15th of November may be better.

Ivan Herman: Ok. But we get near Thanksgiving.
… We have to prepare documents, and may have to have some calls.

Gregg Kellogg: Maybe we should do the 8th then.

Ivan Herman: Ok

Rob Sanderson: How long to those docs be prepared in advance?

Ivan Herman: Up to the WG. Usually five working days.

Rob Sanderson: 1st of November would be beginning of consensus.
… By then the documents would need to be fixed.
… Is that feasible?

Gregg Kellogg: Yes, if I work on editorial issue, and folding is for pchampin.

Ivan Herman: I’ve made this wiki page for things we have to collect.
… The request for CR simply means raising an issue at the specific repo.
… I hope the template has not changed, we may want to check that.
… Let me pick it up…

Ivan Herman: See CR submission template

Ivan Herman: I have no idea what exactly to write on focus on substantive changes.
… I need help for that.
… We have a set of changes in the document, right?

Gregg Kellogg: Yes, since last WG and since CG.

Ivan Herman: Great, let’s link to those.
… “Requirements satisfied”, not sure to write there either.

Action #1: add links to changes to CR request wiki page (Gregg Kellogg)

Gregg Kellogg: Requirements were fed from github issues.

Ivan Herman: CG github?

Gregg Kellogg: CG work began because of issues posted to CG repo. So those were requirements.

Ivan Herman: So we list that as requirements to WG.

Gregg Kellogg: We need to identify issues from CG we want to use.

Action #2: find CG issues and reference in CR request wiki page (Rob Sanderson)

Ivan Herman: “Wide review” is in issues, nothing via e-mail.
… Last thing is information on implementation acceptance criteria.

Gregg Kellogg: We want to give an adequate amount of time to let implementations update.

Ivan Herman: Three months from publication of CR?

Gregg Kellogg: Three months sounds fine to me.

Ivan Herman: What will our criteria be?

Gregg Kellogg: Standard is two implementations per feature.
… We still may want to think about the specific features, if we need it for those.

Ivan Herman: Yes, let’s do that later.
… We now have a set of tests for every feature.
… We can say we need two independent implementations for every feature to pass tests.
… gkellogg can you send me a mail with authoritative tests?

Gregg Kellogg: See Test summary, draft implementation report

Gregg Kellogg: Sure, they can also be found at the top of implementation report.

Ivan Herman: When we say “features”, they are tested.

Gregg Kellogg: Some tests will test more than one feature at a time.
… It requires looking at description of test to know what is being tested.
… tc023 is an example of many features.

Ivan Herman: I see test has a description of relevant features, so that’s ok.
… Can we say something about additional implementations?
… CR is asking for informative test saying how many impls we expect.
… Ruby, JS, and maybe C/C++?

Gregg Kellogg: Hopefully Java

Gregg Kellogg: See Developers section in https://json-ld.org

Dave Longley: Hopefully Python

Ruben Taelman: And one more JS/TypeScript, but not for compacting/framing.

5. Resolutions

6. Action Items