16:22:48 <RRSAgent> RRSAgent has joined #json-ld
16:22:48 <RRSAgent> logging to https://www.w3.org/2020/01/10-json-ld-irc
16:22:50 <Zakim> RRSAgent, make logs Public
16:22:51 <Zakim> please title this meeting ("meeting: ..."), ivan
16:23:00 <ivan> Date: 2019-12-20
16:23:00 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2020Jan/thread.html
16:23:00 <ivan> ivan has changed the topic to: Meeting Agenda 2019-12-20: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Dec/0018.html
16:23:01 <ivan> Chair: azaroth
16:23:01 <ivan> Meeting: JSON-LD Working Group Telco
16:23:01 <ivan> Regrets+ dlongley
16:30:01 <azaroth> azaroth has joined #json-ld
16:34:49 <azaroth> azaroth has changed the topic to: Meeting Agenda 2020-01-10: https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Jan/0001.html
16:35:01 <azaroth> rrsagent, set log public
16:35:06 <azaroth> Meeting: JSON-LD Working Group Telco
16:35:14 <azaroth> Date: 2020-01-10
16:35:23 <azaroth> Agenda:  https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Jan/0001.html
16:35:30 <azaroth> Chair: azaroth
16:35:34 <azaroth> Regrets+ dlongley
16:35:47 <azaroth> Regrets+ rubensworks
16:35:54 <azaroth> present+
16:39:16 <azaroth> regrets+ ajs6f
16:50:18 <azaroth> agenda+ https://github.com/w3c/json-ld-api/issues/270
16:58:05 <gkellogg> gkellogg has joined #json-ld
16:58:36 <gkellogg> present+
17:01:09 <ivan> present+
17:01:33 <pchampin> pchampin has joined #json-ld
17:01:36 <pchampin> present+
17:02:08 <bigbluehat> present+
17:03:02 <azaroth> scribenick: bigbluehat
17:03:09 <dlehn> regrets+
17:03:20 <azaroth> TOPIC: Approve minutes of previous call
17:03:22 <jeff_mixter> jeff_mixter has joined #json-ld
17:03:26 <jeff_mixter> present+
17:03:27 <bigbluehat> https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-12-20-json-ld
17:03:31 <azaroth> PROPOSAL: Approve https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-12-20-json-ld
17:03:34 <bigbluehat> +1
17:03:34 <azaroth> +1
17:03:35 <gkellogg> +1
17:03:36 <pchampin> +1
17:03:40 <ivan> +1
17:03:41 <azaroth> RESOLVED: Approve https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-12-20-json-ld
17:03:52 <azaroth> TOPIC: Announcements / Reminders ?
17:04:06 <bigbluehat> gkellogg: I did see something come through from the Go implementation folks
17:04:13 <bigbluehat> ...they are closing in on full compatibility with 1.1
17:04:16 <bigbluehat> azaroth: lovely!
17:04:26 <bigbluehat> ...and not raising as many issues as the Perl implementation
17:04:38 <bigbluehat> gkellogg: often folks use both the tests and the spec to figure it out
17:04:49 <bigbluehat> ...but sometimes it's nice to have someone be pedantic about the spec on its own
17:05:07 <bigbluehat> azaroth: jeff_mixter did you want to mention the Mellon work?
17:05:23 <bigbluehat> jeff_mixter: we're working with the library community to build out a sort of central hub of entity descriptions
17:05:33 <bigbluehat> ...primarily we're focused on works and persons related to works--authors, etc.
17:05:56 <bigbluehat> ...the relationship with the standards groups will be that we plan to follow all the data publishing guidelines
17:06:03 <bigbluehat> ...and use JSON-LD 1.1 when we get there
17:06:14 <bigbluehat> azaroth: any questions about that?
17:06:22 <bigbluehat> bigbluehat: is there a place to track that work?
17:06:36 <timCole> timCole has joined #json-ld
17:06:42 <bigbluehat> jeff_mixter: it was just announced, but I can share that stuff once I have it
17:06:43 <azaroth> TOPIC: Issues
17:06:51 <bigbluehat> ...and you can reach out to me directly as I'm on the project
17:06:58 <bigbluehat> azaroth: there are two that we should discuss in detail
17:06:59 <azaroth> SUBTOPIC: Handling @context IRI wording
17:07:08 <azaroth> link:  https://github.com/w3c/json-ld-api/issues/265
17:07:18 <bigbluehat> ...the reason we've called this one out in particular
17:07:37 <bigbluehat> ...is that the two Greg(g)'s have different views on what the exact wording shoudl be
17:07:41 <bigbluehat> s/shoudl/should
17:07:47 <bigbluehat> gkellogg: yes. we went back and forth a bit
17:07:56 <bigbluehat> ...and what Greg was pushing for seemed like a very large rewrite
17:08:03 <bigbluehat> ...and dlongley chimed it a bit also
17:08:09 <bigbluehat> ...and that size change didn't seem warranted
17:08:18 <bigbluehat> ...the core question is how to resolve a relative context URL
17:08:27 <bigbluehat> ...that text is certainly more vague
17:08:38 <bigbluehat> ...the base of the document is used to resolve that
17:08:49 <bigbluehat> ...but that may not be explicitly passed in
17:09:04 <bigbluehat> ...so dlongley suggested we add a note that we were avoiding being overly prescriptive
17:09:19 <bigbluehat> ...and a few more notes to clarify the intent and use throughout that section
17:09:26 <bigbluehat> ...and without changing the API signature
17:09:48 <bigbluehat> ...given where we are in the publishing process, I don't think a heavier change is warranted
17:10:02 <bigbluehat> azaroth: it wouldn't be a normative change would it be?
17:10:20 <bigbluehat> gkellogg: it depends on what you believe the boundary of the change is
17:10:31 <bigbluehat> ...if we're changing API signatures and data that's being passed around
17:10:36 <bigbluehat> ...then that would be a normative change
17:10:44 <pchampin> and that we might introduce new bugs...
17:10:50 <bigbluehat> ...there are ways implementations can work around this without our changing the API
17:11:01 <bigbluehat> azaroth: any questions/
17:11:34 <bigbluehat> ...k. I would suggest that we reject this issue on the grounds that we believe this would be a breaking change
17:11:50 <bigbluehat> ...while it might be clearer to do it the way Greg suggests, the current way works without needing to change API signatures
17:12:11 <bigbluehat> gkellogg: no. it actually change the API signature, but the algorithm signature
17:12:25 <bigbluehat> ...but nonetheless it would have far reaching API ramifications
17:12:33 <bigbluehat> azaroth: pchampin what are your thoughts on this one?
17:12:45 <bigbluehat> pchampin: I'm with Greg on this one
17:12:58 <bigbluehat> ...with gkellogg on this one
17:13:09 <bigbluehat> ...the potential for new bugs is quite high
17:13:18 <azaroth> PROPOSAL: Reject #265 as overreaching at the current stage of the process; changing algorithm signatures has too far-reaching consequences for a clarity change
17:13:26 <ivan> +1
17:13:28 <gkellogg> +1
17:13:29 <azaroth> +1
17:13:29 <pchampin> +1
17:13:29 <timCole> +1
17:13:31 <bigbluehat> +1
17:13:31 <jeff_mixter> +1
17:13:44 <azaroth> RESOLVED: Reject #265 as overreaching at the current stage of the process; changing algorithm signatures has too far-reaching consequences for a clarity change
17:13:54 <bigbluehat> gkellogg: I did mark the issue as rejected
17:14:04 <bigbluehat> ...but I didn't know if there was more to do to close this up
17:14:16 <bigbluehat> azaroth: we should call it out as an issue that was not accepted
17:14:26 <bigbluehat> ...and point to this resolution as the rational for the rejection
17:14:38 <bigbluehat> ...we've discussed it, considered it, and rejected the full extent of the change
17:14:55 <bigbluehat> ...but we plan to add notes to clarify things to avoid future confusion
17:15:13 <bigbluehat> ivan: I checked with Ralph about what triggers a full CR or not
17:15:21 <bigbluehat> ...and it's largely under the control of the WG
17:15:33 <bigbluehat> ...there's no algorithm for when it should go back to the Director
17:15:43 <bigbluehat> ...this one does seem to be on the borderline
17:15:49 <bigbluehat> ...and it would restructure the algorithm heavily
17:16:01 <bigbluehat> ...and all the other implementers would have to cross check things against the new changes
17:16:12 <bigbluehat> ...if it's a bug, then it would be justifiable
17:16:27 <bigbluehat> azaroth: it's not wrong to implement it the way gkellogg has described it
17:16:32 <bigbluehat> ivan: no. of course not
17:16:42 <bigbluehat> ...no one said they have to follow these algorithm lines specifically
17:16:46 <bigbluehat> ...they just have to pass the tests
17:16:51 <bigbluehat> gkellogg: yes. we say that explicitly actually
17:17:04 <bigbluehat> ivan: and if they pass it without following all the algorithm steps, that's fine
17:17:07 <bigbluehat> azaroth: any more on this one?
17:17:11 <azaroth> SUBTOPIC: Possible bug in Expansion Algorithm step 13.4.16
17:17:17 <azaroth> link: https://github.com/w3c/json-ld-api/issues/270
17:17:20 <bigbluehat> azaroth: so the next one is issue 270
17:17:34 <bigbluehat> ...after some discussion gkellogg believes the test is fixed
17:17:38 <bigbluehat> ...and added two more tests
17:17:47 <bigbluehat> ...but since we're changing the tests, we do need to consider this as a group
17:17:57 <bigbluehat> ...any change to the algorithm that doesn't change the test results is fine
17:18:17 <bigbluehat> ...but this one changes the test results...so we need to determine the weight of this one
17:18:26 <bigbluehat> ...it doesn't seem like a dropping us out of CR sort of change
17:18:31 <bigbluehat> ...gkellogg can you elaborate?
17:18:48 <bigbluehat> gkellogg: there was a bug in my implementation based on my misinterpretation of my own text
17:19:13 <bigbluehat> ...I'll have to dig into it again more closely
17:19:21 <bigbluehat> ...I'd misinterpreted what his concern was initially
17:19:31 <bigbluehat> azaroth: what I recall is that it was a null vs. empty list question
17:19:46 <bigbluehat> ...and that the test results needed to test for whichever one it should have been rather than the other one
17:20:10 <bigbluehat> gkellogg: so the text had previously said if an input type was `@json`
17:20:28 <bigbluehat> ...because `null` would be kept only in the case for `@value` when the type is `@json`
17:20:38 <bigbluehat> ...that was a change to the algorithm text
17:20:49 <bigbluehat> ...in terms of what the test result was...
17:21:17 <bigbluehat> ...one of these was redundant
17:21:21 <ivan> ivan has left #json-ld
17:21:33 <bigbluehat> ...expand 122 out. it had been an empty string...and should have stayed null
17:21:45 <bigbluehat> ...so it partly related to that wrong step that shouldn't have been in there
17:22:07 <bigbluehat> azaroth: so the good thing is that Greg agrees with these fixes
17:22:16 <bigbluehat> ...so I think that we should have a resolution
17:22:27 <bigbluehat> ...that there was essentially a typo in the test result
17:22:38 <bigbluehat> ...and that we're fixing it by tweaking both the algorithm and the test result
17:22:48 <bigbluehat> ...and the issue submitter (Greg) agrees with this fix
17:22:57 <bigbluehat> ...and that we agree this shouldn't trigger a new CR
17:23:50 <bigbluehat> ...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
17:24:46 <bigbluehat> ivan: so, since as you say the algorithm is non-normative, then we should be fine
17:25:01 <bigbluehat> ...certainly the algorithm and tests should be in sync
17:25:20 <bigbluehat> azaroth: pchampin you're ok with this also?
17:25:21 <ivan> ivan has joined #json-ld
17:25:30 <bigbluehat> pchampin: yes. it's fine.
17:26:00 <bigbluehat> azaroth: so we should note that this would effect other implementation's test results potentially
17:26:09 <azaroth> PROPOSAL: Accept #270 including both text change to the algotithm 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
17:26:13 <bigbluehat> ...but that we do not believe this requires re-entry into CR
17:26:14 <gkellogg> +1
17:26:18 <bigbluehat> +1
17:26:20 <jeff_mixter> +1
17:26:23 <timCole> +1
17:26:25 <pchampin> +1
17:26:26 <azaroth> s/algotithm/algorithm/
17:26:28 <azaroth> +1
17:26:43 <azaroth> RESOLVED: 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
17:26:48 <ivan> +1
17:27:07 <azaroth> SUBTOPIC: Bulk Editorial Changes
17:27:26 <bigbluehat> azaroth: we have a lot of these...and I don't think we need a resolution for each
17:27:27 <gkellogg> q+
17:27:30 <bigbluehat> ivan: exactly what I wanted to say
17:27:37 <azaroth> ack gkellogg
17:27:55 <bigbluehat> azaroth: so, if gkellogg and pchampin agree with the changes, then we should probably accept them en masse
17:28:01 <azaroth> https://github.com/orgs/w3c/projects/4?fullscreen=true
17:28:06 <bigbluehat> gkellogg: most of them are already tagged commenter-agreed
17:28:10 <bigbluehat> ...one does say it's pending
17:28:11 <azaroth> In the Editorial Work Complete column
17:28:21 <bigbluehat> ...another doesn't have any tags...
17:28:27 <bigbluehat> ...one is tagged propose-closing
17:28:32 <bigbluehat> ...and two marked as PR pending
17:28:39 <bigbluehat> ...and are awaiting feedback from Greg
17:29:18 <bigbluehat> azaroth: so, if you use this project link https://github.com/orgs/w3c/projects/4?fullscreen=true
17:29:22 <bigbluehat> ...you can click through to each issue
17:29:50 <bigbluehat> ...there seems to be general agreement throughout
17:30:55 <bigbluehat> gkellogg: some of these are straightforward...like things that fell off during a merge
17:31:07 <bigbluehat> ...some do involve some haggling over words
17:31:41 <bigbluehat> azaroth: and at least one of these points to a test that should've probably been implemented
17:32:16 <bigbluehat> ...277 was about `@language`
17:32:30 <bigbluehat> ...278 was moving some text around assertions rather than errors
17:32:39 <bigbluehat> ...279 seems related to 278
17:32:50 <bigbluehat> s/278/the earlier one about concatenation
17:33:30 <bigbluehat> ...289 a variable was reused
17:33:40 <bigbluehat> gkellogg: right, they needed to be made distinct
17:33:45 <bigbluehat> azaroth: 282...
17:33:49 <bigbluehat> gkellogg: that one needed a test as well
17:34:02 <bigbluehat> ...the way the test was written it ignored something as an invalid triple
17:34:15 <bigbluehat> ...but on a closer reading of the text, it should've thrown an error
17:34:27 <bigbluehat> ...so this needs an expansion test
17:34:33 <bigbluehat> azaroth: so this one probably needs a separate resolution
17:35:03 <bigbluehat> ...so my understanding of this issue is that the test used to be that for wellformedness...
17:35:49 <bigbluehat> ...it should now track that a datatype with an IRI of null would throw an error
17:36:00 <bigbluehat> gkellogg: yeah. I was confusing these...it was a bit of an omnibus issue
17:36:14 <bigbluehat> ...so I'm not sure this one had any test changes
17:36:29 <bigbluehat> azaroth: ah. it would still result in it not being valid...it just would've been caught earlier, correct?
17:36:31 <bigbluehat> gkellogg: right
17:36:41 <bigbluehat> azaroth: so if no tests change, we can keep going down the list
17:39:15 <bigbluehat> ...292...the expansion of null in `@value`...so it's similar to the previous one
17:39:39 <bigbluehat> gkellogg: there was an earlier issue where words in the expansion algorithm moved
17:39:51 <bigbluehat> ...and they run every time now vs. just at the end
17:39:57 <bigbluehat> ...and that seems to have generated lots of these
17:40:06 <bigbluehat> ...however, we did move that part back to the end
17:40:25 <bigbluehat> ...but there were other changes to make sure all the content was part of an algorithmic step
17:41:30 <bigbluehat> azaroth: so, let's keep digging for ones that may have normative changes...
17:43:00 <bigbluehat> gkellogg: so in 303, there was a previously correct result which is now flagged as an error
17:43:07 <bigbluehat> azaroth: I don't think we need a resolution for that
17:43:13 <bigbluehat> ...because no other system would do anything different
17:44:44 <azaroth> https://github.com/w3c/json-ld-framing/issues/88
17:44:50 <bigbluehat> azaroth: so, here's a framing issue
17:44:59 <bigbluehat> gkellogg: this is about the omitGraph flag
17:45:06 <bigbluehat> ...it takes a boolean of course
17:45:12 <bigbluehat> ...it was the default for 1.0
17:45:25 <bigbluehat> ...so to get the correct 1.1 behavior, you now need to set omitGraph to false
17:45:44 <bigbluehat> ...there was also the example that hadn't been adequately updated
17:45:51 <bigbluehat> ...Greg did agree with the changes in the end
17:45:57 <bigbluehat> ...it is just a change to the example text at this point
17:46:11 <bigbluehat> ivan: so, for the future
17:46:48 <bigbluehat> ...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
17:47:13 <bigbluehat> gkellogg: 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
17:47:22 <bigbluehat> ivan: yes. maybe such a list won't happen again
17:47:33 <bigbluehat> gkellogg: well...Greg plans to do compaction
17:47:43 <bigbluehat> ivan: that's fine, but I do think we should resolve to implement such a process
17:47:53 <bigbluehat> azaroth: so let's do one proposal to cover all these issues we just rattled through
17:48:05 <azaroth> PROPOSAL: Accept editorial, commenter-agreed issues raised since last call
17:48:09 <azaroth> +1
17:48:11 <pchampin> +1
17:48:13 <ivan> +1
17:48:14 <gkellogg> +1
17:48:16 <bigbluehat> +1
17:48:19 <timCole> +1
17:48:21 <jeff_mixter> +1
17:48:23 <azaroth> RESOLVED: Accept editorial, commenter-agreed issues raised since last call
17:48:45 <bigbluehat> gkellogg: there are a few that aren't strictly in this category
17:48:51 <bigbluehat> ...303 and framing/93
17:49:13 <bigbluehat> s/framing\/93/framing\/92
17:49:24 <azaroth> PROPOSAL: Accept and close #303 (test management), #92 (duplicate content in framing introduction)
17:49:29 <azaroth> +1
17:49:30 <bigbluehat> +1
17:49:31 <gkellogg> +1
17:49:36 <ivan> +1
17:49:44 <timCole> +1
17:49:46 <azaroth> RESOLVED: Accept and close #303 (test management), #92 (duplicate content in framing introduction)
17:49:48 <pchampin> +1
17:50:30 <azaroth> PROPOSAL: 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
17:50:33 <gkellogg> +1
17:50:34 <azaroth> +1
17:50:37 <pchampin> +1
17:50:38 <timCole> +1
17:50:40 <bigbluehat> +1
17:50:49 <ivan> +1
17:50:51 <azaroth> RESOLVED: 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
17:52:12 <bigbluehat> ivan: I won't be generating the minutes this weekend, but we should be OK to go ahead with this resolution without them
17:52:27 <bigbluehat> azaroth: are there any other issues that need discussion?
17:52:46 <bigbluehat> gkellogg: there are a few others I think we can close quickly
17:52:53 <bigbluehat> ivan: the ones you mentions are indeed done
17:52:58 <bigbluehat> azaroth: and without a resolution, correct?
17:53:04 <bigbluehat> ...they're done...or we wouldn't be in CR
17:53:07 <bigbluehat> ...so yes, we'll close them
17:53:34 <bigbluehat> ...with 5 minutes...there's probably not time to talk about Best Practices
17:53:46 <bigbluehat> ivan: I'm curious about a few other things also, like the CBOR note
17:53:58 <bigbluehat> ...and whether we think we'll see a C or C++ implementation
17:54:17 <bigbluehat> gkellogg: per Manu, I think there is a C or C++ implementation in progress
17:54:44 <bigbluehat> ivan: so we'll have C/C++, Go, Ruby, JavaScript
17:54:52 <bigbluehat> azaroth: also Perl
17:54:59 <bigbluehat> ivan: and pchampin how's Rust?
17:55:05 <bigbluehat> pchampin: sadly, I won't be able to do that on my own
17:55:23 <bigbluehat> ...but someone has commented on the list in November
17:55:36 <bigbluehat> ...and I might try and help them, but I won't be able to lead them
17:56:10 <bigbluehat> ivan: as I see it now, we're in good shape to publish the specs before the end of our charter
17:56:23 <bigbluehat> ...in parallel this whole Process 2020 will come out in the coming months
17:56:31 <bigbluehat> ...so it may be a good conversation to have soon about what we do next
17:56:57 <bigbluehat> ...so, for instance, the Verifiable Claims WG has been rechartered
17:57:02 <bigbluehat> ...that sort of thing didn't used to happen
17:57:09 <bigbluehat> ...but now there's a maintenance mode for groups
17:57:13 <bigbluehat> ...and maybe we could consider that
17:57:22 <bigbluehat> ...we have some other items we haven't gotten too
17:57:29 <bigbluehat> ...we don't have to discuss it now, but soon
17:57:32 <bigbluehat> azaroth: agreed
17:57:44 <bigbluehat> ...I'd be very surprised if there's ever such a huge number of small issues like these again
17:58:04 <bigbluehat> ...and Greg's Perl implementation is down to less than 10 tests that don't pass
17:58:16 <bigbluehat> ivan: do we know the state of the JS implementation?
17:58:22 <bigbluehat> gkellogg: I've been working on that, actually
17:58:33 <bigbluehat> ...there are issues with the HTML tests
17:58:47 <bigbluehat> ...because the XML DOM parsing library in use now eats the entity escapes
17:58:55 <bigbluehat> ...and we have tests to make sure that doesn't happen
17:58:58 <bigbluehat> ...so those fail
17:59:08 <bigbluehat> ...but I'm narrowing in on completion
17:59:14 <bigbluehat> ...hopefully within the next month
17:59:18 <bigbluehat> ivan: sounds good
17:59:29 <bigbluehat> azaroth: and Python?
17:59:39 <bigbluehat> gkellogg: I've not begun on that yet, but that's meant to be next, yes.
18:00:00 <azaroth> TOPIC: Adjourn
18:00:49 <ivan> zakim, end meeting
18:00:49 <Zakim> As of this point the attendees have been azaroth, gkellogg, ivan, pchampin, bigbluehat, jeff_mixter, yeah-whatever
18:00:51 <Zakim> RRSAgent, please draft minutes
18:00:51 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/10-json-ld-minutes.html Zakim
18:00:54 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
18:00:58 <Zakim> Zakim has left #json-ld
18:01:03 <ivan> rrsagent, bye
18:01:03 <RRSAgent> I see no action items