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:
- 1. Approve minutes of previous call
- 2. Issues
- 3. Misc
- 4. CR Preparation
- 5. Resolutions
- 6. Action Items
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
- Resolution #1: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-10-11-json-ld
- Resolution #2: Close all completed editorial actions
- Resolution #3: Accept changes after changing clause for explicit 1.1 for API #161, lazy evaluation of processing mode
- Resolution #4: Accept framing #74 as an oversight to be fixed for
@type
on node objects - Resolution #5: Defer framing #73 to future version, as new feature after the proposal window is closed