<azaroth> trackbot, start meeting

<azaroth> scribenick: bjdmeest

azaroth: agenda is mostly testing, but there is one extra issue
... issues #331 and #332
... so first issues, then testing
... implementations or demos would be great
... anything else?

Minutes Approval

<azaroth> PROPOSED RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/07/15-annotation-minutes.html

RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/07/15-annotation-minutes.html

Issues

<azaroth> Git: https://github.com/w3c/web-annotation/issues/331

azaroth: about referring to RFC7273: I propose accept and mark as editorial

<bigbluehat> +1

<tbdinesh> +1

+1

<Jacob> +1

azaroth: ok, consider it done

<azaroth> Git: https://github.com/w3c/web-annotation/issues/332

takeshi: this is about paging
... we used LDP paging, and switched to social Web
... I found that we cannot detect any new changes while we are retrieving all annotations
... in LDP pages, they added a specific Link tag
... even when the client is accessing the entire paging, it can detect the changes, because the parameters can be changed
... I couldn't find such a mechanism in the social web paging
... so after retrieving all annotations, the client cannot be sure that the retrieved data is actually the latest data
... my proposal is to add a "modified" in the body

<Jacob> wouldn't we need to do the same on target since that can change too?

azaroth: the concern is that, when an annotation is modified, that modified timestamp should be propagated to all the collections

<tilgovi> If you provide an ETag that's derived from the state of all the annotations in the collections, that would change.

azaroth: 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
... would it be a SHOULD or a MUST? I would like SHOULD

takeshi: is "total" MUST or SHOULD?

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

<tbdinesh> should?

azaroth: what do people think?

<bigbluehat> I'd stick with SHOULD

<Jacob> +1 for SHOULD

ShaneM: this doc is already CR, right?
... I wouldn't make any changes that constrain conformance
... SHOULDs to MUSTs are a big problem

azaroth: agreed
... adding a MAY seems easy, because you can do it anyway (i.e., is editorial)
... is adding a SHOULD going to cause problems?

ShaneM: no
... all these optional things in here, I got feedback that they don't improve interoperability

<azaroth> PROPOSAL: Add a sentence to protocol 4.1.3 that Collections SHOULD have a `modified` timestamp

<takeshi> +1

<Jacob> +1

+1

<bigbluehat> +1

<PaoloCiccarese> +1

<ShaneM> +0

<azaroth> +1

RESOLUTION: Add a sentence to protocol 4.1.3 that Collections SHOULD have a `modified` timestamp

<tbdinesh> +1

Testing

azaroth: a bunch of schemas have been added
... progress is happening, but we're not there yet

<azaroth> Jacob, anything that you can report here on irc?

<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

azaroth: Tim, in the email, asked: how important is it to report how many times a feature was used?
... 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

<Zakim> ShaneM, you wanted to comment on feature granularity

azaroth: even when format is, e.g., not used in remoteResource

<azaroth> Jacob: Thanks! :)

ShaneM: You want as few features as possible
... is each of these fine-grained things a feature?

<Jacob> I should note that everything is going to move more slowly this next week as Tim and I are both traveling to Balisage

ShaneM: is an attribute mandatory or not
... and does it have a default?
... because these attributes are just data, I don't care about that

<bigbluehat> I agree with ShaneM

<Jacob> @ShaneM Does this mean we shouldn't test MAYs or we shouldn't test anything that isn't a MUST?

<PaoloCiccarese> I agree also, not useful either

azaroth: having a complete matrix of every possible feature etc. seems massive overkill

<PaoloCiccarese> That could be a retrospective study

azaroth: It seems like we have a way forward
... So, the decision is that it is sufficient to say that it is used, and move on
... anything else about model testing?

ShaneM: when talking about, e.g., text direction
... we are talking about verification (is the value ltr or ...)
... as long as the value is valid, that's fine
... so there is no separate test for that

azaroth: the feature is textualBody, and all its properties?

<Jacob> So we would still need to verify that something, e.g., language, is a string or an array of strings?

ShaneM: are there distinct types of textualBody that really need to be supported? e.g., plain vs html?

<azaroth> link: https://www.w3.org/TR/annotation-model/#embedded-textual-body

azaroth: I don't think so
... TextualBody MUST have a value

<Jacob> This is an easy test

ShaneM: are there specific format that are allowed?

azaroth: it SHOULD be a media type
... we could probably just test using a regex

ShaneM: if it says SHOULD, then anything can go, nothing would be wrong
... so there are no tests there

Protocol Testing

ShaneM: again, that's what people said to me: there is little required

