JSON-LD Working Group Telco — Minutes

Date: 2020-01-10

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Gregg Kellogg, Ivan Herman, Pierre-Antoine Champin, Benjamin Young, Jeff Mixter

Regrets: Dave Longley, Ruben Taelman, Adam Soroka, David I. Lehn

Guests:

Chair: Rob Sanderson

Scribe(s): Benjamin Young

Content:

1. Approve minutes of previous call

Benjamin Young: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-12-20-json-ld

Proposed resolution: Approve https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-12-20-json-ld (Rob Sanderson)

Benjamin Young: +1

Rob Sanderson: +1

Gregg Kellogg: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Resolution #1: Approve https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-12-20-json-ld

2. Announcements / Reminders ?

Gregg Kellogg: I did see something come through from the Go implementation folks
… they are closing in on full compatibility with 1.1

Rob Sanderson: lovely!
… and not raising as many issues as the Perl implementation

Gregg Kellogg: often folks use both the tests and the spec to figure it out
… but sometimes it’s nice to have someone be pedantic about the spec on its own

Rob Sanderson: jeff_mixter did you want to mention the Mellon work?

Jeff Mixter: we’re working with the library community to build out a sort of central hub of entity descriptions
… primarily we’re focused on works and persons related to works–authors, etc.
… the relationship with the standards groups will be that we plan to follow all the data publishing guidelines
… and use JSON-LD 1.1 when we get there

Rob Sanderson: any questions about that?

Benjamin Young: is there a place to track that work?

Jeff Mixter: it was just announced, but I can share that stuff once I have it

3. Issues

Jeff Mixter: and you can reach out to me directly as I’m on the project

Rob Sanderson: there are two that we should discuss in detail

3.1. Handling @context IRI wording

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

Rob Sanderson: the reason we’ve called this one out in particular
… is that the two Greg(g)’s have different views on what the exact wording should be

Gregg Kellogg: yes. we went back and forth a bit
… and what Greg was pushing for seemed like a very large rewrite
… and dlongley chimed it a bit also
… and that size change didn’t seem warranted
… the core question is how to resolve a relative context URL
… that text is certainly more vague
… the base of the document is used to resolve that
… but that may not be explicitly passed in
… so dlongley suggested we add a note that we were avoiding being overly prescriptive
… and a few more notes to clarify the intent and use throughout that section
… and without changing the API signature
… given where we are in the publishing process, I don’t think a heavier change is warranted

Rob Sanderson: it wouldn’t be a normative change would it be?

Gregg Kellogg: it depends on what you believe the boundary of the change is
… if we’re changing API signatures and data that’s being passed around
… then that would be a normative change

Pierre-Antoine Champin: and that we might introduce new bugs…

Gregg Kellogg: there are ways implementations can work around this without our changing the API

Rob Sanderson: any questions/
… k. I would suggest that we reject this issue on the grounds that we believe this would be a breaking change
… while it might be clearer to do it the way Greg suggests, the current way works without needing to change API signatures

Gregg Kellogg: no. it actually change the API signature, but the algorithm signature
… but nonetheless it would have far reaching API ramifications

Rob Sanderson: pchampin what are your thoughts on this one?

Pierre-Antoine Champin: I’m with Greg on this one
… with gkellogg on this one
… the potential for new bugs is quite high

Proposed resolution: Reject #265 as overreaching at the current stage of the process; changing algorithm signatures has too far-reaching consequences for a clarity change (Rob Sanderson)

Ivan Herman: +1

Gregg Kellogg: +1

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Tim Cole: +1

Benjamin Young: +1

Jeff Mixter: +1

Resolution #2: Reject #265 as overreaching at the current stage of the process; changing algorithm signatures has too far-reaching consequences for a clarity change

Gregg Kellogg: I did mark the issue as rejected
… but I didn’t know if there was more to do to close this up

Rob Sanderson: we should call it out as an issue that was not accepted
… and point to this resolution as the rational for the rejection
… we’ve discussed it, considered it, and rejected the full extent of the change
… but we plan to add notes to clarify things to avoid future confusion

Ivan Herman: I checked with Ralph about what triggers a full CR or not
… and it’s largely under the control of the WG
… there’s no algorithm for when it should go back to the Director
… this one does seem to be on the borderline
… and it would restructure the algorithm heavily
… and all the other implementers would have to cross check things against the new changes
… if it’s a bug, then it would be justifiable

Rob Sanderson: it’s not wrong to implement it the way gkellogg has described it

Ivan Herman: no. of course not
… no one said they have to follow these algorithm lines specifically
… they just have to pass the tests

Gregg Kellogg: yes. we say that explicitly actually

Ivan Herman: and if they pass it without following all the algorithm steps, that’s fine

Rob Sanderson: any more on this one?

3.2. Possible bug in Expansion Algorithm step 13.4.16

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

Rob Sanderson: so the next one is issue 270
… after some discussion gkellogg believes the test is fixed
… and added two more tests
… but since we’re changing the tests, we do need to consider this as a group
… any change to the algorithm that doesn’t change the test results is fine
… but this one changes the test results…so we need to determine the weight of this one
… it doesn’t seem like a dropping us out of CR sort of change
… gkellogg can you elaborate?

Gregg Kellogg: there was a bug in my implementation based on my misinterpretation of my own text
… I’ll have to dig into it again more closely
… I’d misinterpreted what his concern was initially

Rob Sanderson: what I recall is that it was a null vs. empty list question
… and that the test results needed to test for whichever one it should have been rather than the other one

Gregg Kellogg: so the text had previously said if an input type was @json
… because null would be kept only in the case for @value when the type is @json
… that was a change to the algorithm text
… in terms of what the test result was…
… one of these was redundant
… expand 122 out. it had been an empty string…and should have stayed null
… so it partly related to that wrong step that shouldn’t have been in there

Rob Sanderson: so the good thing is that Greg agrees with these fixes
… so I think that we should have a resolution
… that there was essentially a typo in the test result
… and that we’re fixing it by tweaking both the algorithm and the test result
… and the issue submitter (Greg) agrees with this fix
… and that we agree this shouldn’t trigger a new CR
… my proposal, then, would be that we suggest a non-normative tweak to the algorithm text and fix what amounts to a typo in the tests

Ivan Herman: so, since as you say the algorithm is non-normative, then we should be fine
… certainly the algorithm and tests should be in sync

Rob Sanderson: pchampin you’re ok with this also?

Pierre-Antoine Champin: yes. it’s fine.

Rob Sanderson: so we should note that this would effect other implementation’s test results potentially

Proposed resolution: Accept #270 including both text change to the algorithm and fix to the expected test result, noting that this would potentially affect other implementations’ test results, but that we do not believe this requires re-entry to CR (Rob Sanderson)

Rob Sanderson: but that we do not believe this requires re-entry into CR

Gregg Kellogg: +1

Benjamin Young: +1

Jeff Mixter: +1

Tim Cole: +1

Pierre-Antoine Champin: +1

Rob Sanderson: +1

Resolution #3: Accept #270 including both text change to the algorithm and fix to the expected test result, noting that this would potentially affect other implementations’ test results, but that we do not believe this requires re-entry to CR

Ivan Herman: +1

3.3. Bulk Editorial Changes

Rob Sanderson: we have a lot of these…and I don’t think we need a resolution for each

Ivan Herman: exactly what I wanted to say

Rob Sanderson: so, if gkellogg and pchampin agree with the changes, then we should probably accept them en masse

Rob Sanderson: https://github.com/orgs/w3c/projects/4?fullscreen=true

Gregg Kellogg: most of them are already tagged commenter-agreed
… one does say it’s pending

Rob Sanderson: In the Editorial Work Complete column

Gregg Kellogg: another doesn’t have any tags…
… one is tagged propose-closing
… and two marked as PR pending
… and are awaiting feedback from Greg

Rob Sanderson: so, if you use this project link https://github.com/orgs/w3c/projects/4?fullscreen=true
… you can click through to each issue
… there seems to be general agreement throughout

Gregg Kellogg: some of these are straightforward…like things that fell off during a merge
… some do involve some haggling over words

Rob Sanderson: and at least one of these points to a test that should’ve probably been implemented
… 277 was about @language
… 278 was moving some text around assertions rather than errors
… 279 seems related to the earlier one about concatenation
… 289 a variable was reused

Gregg Kellogg: right, they needed to be made distinct

Rob Sanderson: 282…

Gregg Kellogg: that one needed a test as well
… the way the test was written it ignored something as an invalid triple
… but on a closer reading of the text, it should’ve thrown an error
… so this needs an expansion test

Rob Sanderson: so this one probably needs a separate resolution
… so my understanding of this issue is that the test used to be that for wellformedness…
… it should now track that a datatype with an IRI of null would throw an error

Gregg Kellogg: yeah. I was confusing these…it was a bit of an omnibus issue
… so I’m not sure this one had any test changes

Rob Sanderson: ah. it would still result in it not being valid…it just would’ve been caught earlier, correct?

Gregg Kellogg: right

Rob Sanderson: so if no tests change, we can keep going down the list
… 292…the expansion of null in @value…so it’s similar to the previous one

