14:52:16 <RRSAgent> RRSAgent has joined #annotation
14:52:16 <RRSAgent> logging to http://www.w3.org/2016/07/29-annotation-irc
14:52:22 <Zakim> Zakim has joined #annotation
14:52:27 <azaroth> trackbot, start meeting
14:52:29 <trackbot> RRSAgent, make logs public
14:52:31 <trackbot> Zakim, this will be 2666
14:52:31 <Zakim> ok, trackbot
14:52:32 <trackbot> Meeting: Web Annotation Working Group Teleconference
14:52:32 <trackbot> Date: 29 July 2016
14:52:40 <azaroth> Chair: Rob_Sanderson
14:53:54 <azaroth> Regrets: Tim_Cole, Ivan_Herman
14:54:19 <azaroth> azaroth has changed the topic to: Agenda: https://lists.w3.org/Archives/Public/public-annotation/2016Jul/0096.html
14:57:37 <Jacob> Jacob has joined #annotation
14:57:46 <bjdmeest> bjdmeest has joined #annotation
14:58:41 <azaroth> Present+ Rob_Sanderson
14:58:54 <Jacob> Present+ Jacob_Jett
14:59:29 <bjdmeest> Present+ Ben_De_Meester
15:00:46 <bigbluehat> Present+ Benjamin_Young
15:00:52 <tbdinesh> tbdinesh has joined #annotation
15:02:41 <ShaneM> present+ ShaneM
15:02:46 <azaroth> scribenick: bjdmeest
15:02:55 <tbdinesh> present+ tb_dinesh
15:03:56 <bjdmeest> azaroth: agenda is mostly testing, but there is one extra issue
15:04:06 <bjdmeest> ... issues #331 and #332
15:04:14 <bjdmeest> ... so first issues, then testing
15:04:22 <bjdmeest> ... implementations or demos would be great
15:04:25 <bjdmeest> ... anything else?
15:04:31 <azaroth> Topic: Minutes Approval
15:04:36 <azaroth> PROPOSED RESOLUTION:  Minutes of the previous call are approved: https://www.w3.org/2016/07/15-annotation-minutes.html
15:05:13 <bjdmeest> RESOLUTION:  Minutes of the previous call are approved: https://www.w3.org/2016/07/15-annotation-minutes.html
15:05:19 <azaroth> TOPIC:  Issues
15:05:34 <azaroth> Git: https://github.com/w3c/web-annotation/issues/331
15:06:36 <bjdmeest> azaroth: about referring to RFC7273: I propose accept and mark as editorial
15:06:45 <takeshi> takeshi has joined #annotation
15:06:54 <bigbluehat> +1
15:06:56 <tbdinesh> +1
15:06:57 <bjdmeest> +1
15:07:02 <Jacob> +1
15:07:03 <tilgovi> tilgovi has joined #annotation
15:07:08 <bjdmeest> azaroth: ok, consider it done
15:07:46 <azaroth> Git: https://github.com/w3c/web-annotation/issues/332
15:08:21 <tilgovi> Present+ Randall_Leeds
15:08:25 <bjdmeest> takeshi: this is about paging
15:08:57 <bjdmeest> ... we used LDP paging, and switched to social Web
15:09:47 <bjdmeest> ... I found that we cannot detect any new changes while we are retrieving all annotations
15:10:13 <bjdmeest> ... in LDP pages, they added a specific Link tag
15:10:38 <bjdmeest> ... even when the client is accessing the entire paging, it can detect the changes, because the parameters can be changed
15:10:51 <bjdmeest> ... I couldn't find such a mechanism in the social web paging
15:11:10 <Janina_> Janina_ has joined #annotation
15:11:21 <bjdmeest> ... so after retrieving all annotations, the client cannot be sure that the retrieved data is actually the latest data
15:11:59 <bjdmeest> ... my proposal is to add a "modified" in the body
15:12:39 <Jacob> wouldn't we need to do the same on target since that can change too?
15:13:04 <bjdmeest> azaroth: the concern is that, when an annotation is modified, that modified timestamp should be propagated to all the collections
15:13:09 <tilgovi> If you provide an ETag that's derived from the state of all the annotations in the collections, that would change.
15:14:30 <bjdmeest> ... so the spec would say that the annotationCollection and annotationPage SHOULD have a modified field, depending on the last modification of the annotations in the collection of page
15:14:47 <bjdmeest> ... would it be a SHOULD or a MUST? I would like SHOULD
15:15:01 <PaoloCiccarese> PaoloCiccarese has joined #annotation
15:15:16 <bjdmeest> takeshi: is "total" MUST or SHOULD?
15:16:14 <azaroth> q?
15:16:21 <bjdmeest> azaroth: "total" is SHOULD, so "modified" would then probably also be SHOULD. Or we change both to MUST, if people think that would be necessary
15:16:25 <tbdinesh> should?
15:16:26 <bjdmeest> ... what do people think?
15:16:34 <bigbluehat> I'd stick with SHOULD
15:16:40 <Jacob> +1 for SHOULD
15:16:53 <PaoloCiccarese> Present+ Paolo_Ciccarese
15:17:07 <bjdmeest> ShaneM: this doc is already CR, right?
15:17:20 <bjdmeest> ... I wouldn't make any changes that constrain conformance
15:17:32 <bjdmeest> ... SHOULDs to MUSTs are a big problem
15:17:39 <bjdmeest> azaroth: agreed
15:18:09 <bjdmeest> ... adding a MAY seems easy, because you can do it anyway (i.e., is editorial)
15:18:18 <bjdmeest> ... is adding a SHOULD going to cause problems?
15:18:26 <bjdmeest> ShaneM: no
15:19:05 <bjdmeest> ... all these optional things in here, I got feedback that they don't improve interoperability
15:19:23 <azaroth> PROPOSAL: Add a sentence to protocol 4.1.3 that Collections SHOULD have a `modified` timestamp
15:19:36 <takeshi> +1
15:19:41 <Jacob> +1
15:19:46 <bjdmeest> +1
15:19:47 <bigbluehat> +1
15:19:48 <PaoloCiccarese> +1
15:19:48 <ShaneM> +0
15:20:01 <azaroth> +1
15:20:12 <bjdmeest> RESOLUTION: Add a sentence to protocol 4.1.3 that Collections SHOULD have a `modified` timestamp
15:20:13 <tbdinesh> +1
15:20:34 <azaroth> rrsagent, pointer?
15:20:34 <RRSAgent> See http://www.w3.org/2016/07/29-annotation-irc#T15-20-34
15:20:43 <takeshi> Present+ Takeshi_Kanai
15:21:01 <azaroth> TOPIC: Testing
15:22:32 <bjdmeest> azaroth: a bunch of schemas have been added
15:22:45 <bjdmeest> ... progress is happening, but we're not there yet
15:22:51 <azaroth> Jacob, anything that you can report here on irc?
15:23:28 <Jacob> I'll be working on schemas for 3.3 this afternoon but Tim will have to look over them before they get committed to the Git Repo
15:23:39 <bjdmeest> ... Tim, in the email, asked: how important is it to report how many times a feature was used?
15:24:06 <ShaneM> q+ to comment on feature granularity
15:24:07 <bjdmeest> ... e.g., if every textual body has a format associated with it, is it sufficient to say: yes, format is used, and is a feature, and can be used anywhere
15:24:36 <azaroth> q?
15:24:39 <azaroth> ack ShaneM
15:24:39 <Zakim> ShaneM, you wanted to comment on feature granularity
15:24:48 <bjdmeest> ... even when format is, e.g., not used in remoteResource
15:25:00 <azaroth> Jacob: Thanks! :)
15:25:03 <bjdmeest> ShaneM: You want as few features as possible
15:25:18 <bjdmeest> ... is each of these fine-grained things a feature?
15:25:28 <Jacob> I should note that everything is going to move more slowly this next week as Tim and I are both traveling to Balisage
15:25:45 <bjdmeest> ... is an attribute mandatory or not
15:25:52 <bjdmeest> ... and does it have a default?
15:26:26 <bjdmeest> ... because these attributes are just data, I don't care about that
15:26:50 <bigbluehat> I agree with ShaneM
15:27:03 <Jacob> @ShaneM Does this mean we shouldn't test MAYs or we shouldn't test anything that isn't a MUST?
15:27:04 <PaoloCiccarese> I agree also, not useful either
15:27:05 <bjdmeest> azaroth: having a complete matrix of every possible feature etc. seems massive overkill
15:27:39 <PaoloCiccarese> That could be a retrospective study
15:27:44 <bjdmeest> ... It seems like we have a way forward
15:28:10 <bjdmeest> ... So, the decision is that it is sufficient to say that it is used, and move on
15:28:20 <bjdmeest> ... anything else about model testing?
15:28:39 <bjdmeest> ShaneM: when talking about, e.g., text direction
15:29:06 <bjdmeest> ... we are talking about verification (is the value ltr or ...)
15:29:14 <bjdmeest> ... as long as the value is valid, that's fine
15:29:29 <bjdmeest> ... so there is no separate test for that
15:29:42 <bjdmeest> azaroth: the feature is textualBody, and all its properties?
15:29:44 <Jacob> So we would still need to verify that something, e.g., language, is a string or an array of strings?
15:30:06 <bjdmeest> ShaneM: are there distinct types of textualBody that really need to be supported? e.g., plain vs html?
15:30:07 <azaroth> link: https://www.w3.org/TR/annotation-model/#embedded-textual-body
15:30:14 <bjdmeest> azaroth: I don't think so
15:30:25 <bjdmeest> ... TextualBody MUST have a value
15:30:59 <Jacob> This is an easy test
15:31:21 <bjdmeest> ShaneM: are there specific format that are allowed?
15:31:28 <bjdmeest> azaroth: it SHOULD be a media type
15:31:42 <bjdmeest> ... we could probably just test using a regex
15:32:11 <bjdmeest> ShaneM: if it says SHOULD, then anything can go, nothing would be wrong
15:32:19 <bjdmeest> ... so there are no tests there
15:33:06 <azaroth> TOPIC: Protocol Testing
15:33:07 <bjdmeest> ... again, that's what people said to me: there is little required
15:33:32 <bigbluehat> https://github.com/w3c/wptserve/pull/87
15:33:54 <bjdmeest> bigbluehat: wptserver cannot handle prefer headers on separate lines
15:34:15 <bjdmeest> ... only the last one is recognized
15:34:28 <bjdmeest> ... which is true for virtually every python server in the world
15:34:46 <tilgovi> server or client?
15:35:09 <bjdmeest> ... most servers get it wrong, almost all clients don't support it
15:35:29 <bjdmeest> ... if you want to send multiple, you have to comma-separate them
15:35:42 <bjdmeest> ... the patch fixes that
15:35:58 <bjdmeest> ... so that wptserve actually supports this
15:36:13 <bjdmeest> ... it is working with that patch
15:36:38 <azaroth> Link: https://www.w3.org/TR/annotation-protocol/#responses-without-annotations
15:36:41 <ShaneM> I am going to work to get that PR integrated into wptserve ASAP
15:37:13 <bjdmeest> azaroth: is this also a problem for the clients?
15:37:39 <bjdmeest> bigbluehat: it is possible to send comma-separate headers with any client
15:37:59 <bjdmeest> ... if anyone wants to send the headers as mentioned in the spec, they will have a hard time
15:38:42 <ShaneM> q+ to ask about real implementations
15:38:43 <bjdmeest> ... the biggest question I have: how confused will people be with the multiple prefer-headers?
15:38:58 <bjdmeest> ... would it be better to avoid to have both?
15:39:02 <azaroth> ack ShaneM
15:39:02 <Zakim> ShaneM, you wanted to ask about real implementations
15:39:08 <bjdmeest> ... it's not impossible to support, but it's tedious
15:39:20 <bjdmeest> ShaneM: I'm wondering about real implementations
15:39:25 <bjdmeest> ... have we checked any?
15:40:30 <bjdmeest> bigbluehat: the problem was that the current curl commands didn't work on wptserve
15:41:15 <bjdmeest> azaroth: I use python with request and wsgi, so I assume I will get in the same trouble
15:41:58 <bigbluehat> oh, and also RFC 7230 deprecates line folding...
15:42:29 <bjdmeest> ... I propose about the protocol specification: an editorial action to change the examples to use the comma-separated values
15:42:51 <tilgovi> It's not uncommon for a spec to say that lines are broken for readability only
15:43:26 <azaroth> PROPOSAL:  The examples in the protocol document should use comma separated values for link and prefer headers rather than multiple headers
15:43:47 <bjdmeest> bigbluehat: would this be better than just adding a note about using string-concatenated?
15:44:03 <bjdmeest> azaroth: I anticipate people will just copy-paste examples
15:44:31 <bjdmeest> ... adding a note saying: we do it like this seems good, but I think the examples should be changed
15:44:58 <ShaneM> +1
15:44:59 <bjdmeest> +1
15:45:02 <azaroth> +1
15:45:05 <PaoloCiccarese> +1
15:45:09 <tbdinesh> +1
15:45:10 <takeshi> +1
15:45:10 <bigbluehat> +0
15:45:40 <bigbluehat> +1
15:45:49 <bjdmeest> RESOLUTION: The examples in the protocol document should use comma separated values for link and prefer headers rather than multiple headers
15:45:55 <azaroth> rrsagent, pointer?
15:45:55 <RRSAgent> See http://www.w3.org/2016/07/29-annotation-irc#T15-45-55
15:46:51 <bjdmeest> ShaneM: adding a Note that says: these are the problems in the wild, is a great contribution to the community
15:46:53 <azaroth> q?
15:47:33 <bjdmeest> ShaneM: are we at a position to soon push this to wptserve and get some tests in place?
15:48:15 <bjdmeest> bigbluehat: once I have all the multiple prefer headers code in place, we can talk about integrating all this
15:49:12 <bjdmeest> bigbluehat: I am talking about the 4.2 representation stuff
15:49:38 <bjdmeest> ... currently, the server may ignore the client's preferences
15:50:46 <bjdmeest> azaroth: there where comments: just use HTTP and be done with it. The pattern that was adopted by LDP (and by us) was:
15:51:16 <bjdmeest> ... if you want this to happen, do this, but the server can ignore everything (to avoid having to create a separate profile)
15:51:44 <bjdmeest> ... so something like: _please_ support all the stuff, but, yeah..
15:51:52 <bjdmeest> ... it's not required
15:52:02 <bjdmeest> ShaneM: about automation
15:52:11 <bjdmeest> ... the next hurdle is to provide automation
15:52:22 <bjdmeest> ... for protocol testing, it is quite straightforward
15:52:26 <bjdmeest> ... not so for model testing
15:52:49 <bjdmeest> ... we want a way to send actual output from the client, and send them to the tests
15:53:01 <bjdmeest> ... for CR, we are trusting the implementer to do what we say
15:53:20 <bjdmeest> ... but we have no proof that implementers actually did the right thing
15:53:42 <bjdmeest> ... that's fine, we just want to say: these implementers say that they implement our spec
15:54:30 <bjdmeest> ... I'm wondering: could people that write annotation clients help in telling how implementation clients could emit those annotation models
15:54:59 <bjdmeest> azaroth: aren't the schemas sufficient? i.e., send the annotation to the wptserve?
15:55:16 <bjdmeest> ShaneM: if think about the feature tests, e.g., I want an annotation of an image
15:55:34 <bjdmeest> ... how to I automate telling your client to generate such an annotation and send it through the wire?
15:55:56 <bjdmeest> ... we could use the protocol, we could paste it in the textarea and test it
15:56:15 <bjdmeest> azaroth: but the tricky part is asking the client to generate 'such an annotation'
15:56:32 <bjdmeest> ShaneM: there is 'WebDriver' (the standardized version of Celenium)
15:56:41 <azaroth> s/Celenium/Selenium/
15:56:56 <bjdmeest> ... to test the properties of web browsers
15:57:09 <azaroth> See: http://www.seleniumhq.org/projects/webdriver/
15:57:20 <bjdmeest> ... let's say you have an annotation-client as a chrome-plugin
15:57:51 <bjdmeest> ... you, as an implementer could test that annotation-client using something like webdriver
15:58:07 <bjdmeest> azaroth: that would have been easier if there would have been a client API
15:58:47 <bjdmeest> ShaneM: We could have a hook, that, when a test came up, it could hit a URI with a query string to return the right content
15:59:00 <bjdmeest> ... using like a service worker, in the browser
15:59:40 <bjdmeest> azaroth: [adjourn]
15:59:43 <azaroth> TOPIC: Adjourn
15:59:45 <bjdmeest> ... see you next week!
15:59:54 <tilgovi> thanks, bjdmeest !
16:00:03 <bigbluehat> bjdmeest++
16:13:57 <azaroth> rrsagent, make minutes
16:13:57 <RRSAgent> I have made the request to generate http://www.w3.org/2016/07/29-annotation-minutes.html azaroth
16:14:03 <azaroth> rrsagent, make logs public
16:15:29 <azaroth> regrets+ Frederick_Hirsch
16:15:32 <azaroth> rrsagent, make minutes
16:15:32 <RRSAgent> I have made the request to generate http://www.w3.org/2016/07/29-annotation-minutes.html azaroth
16:15:34 <azaroth> rrsagent, make logs public
16:21:35 <tantek> tantek has joined #annotation
16:54:07 <shepazu> shepazu has joined #annotation
17:56:42 <Zakim> Zakim has left #annotation
18:37:24 <tilgovi> tilgovi has joined #annotation
19:05:14 <shepazu_> shepazu_ has joined #annotation
20:54:11 <tantek> tantek has joined #annotation
21:11:29 <tilgovi> tilgovi has joined #annotation