<bigbluehat> https://github.com/w3c/wptserve/pull/87

bigbluehat: wptserver cannot handle prefer headers on separate lines
... only the last one is recognized
... which is true for virtually every python server in the world

<tilgovi> server or client?

bigbluehat: most servers get it wrong, almost all clients don't support it
... if you want to send multiple, you have to comma-separate them
... the patch fixes that
... so that wptserve actually supports this
... it is working with that patch

<azaroth> Link: https://www.w3.org/TR/annotation-protocol/#responses-without-annotations

<ShaneM> I am going to work to get that PR integrated into wptserve ASAP

azaroth: is this also a problem for the clients?

bigbluehat: it is possible to send comma-separate headers with any client
... if anyone wants to send the headers as mentioned in the spec, they will have a hard time
... the biggest question I have: how confused will people be with the multiple prefer-headers?
... would it be better to avoid to have both?

<Zakim> ShaneM, you wanted to ask about real implementations

bigbluehat: it's not impossible to support, but it's tedious

ShaneM: I'm wondering about real implementations
... have we checked any?

bigbluehat: the problem was that the current curl commands didn't work on wptserve

azaroth: I use python with request and wsgi, so I assume I will get in the same trouble

<bigbluehat> oh, and also RFC 7230 deprecates line folding...

azaroth: I propose about the protocol specification: an editorial action to change the examples to use the comma-separated values

<tilgovi> It's not uncommon for a spec to say that lines are broken for readability only

<azaroth> PROPOSAL: The examples in the protocol document should use comma separated values for link and prefer headers rather than multiple headers

bigbluehat: would this be better than just adding a note about using string-concatenated?

azaroth: I anticipate people will just copy-paste examples
... adding a note saying: we do it like this seems good, but I think the examples should be changed

<ShaneM> +1

+1

<azaroth> +1

<PaoloCiccarese> +1

<tbdinesh> +1

<takeshi> +1

<bigbluehat> +0

<bigbluehat> +1

RESOLUTION: The examples in the protocol document should use comma separated values for link and prefer headers rather than multiple headers

ShaneM: adding a Note that says: these are the problems in the wild, is a great contribution to the community
... are we at a position to soon push this to wptserve and get some tests in place?

bigbluehat: once I have all the multiple prefer headers code in place, we can talk about integrating all this
... I am talking about the 4.2 representation stuff
... currently, the server may ignore the client's preferences

azaroth: there where comments: just use HTTP and be done with it. The pattern that was adopted by LDP (and by us) was:
... if you want this to happen, do this, but the server can ignore everything (to avoid having to create a separate profile)
... so something like: _please_ support all the stuff, but, yeah..
... it's not required

ShaneM: about automation
... the next hurdle is to provide automation
... for protocol testing, it is quite straightforward
... not so for model testing
... we want a way to send actual output from the client, and send them to the tests
... for CR, we are trusting the implementer to do what we say
... but we have no proof that implementers actually did the right thing
... that's fine, we just want to say: these implementers say that they implement our spec
... I'm wondering: could people that write annotation clients help in telling how implementation clients could emit those annotation models

azaroth: aren't the schemas sufficient? i.e., send the annotation to the wptserve?

ShaneM: if think about the feature tests, e.g., I want an annotation of an image
... how to I automate telling your client to generate such an annotation and send it through the wire?
... we could use the protocol, we could paste it in the textarea and test it

azaroth: but the tricky part is asking the client to generate 'such an annotation'

ShaneM: there is 'WebDriver' (the standardized version of Selenium)
... to test the properties of web browsers

<azaroth> See: http://www.seleniumhq.org/projects/webdriver/

ShaneM: let's say you have an annotation-client as a chrome-plugin
... you, as an implementer could test that annotation-client using something like webdriver

azaroth: that would have been easier if there would have been a client API

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
... using like a service worker, in the browser

azaroth: [adjourn]

Adjourn

azaroth: see you next week!

<tilgovi> thanks, bjdmeest !

<bigbluehat> bjdmeest++

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Celenium/Selenium/
Found ScribeNick: bjdmeest
Inferring Scribes: bjdmeest
Present: Rob_Sanderson Jacob_Jett Ben_De_Meester Benjamin_Young ShaneM tb_dinesh Randall_Leeds Paolo_Ciccarese Takeshi_Kanai
Regrets: Tim_Cole Ivan_Herman Frederick_Hirsch
Found Date: 29 Jul 2016
Guessing minutes URL: http://www.w3.org/2016/07/29-annotation-minutes.html
People with action items: