JSON-LD Working Group Telco — Minutes

Date: 2020-03-27

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Ivan Herman, Pierre-Antoine Champin, Gregg Kellogg, Ruben Taelman, Benjamin Young, David I. Lehn, Tim Cole

Regrets: Dave Longley

Guests:

Chair: Benjamin Young

Scribe(s): Rob Sanderson, Benjamin Young

Content:

1. Announcements / Reminders

1.1. Daylight savings and call times – March 29th next big change

Benjamin Young: DST madness ends on Sunday (for us at least)
… so we will go back to being in sync soon

1.2. Summary of recent changes from Gregg

Benjamin Young: Don’t think there have been any big changes?

Gregg Kellogg: A couple of changes. PA noted the preserve keyword wasn’t described. It’s a framing keyword used in expansion to support framing. So added a keyword to the API doc to describe that one. All the others are in the syntax document, and framing specific ones in framing
… Ruben noted the container definition didn’t include all of the possible container values, so we updated that
… And json-ld.js folks noted some URI issues they encountered and contributed some tests
… That’s pretty much it

Benjamin Young: Thank you for that! Any comments / questions?

2. Issues

2.1. Our collective future – WG “close” dates and future WG “maintenance” state options

Benjamin Young: Nope. On to issues…
… Ivan you have some thoughts on this?

Ivan Herman: One issue is whether we can settle everything to go to PR in a month
… what’s the standpoint on that one. I don’t have an answer, just a hope :)
… related to this, if we don’t think we can make it by the end of June for TR, the deadline for the group, we need to think about an extension to properly finish things
… for the extension I don’t think there will be a problem.
… If we don’t have enough implementations, then we know there are some in the making, so that could be just a couple of months.
… That sort of extension shouldn’t be a problem.
… So we should decide in the near future where we’re at
… These days it’s relatively widespread to recharter as a maintenance group
… we did that with VC not long ago
… I need to talk to PLH on Monday. If we do this, a new charter through the usual process, the current process is quite simple and fast
… you don’t have to rejoin the group, the IPR situation continues
… but the new process would force people to rejoin because of some obscure, arcane, IPR concerns
… so it would be good to do it under the current process, meaning to decide and send the charter to AC
… maintenance means no new recs planned. There are chairs, and we can have telcos when something comes up
… it’s the group that carries on with errata. We might also be able to have a quick turn around for a new version that takes care of errata, but also some new features
… for new features there is a CR for the new feature only
… so we need 2-3 implementations of the feature before it goes into the TR
… need to decide whether June is the deadline, and to decide if we want to go for a maintenance group
… decision time!

Benjamin Young: Related question – can we do both at the same time?

Ivan Herman: Good question … don’t have the answer. The maintenance group should come when the group ends, but maybe it can switch in when we go to PR as all technical work would be done
… lets decide on both separately

Rob Sanderson: so, for the technical recommendations this makes sense
… but what about notes?
… for streaming, could we publish that?
… if not, then maybe we shouldn’t go to maintenance
… but if so, then it’d be great to go to maintenance

Ivan Herman: let me try to find what we have

Ivan Herman: See VC WG’s charter

Ivan Herman: an example ^^ maintenance group earlier this year
… the deliverables include notes, so answer is probably yes we can issue notes

Benjamin Young: That would be great

Gregg Kellogg: In this case they did enumerate specific notes. Useful to allow for other notes as well, not specifically called out

Ivan Herman: Yes, true. I don’t think it’s a problem. Any WG can issue a note at any time
… True for us. The streaming note is not part of the charter, but no problem publishing it
… issue is with recommendations. The rest are cherries.

Gregg Kellogg: Two more parts. For the extension, strictly speaking we’ll have enough implementations to show conformance.
… for virtually every feature. There might be some where there’s some technical issue in getting there.
… could be achieved with some more effort, but we’ll see when we collect them.
… can collect ruby, python, javascript and update those shortly.
… then can leave it open for other groups to come in
… not /required/ for going to PR
… maintenance group can maintain the implementation report over time

Ivan Herman: absolutely

Gregg Kellogg: So implementations after the PR cut off can still appear

Ivan Herman: very true, it’s under the maintenance group. My strictly personal preference would be if we have 3 covered in the report by end of April, that we should just go ahead
… it makes things much cleaner. If some others come in later, then the report can be extended
… going through the hoops for extension would just complicate things

