16:14:16 <RRSAgent> RRSAgent has joined #json-ld
16:14:16 <RRSAgent> logging to https://www.w3.org/2019/11/15-json-ld-irc
16:14:17 <ivan> rrsagent, set log public
16:14:17 <ivan> Meeting: JSON-LD Working Group Telco
16:14:17 <ivan> Date: 2019-11-15
16:14:17 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Nov/0016.html
16:14:17 <ivan> ivan has changed the topic to: Meeting Agenda 2019-11-15: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Nov/0016.html
16:14:18 <ivan> Chair: azaroth
16:14:18 <ivan> Regrets+ bigbluehat
16:51:19 <pchampin> pchampin has joined #json-ld
16:55:33 <azaroth> azaroth has joined #json-ld
16:57:16 <azaroth> present+
16:59:33 <gkellogg> gkellogg has joined #json-ld
17:00:31 <gkellogg_> gkellogg_ has joined #json-ld
17:00:57 <gkellogg> present+
17:01:05 <dlongley> present+
17:01:38 <ivan> present+
17:02:01 <azaroth> regrets+ bigbluehat
17:02:30 <azaroth> TOPIC: Scribe Selection
17:02:44 <dlehn> present+
17:02:46 <azaroth> scribenick: pchampin
17:03:18 <azaroth> regrets- bigbluehat
17:03:26 <pchampin> azaroth: There was no minutes in the previous call.
17:03:30 <azaroth> TOPIC: Issues
17:03:34 <ivan> present+ bigbluehat
17:03:46 <pchampin> bigbluehat: last week's meeting was informal, too few people.
17:03:51 <azaroth> SUBTOPIC: @version and floating point values
17:04:01 <azaroth> https://github.com/w3c/json-ld-syntax/issues/296
17:04:03 <ivan> q+
17:04:04 <azaroth> https://github.com/w3c/json-ld-syntax/issues/297
17:04:10 <azaroth> ack ivan
17:04:27 <pchampin> ivan: we have voted for a feature freeze a long time ago.
17:04:42 <gkellogg> q+
17:04:43 <pchampin> ... We shouldn't change the version format now;
17:04:55 <pchampin> ... this is not a bug, this is a feature request.
17:05:18 <pchampin> azaroth: as I understand, the argument against a floating point value is that
17:05:30 <pchampin> ... implementations might not do the right thing when comparing 1.1 to 1.1 .
17:05:36 <pchampin> ... So that could be considered as a bug.
17:05:49 <azaroth> ack gkellogg
17:06:21 <pchampin> gkellogg: I don't see this as a feature request; it raises a potential problem with the spec.
17:06:34 <bigbluehat> q+
17:06:34 <pchampin> ... That said, I don't think we should change it.
17:06:47 <dlehn> i stand by my comment that we should add a FAQ for this
17:07:14 <pchampin> ... The argument is described in details in the issue.
17:07:30 <pchampin> ... One argument is that CBOR internal representation may cause problem.
17:07:43 <azaroth> ack bigbluehat
17:08:01 <pchampin> ... But I'm not for changing it.
17:08:35 <pchampin> bigbluehat: I think we should add a note, to warn implementers against a naive handling of this number.
17:08:57 <azaroth> +1 to gkellogg -- we don't put implementation considerations in the spec
17:09:09 <pchampin> gkellogg: in JSON it is unambiguous.
17:09:15 <pchampin> ... The problem araises when it is converted to an internal representation,
17:09:22 <pchampin> ... which is an implementation problem.
17:09:24 <azaroth> q?
17:09:41 <azaroth> q+ to agree best practice
17:10:01 <pchampin> bigbluehat: That's why a note might be appropriate.
17:10:12 <azaroth> ack azaroth
17:10:12 <Zakim> azaroth, you wanted to agree best practice
17:10:16 <pchampin> gkellogg: agreed
17:10:48 <pchampin> azaroth: I would suggest that such a note appear in the Best Practices document.
17:11:03 <ivan> +1 to azaroth
17:11:04 <gkellogg> action: gkellogg to add note on representation of `@version` not being semver, and noting issues with comparing floating point values
17:11:08 <pchampin> ... Adding implementation notes in the spec seems like a slipery slope.
17:11:10 <azaroth> q?
17:11:22 <bigbluehat> note might just say "Careful how you compare these things. They ain't actually numbers, kids. ;-P"
17:11:34 <bigbluehat> s/note might just say "Careful how you compare these things. They ain't actually numbers, kids. ;-P"//
17:11:39 <bigbluehat> q+
17:11:53 <bigbluehat> q-
17:11:54 <pchampin> gkellogg: it seems a little trivial for BP.
17:12:07 <pchampin> ... And the BP document is more targetted at data publishers than implementers.
17:13:01 <azaroth> PROPOSAL: Reject syntax#296 won't fix as the spec isn't broken, but add a note in the spec about implementation concerns
17:13:08 <azaroth> +1
17:13:09 <ivan> +1
17:13:10 <pchampin> +1
17:13:15 <dlongley> +1
17:13:26 <dlehn> +1
17:13:37 <gkellogg> +1
17:13:40 <bigbluehat> +1
17:13:40 <azaroth> RESOLVED: Reject syntax#296 won't fix as the spec isn't broken, but add a note in the spec about implementation concerns
17:13:57 <azaroth> https://github.com/w3c/json-ld-syntax/issues/297
17:14:33 <ivan> Subtopic: Keyword pattern should error when used as a term
17:14:47 <pchampin> gellogg: while discussing syntax#296, I pointed out why we chose to have a number in `@version`;
17:15:16 <bigbluehat> s/gellogg/gkellogg
17:15:41 <pchampin> ... ignoring keywords-like terms in the term definitions may cause the same problem in the future,
17:15:59 <pchampin> ... so I proposed to reject them instead.
17:16:42 <pchampin> ... If `@version` didn't exist, 1.0 and 1.1 processors would generate different results by ignoring things.
17:16:53 <pchampin> ... Publishers can prevent that by using a specific version.
17:17:08 <pchampin> ... We are creating a pattern for future versions.
17:17:32 <azaroth> q?
17:17:38 <pchampin> ... So I agree we should close this issue as wontfix.
17:17:46 <dlongley> q+
17:17:50 <azaroth> ack dlongley
17:18:08 <pchampin> dlongley: do we throw an error if `@version` is not 1.1?
17:18:15 <pchampin> gkellogg: yes
17:18:40 <pchampin> ... A future version would presumably allow 1.1 and something else (1.1, 2.0).
17:18:53 <azaroth> PROPOSAL: Close #297 wontfix, change is too extensive, and `@version` deals with most of the problem as is
17:18:58 <dlongley> q+
17:19:01 <ivan> +1
17:19:02 <azaroth> ack dlongley
17:19:06 <azaroth> +1
17:20:21 <gkellogg> q+
17:20:31 <azaroth> ack gkellogg
17:20:46 <pchampin> dlongley: re the problem raised in issue#296, internal representations might not evaluate exactly to 1.1 .
17:21:07 <pchampin> ... What advice do we want to give to implementors?
17:21:45 <pchampin> gkellogg: I don't think that this problem would happen in *practice*.
17:22:14 <pchampin> q+
17:22:39 <azaroth> ack pchampin
17:22:59 <bigbluehat> q+
17:23:22 <azaroth> ack bigbluehat
17:24:01 <pchampin> pchampin: 1.1 is *not* represented exactly in float representation, but I agree that the problem is very unlikely to happen
17:24:12 <pchampin> bigbluehat: version numbers are not really numbers.
17:24:30 <pchampin> ... I don't think that future versions should use 1.* .
17:24:37 <azaroth> PROPOSAL: Close #297 wontfix, change is too extensive, and `@version` deals with most of the problem as is
17:24:40 <azaroth> +1
17:24:42 <gkellogg> +1
17:24:43 <pchampin> gkellogg: we could put restrictions on future WG.
17:24:44 <pchampin> +1
17:24:50 <bigbluehat> +1
17:24:54 <dlongley> +1
17:24:57 <ivan> +1
17:25:04 <azaroth> RESOLVED: Close #297 wontfix, change is too extensive, and `@version` deals with most of the problem as is
17:25:04 <dlehn> +1
17:25:08 <pchampin> s/we could/we should not/
17:25:27 <azaroth> TOPIC: Media types / IANA
17:25:36 <azaroth> s/TOPIC/SUBTOPIC/
17:26:06 <pchampin> azaroth: I reached out to Heather Flanigan and Michelle XXX
17:26:07 <gkellogg> q+ to add another agenda item on test suite location
17:26:20 <azaroth> s/XXX/Cotton./
17:26:31 <pchampin> ... They found the problem interesting and said they would look at it.
17:27:00 <pchampin> ... But I didn't get any response.
17:27:21 <azaroth> q?
17:27:24 <pchampin> ... I suggest that we do not consider it as a blocker for going to CR.
17:27:38 <pchampin> dlongley: I think we agreed to that on the last call.
17:27:48 <azaroth> TOPIC: CfC for moving to CR
17:27:59 <azaroth> ack gkellogg
17:27:59 <Zakim> gkellogg, you wanted to add another agenda item on test suite location
17:28:06 <azaroth> TOPIC: Test Suite location
17:28:44 <pchampin> glellogg: we had discussed about mirroring the test-suite at W3C,
17:28:58 <pchampin> ... and returning the correct headers.
17:29:13 <pchampin> ... This is our last chance to change the location of the test suite in the spec.
17:29:40 <pchampin> ivan: What I can do is a redirect from a directory at w3.org to github.
17:30:01 <bigbluehat> q+
17:30:05 <pchampin> ... Or I can set each individual test as a redirection, with the appropriate headers,
17:30:15 <pchampin> ... but that would be a pain if there are many of them.
17:30:28 <pchampin> gkellogg: only a few (~20) have headers requirements.
17:30:55 <pchampin> ... But we can set the headers in github.
17:31:03 <azaroth> q?
17:31:12 <pchampin> .. Other WG have solved this problem by hosting them eslewhere.
17:32:04 <azaroth> ack bigbluehat
17:32:19 <pchampin> gkellog: if we can put a .htaccess file on github,
17:33:02 <pchampin> ... we can sync it on W3C -- and have it apply the .htaccess.
17:33:19 <pchampin> bigbluehat: do we expect the test suite to change much in the future?
17:33:35 <pchampin> gkellogg: in CR, we may have a lot of changes.
17:34:36 <pchampin> ... (discussion about how the CG would handle that after the WG)
17:34:57 <pchampin> ivan: I'm in favour of leaving it in github,
17:35:01 <bigbluehat> q+
17:35:06 <azaroth> ack bigbluehat
17:35:08 <pchampin> ... even if implementations have to fake something about the headers.
17:35:24 <pchampin> ... I'm concerned about the burden of hosting them on w3.org.
17:35:37 <gkellogg> https://w3c.github.io/json-ld-api/tests/remote-doc-manifest.jsonld
17:35:53 <azaroth> q+
17:36:29 <pchampin> gkellogg: there are tests related to the content-type, or some headers;
17:36:52 <pchampin> ... so implementers will require to setup an HTTP proxy to actually tests those things.
17:36:53 <azaroth> ack azaroth
17:37:30 <ivan> s/eslewhere/elsewhere/
17:37:47 <pchampin> azaroth: In the Annotation testing, how did we make headers-related tests?
17:38:06 <pchampin> bigbluehat: we used web platform tests.
17:38:47 <pchampin> azaroth: could we use web platform tests for the few of our tests that require setting headers?
17:39:02 <pchampin> ivan: the web platform tests targets in-browser APIs, this is not what we do.
17:40:13 <pchampin> bigbluehat: Activity Streams set up their own server for the test suite.
17:40:32 <pchampin> gkellogg: that's what json-ld.org did.
17:41:15 <pchampin> ... We could consider developing a shim for the benefit of testers.
17:42:11 <pchampin> azaroth: using localhost, and convincing the system that it is something esle, is usually nightmare.
17:42:46 <azaroth> TOPIC: CfC for CR
17:43:00 <pchampin> gkellogg: the current workaround works, so let's stick to it
17:43:05 <gkellogg> q+
17:43:20 <azaroth> ack gkellogg
17:43:44 <pchampin> azaroth: there are no more issues; once the note we have decided to add is added, we can go to CR
17:44:03 <pchampin> gkellogg: ivan has a script for updating the contributors;
17:44:31 <pchampin> ... maybe it should be run to take into account recent changes in WG membership?
17:44:53 <pchampin> ivan: I can do that, but that is editorial. We can discuss CR regardless.
17:45:07 <pchampin> ... What we must decide is the minimum date of the CR end.
17:46:04 <pchampin> ... This is a commitment to not move out of CR before that date.
17:46:09 <gkellogg> q+
17:46:13 <azaroth> ack gkellogg
17:46:19 <pchampin> ... When are we confident to have a full recommendation?
17:46:37 <pchampin> gkellogg: we should leave enough time to implementors.
17:47:14 <pchampin> ivan: this is a *minimal* date, but that does not prevent us from delaying it,
17:47:25 <pchampin> ... if someone comes up and asks us to wait.
17:47:46 <pchampin> azaroth: this is why I would prefer to set it earlier than later.
17:48:35 <azaroth> PROPOSAL: Earliest end of CR to be February 17th 2020
17:48:38 <bigbluehat> +1
17:48:39 <azaroth> +1
17:48:40 <gkellogg> +1
17:48:41 <dlongley> +1
17:48:43 <dlehn> +1
17:48:44 <pchampin> +1
17:49:01 <ivan> +1
17:49:03 <azaroth> RESOLVED: Earliest end of CR to be February 17th 2020
17:49:42 <pchampin> azaroth: for the call for consensus, do we need to wait for the note for #296?
17:49:54 <pchampin> gkellogg: it is editorial.
17:50:02 <pchampin> ivan: I agree, this is not a problem.
17:50:46 <pchampin> azaroth: so we can start the CFC now, until?
17:51:15 <ivan> https://github.com/w3c/json-ld-wg/wiki/%5BJSON-LD-WG%5D-CR-transition-for-json-ld11,-json-ld11-api,-and-json-ld11-framing
17:51:54 <pchampin> ivan: last chance to make changes to that wiki page
17:52:53 <pchampin> ... I think that, with Thanksgiving, 10th of December is a reasonable publication date
17:54:28 <pchampin> ... (discussion on ReSpec)
17:54:36 <azaroth> PROPOSAL: Request transition to CR, closing date of CfC is Monday 25th Nov, publication date of December 10th
17:54:41 <azaroth> +1
17:54:53 <dlongley> +1
17:54:56 <bigbluehat> +1
17:54:57 <pchampin> +1
17:54:59 <gkellogg> +1
17:55:04 <dlehn> +1
17:55:23 <ivan> +1
17:56:04 <azaroth> RESOLVED: Request transition to CR, closing date of CfC is Monday 25th Nov, publication date of December 10th
17:56:26 <azaroth> TOPIC: AOB?
17:56:53 <pchampin> ivan: will we have a primer or any other document?
17:57:13 <pchampin> ... If it will not happen, we can close the WG early once the REC is out.
17:57:23 <bigbluehat> q+
17:57:23 <pchampin> q+
17:57:26 <azaroth> ack bigbluehat
17:57:35 <azaroth> q+
17:58:23 <pchampin> bigbluehat: the BP was on Adam and me,
17:58:38 <pchampin> ... Adam is gone and I have said yes to many other things;
17:58:53 <azaroth> q?
17:58:54 <azaroth> ack pchampin
17:59:12 <pchampin> ... I intend to put more time into it, and submit it to CG.
17:59:48 <azaroth> q?
17:59:50 <azaroth> ack azaroth
17:59:55 <pchampin> pchampin: I have to check with Victor Charpennay about the CBOR-LD note
18:00:42 <bigbluehat> q+
18:00:48 <pchampin> azaroth: in the CR phase and after, there is a lot of thing for the WG to do
18:01:13 <ivan> q+ on another topic
18:01:16 <azaroth> ack bigbluehat
18:01:52 <pchampin> ... We can have 1/2h meeting in that time, and focus on the BP document.
18:02:11 <gkellogg> q+
18:02:17 <pchampin> benjamin: if any of you had some BP things, an article you wrote, a presentation you gave,
18:02:31 <pchampin> ... putting this in the BP issue would be super helpful.
18:02:51 <azaroth> ack gkellogg
18:03:11 <pchampin> ... It would be good to get feedback from the WG during future meetings.
18:03:14 <azaroth> ack ivan
18:03:14 <Zakim> ivan, you wanted to comment on another topic
18:03:29 <pchampin> gkellogg: I may have some blog posts that could be repurposed in BP.
18:03:35 <azaroth> action azaroth to fill out requirements on wiki page
18:03:40 <azaroth> action: azaroth to fill out requirements on wiki page
18:03:58 <pchampin> ivan: something else; in the Wiki page, there is a "Requirements satisfied" section
18:04:17 <pchampin> gkellogg: all requirements are captured as issues
18:04:43 <pchampin> ivan: so using github magic, it should be possible to add a single link to all of them
18:04:50 <azaroth> TOPIC: Adjourn
18:06:01 <ivan> rrsagent, draft minutes
18:06:01 <RRSAgent> I have made the request to generate https://www.w3.org/2019/11/15-json-ld-minutes.html ivan
18:06:01 <ivan> zakim, bye
18:06:01 <ivan> rrsagent, bye
18:06:01 <RRSAgent> I see 2 open action items saved in https://www.w3.org/2019/11/15-json-ld-actions.rdf :
18:06:01 <RRSAgent> ACTION: gkellogg to add note on representation of `@version` not being semver, and noting issues with comparing floating point values [1]
18:06:01 <RRSAgent>   recorded in https://www.w3.org/2019/11/15-json-ld-irc#T17-11-04
18:06:01 <RRSAgent> ACTION: azaroth to fill out requirements on wiki page [2]
18:06:01 <RRSAgent>   recorded in https://www.w3.org/2019/11/15-json-ld-irc#T18-03-40
18:06:01 <Zakim> leaving.  As of this point the attendees have been azaroth, gkellogg, dlongley, ivan, dlehn, bigbluehat
18:06:01 <Zakim> Zakim has left #json-ld