Gregg Kellogg: there was an earlier issue where words in the expansion algorithm moved
… and they run every time now vs. just at the end
… and that seems to have generated lots of these
… however, we did move that part back to the end
… but there were other changes to make sure all the content was part of an algorithmic step

Rob Sanderson: so, let’s keep digging for ones that may have normative changes…

Gregg Kellogg: so in 303, there was a previously correct result which is now flagged as an error

Rob Sanderson: I don’t think we need a resolution for that
… because no other system would do anything different

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

Rob Sanderson: so, here’s a framing issue

Gregg Kellogg: this is about the omitGraph flag
… it takes a boolean of course
… it was the default for 1.0
… so to get the correct 1.1 behavior, you now need to set omitGraph to false
… there was also the example that hadn’t been adequately updated
… Greg did agree with the changes in the end
… it is just a change to the example text at this point

Ivan Herman: so, for the future
… if there’s an editorial-based change, and the commenter agrees with those changes, then we could agree that in those cases gkellogg can close them

Gregg Kellogg: maybe we need a proposal that issues that do not result in a change to test behavior to which the commenter agrees can be merged without further discussion

Ivan Herman: yes. maybe such a list won’t happen again

Gregg Kellogg: well…Greg plans to do compaction

Ivan Herman: that’s fine, but I do think we should resolve to implement such a process

Rob Sanderson: so let’s do one proposal to cover all these issues we just rattled through

Proposed resolution: Accept editorial, commenter-agreed issues raised since last call (Rob Sanderson)

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Gregg Kellogg: +1

Benjamin Young: +1

Tim Cole: +1

Jeff Mixter: +1

Resolution #4: Accept editorial, commenter-agreed issues raised since last call

Gregg Kellogg: there are a few that aren’t strictly in this category
… 303 and framing/93

Benjamin Young: s/framing\/93/framing\/92

Proposed resolution: Accept and close #303 (test management), #92 (duplicate content in framing introduction) (Rob Sanderson)

Rob Sanderson: +1

Benjamin Young: +1

Gregg Kellogg: +1

Ivan Herman: +1

Tim Cole: +1

Resolution #5: Accept and close #303 (test management), #92 (duplicate content in framing introduction)

Pierre-Antoine Champin: +1

Proposed resolution: WG agrees that editors can resolve and close editorial issues that do not require changes to test results without WG intervention if the commenter agrees with the solution (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Tim Cole: +1

Benjamin Young: +1

Ivan Herman: +1

Resolution #6: WG agrees that editors can resolve and close editorial issues that do not require changes to test results without WG intervention if the commenter agrees with the solution

Ivan Herman: I won’t be generating the minutes this weekend, but we should be OK to go ahead with this resolution without them

Rob Sanderson: are there any other issues that need discussion?

Gregg Kellogg: there are a few others I think we can close quickly

Ivan Herman: the ones you mentions are indeed done

Rob Sanderson: and without a resolution, correct?
… they’re done…or we wouldn’t be in CR
… so yes, we’ll close them
… with 5 minutes…there’s probably not time to talk about Best Practices

Ivan Herman: I’m curious about a few other things also, like the CBOR note
… and whether we think we’ll see a C or C++ implementation

Gregg Kellogg: per Manu, I think there is a C or C++ implementation in progress

Ivan Herman: so we’ll have C/C++, Go, Ruby, JavaScript

Rob Sanderson: also Perl

Ivan Herman: and pchampin how’s Rust?

Pierre-Antoine Champin: sadly, I won’t be able to do that on my own
… but someone has commented on the list in November
… and I might try and help them, but I won’t be able to lead them

Ivan Herman: as I see it now, we’re in good shape to publish the specs before the end of our charter
… in parallel this whole Process 2020 will come out in the coming months
… so it may be a good conversation to have soon about what we do next
… so, for instance, the Verifiable Claims WG has been rechartered
… that sort of thing didn’t used to happen
… but now there’s a maintenance mode for groups
… and maybe we could consider that
… we have some other items we haven’t gotten too
… we don’t have to discuss it now, but soon

Rob Sanderson: agreed
… I’d be very surprised if there’s ever such a huge number of small issues like these again
… and Greg’s Perl implementation is down to less than 10 tests that don’t pass

Ivan Herman: do we know the state of the JS implementation?

Gregg Kellogg: I’ve been working on that, actually
… there are issues with the HTML tests
… because the XML DOM parsing library in use now eats the entity escapes
… and we have tests to make sure that doesn’t happen
… so those fail
… but I’m narrowing in on completion
… hopefully within the next month

Ivan Herman: sounds good

Rob Sanderson: and Python?

Gregg Kellogg: I’ve not begun on that yet, but that’s meant to be next, yes.

4. Adjourn

5. Resolutions