Gregg Kellogg: Would be good to send out request to see who wants to submit a report
… java is working on it. Go perhaps.
… dont’ really know at this stage, but nice to see what peoples’ intentions are
… could do it in a blog post
… Didn’t understand the process for maintenance in updating a rec?

Ivan Herman: the new process essentially has the groups being able to do some sort of extension on the current rec
… so strictly backwards compatible, but adding a new feature
… there’ll be a new name for something similar to CR for just the feature. We issue a new document with a delta for the new feature that we want to add
… then the CR-like period, but only looks at the delta
… with implementations we can then move it to PR-like phase
… the same as HTML5.whatever with a new element in it
… details was added without touching anything else, and now it’s part of the rec
… more complex context references for integrity … we could add that if it doesn’t invalidate any 1.1 data, we can do that
… I know only the high level, not the details

Benjamin Young: Should get to proposals
… trending option seems to leave us on current timeline, work towards charter for a maintenance group

Proposed resolution: continue on current WG timeline (closing on June 15th) and not submit for an extension (Benjamin Young)

Gregg Kellogg: +1

Ruben Taelman: +1

Rob Sanderson: +1

Benjamin Young: +1

Ivan Herman: +1

Pierre-Antoine Champin: +1

David I. Lehn: +1

Resolution #1: continue on current WG timeline (closing on June 15th) and *not submit for an extension*

Ivan Herman: I think for this, I agree with Gregg, we should reach out to implementers and get reports ASAP
… the perl implementation is there, so should be easy to get a report
… Gregg takes care of ruby … dlehn, if you can submit for javascript … and python?

Gregg Kellogg: And Ruben’s too

David I. Lehn: I haven’t run the test generation in a while, but should be working

Ivan Herman: Lets get them now. If we have the report ready, then great … we wait till the end of April to see if any other comes in

Gregg Kellogg: ncar working on rdflib

David I. Lehn: Helpful to update PHP to show still just 1.0 ?
… probably not too bad to make the tests work again … no intention to update to 1.1

Ivan Herman: It doesn’t hurt

Benjamin Young: There’s doubltess communities that would benefit from it
… PHP apps not going anywhere

David I. Lehn: I think we’ll need someone to update it

Benjamin Young: Having the tests run is a good way to get developers

Rob Sanderson: [discussion about PERL implementation]

Gregg Kellogg: suggest that in blog post we construct a poll for implementers … intend to submit report, intend to submit but not be complete, no intention to submit
… then push out on social media
… something the w3c uses?

Ivan Herman: WBS … but not brilliant

Ruben Taelman: wondering if there will be a point when the test suite will be frozen?
… nowadays there are some new tests added … but then implementation reports will be out of date
… and would need to be resubmitted if tests are missing. Good to freeze the suite so from then on, the new reports are final

Rob Sanderson: +1

Gregg Kellogg: I don’t think we did with earlier ones, but at some point we need to stop accepting changes
… currently in a review period, so can’t shut it off completely yet
… need to send a notification to the community that we’re not accepting updates after some date

Ivan Herman: we can have implementation report at end of april … the report would be frozen, but the test suite can continue

Gregg Kellogg: How far in advance of publishing the note are the tests for the note frozen
… to avoid rerunning and resubmitting tests, and then regenerating the note

Ivan Herman: Publish note adjacent to the PR request. Note is frozen and bound to a transition.

Gregg Kellogg: I think we should consider a date for the report, and then provide a period before that during which we don’t change the tests

Ruben Taelman: I think 1 or 2 weeks could be sufficient

Ivan Herman: Important that if we have a report, and we submit it, that we don’t touch the report during the vote for Rec
… from that point everything must be frozen
… otherwise something doesn’t work and we get push back from the AC

David I. Lehn: As far as the tests / report … we could tag the current test suite and say the report is for the tag
… we should continue to add tests as people find bugs
… want to generate more tests, for languages with code coverage, we can always find more tests to add
… for js there’s lots of opportunities for more tests. We shouldn’t not write those

Rob Sanderson: I was going to essentially say what dlehn just said
… we could say that the set of tests that we’ll report on is frozen as of whenever we pick
… and there’s always the possibility to add new tests
… but the question is about what shows up in the test reports
… and that looking weird if they’re out of sync
… we then make sure that anything run after a date, just don’t got into the report
… so maybe we freeze the report in a week?
… so folks prioritize what goes into it
… and so they don’t implement stuff not going into the report

Gregg Kellogg: I think freezing next week might be premature, but we could count back from the PR

Ivan Herman: Beginning of may is going to AC

Gregg Kellogg: When do we need to publish the implementation report note?

Rob Sanderson: If we publish April 30, we could freeze on April 16

Rob Sanderson: is April 30 ok, ivan?

Ivan Herman: For AC I would like to be beginning of May … so April 30 … no, I’m a pessimist … we should start the process with the director about April 15

Gregg Kellogg: Meaning we need to freeze the tests next week
… and that people need to send in before the 10th
… if we freeze, we can update after the fact … so long as we don’t change what is being reported
… there’s still sufficient for the director, and more evidence is for the AC process

Ivan Herman: yes … a note in a loose sense or a WG note. If it’s just a frozen document, that’s good enough

Gregg Kellogg: https://w3c.github.io/json-ld-api/reports/

Rob Sanderson: [discussion of ^^ report document]

Ruben Taelman: Still need to publish latest tests
… submitted report from serializer as well as toRDF
… will not pass all of the tests

Gregg Kellogg: Don’t need to pass all the tests, just need two passes for each tests
… provides useful information to know which features pass

Proposed resolution: freeze what tests are used to generate the report by April 3rd and encourage implementers to provide tests before April 10th. (Benjamin Young)

Rob Sanderson: +1

Gregg Kellogg: +1

Ivan Herman: +1

Benjamin Young: +1

Ruben Taelman: +1

Tim Cole: +1

David I. Lehn: +1

Resolution #2: freeze what tests are used to generate the report by April 3rd and encourage implementers to provide tests before April 10th.

Gregg Kellogg: Even people not making changes can submit reports

Ivan Herman: Maintenance group …

Proposed resolution: begin drafting a charter for a Maintenance Group (Benjamin Young)

Ivan Herman: +1

Gregg Kellogg: +1

Pierre-Antoine Champin: +1

Rob Sanderson: +1

Ruben Taelman: +1

Benjamin Young: +1

David I. Lehn: +1

Tim Cole: +1

Resolution #3: begin drafting a charter for a Maintenance Group

Ivan Herman: I will do this next week. shouldn’t be very complicated
… One practical thing …
… the past few days the W3C is moving to Zoom away from webex
… the question is if it is worth changing to zoom and forget webex
… last few months of the WG and people might be messed around, but long term if we have a maintenance group, then zoom is better than webex
… I’m neutral. You guys tell me what to do

Benjamin Young: I’m in all the chat systems anyway

Gregg Kellogg: Work on automation for zoom?
… like zakim type features

Ivan Herman: Not really, it replaces webex. It’s more stable and these days having video is psychologically good
… zoom 15-20 video in gallery just works

Rob Sanderson: +1

Gregg Kellogg: I’ll need to get dressed :D

Benjamin Young: Just a shirt
… How soon?

Proposed resolution: begin our move to Zoom starting with next week’s call (Benjamin Young)

Benjamin Young: +1

Ivan Herman: A matter of 15 minutes for me, so we can try next week

Ruben Taelman: +1

Gregg Kellogg: +1

Ivan Herman: +1

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Tim Cole: +1

Resolution #4: begin our move to Zoom starting with next week’s call

Ivan Herman: I will send the precise URL to the member only list

Benjamin Young: We’ll call it out in the minutes

2.2. Streaming progress, pull requests, and issues

Benjamin Young: https://github.com/w3c/json-ld-streaming/issues

Benjamin Young: Some issues … ruben, an overview?

Ruben Taelman: Should the note be locked around mid april?

Ivan Herman: No need. we can do it until june, or later with the maintenance group

Ruben Taelman: what has been done … added a test suite. PR for first implementation report from it.
… also a PR to add conformance section. Gregg commented on that.
… don’t know if that means everything else is okay?

Gregg Kellogg: You addressed everything :)

Ruben Taelman: so good to go

Gregg Kellogg: yes as far as i’m concerned

Ruben Taelman: a type issue from ivan?

Ivan Herman: Current document says that type must follow the context in case the type is affected by context
… okay, but I’m sure that people will be screwed up by this … better to say type must follow context always, even if it doesn’t actually matter in a particular case

Ruben Taelman: Yes agree.
… PA made some suggestions, agree with most of them. Can be merged as well
… unless there are any other comments?
…

Benjamin Young: Okay, we can have 5 minutes back
… reconvene next week on zoom

Rob Sanderson: .. thanks all

3. Are we all well?

4. Resolutions