Web Annotation Working Group Teleconference

<TimCole> PROPOSED RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/08/12-annotation-minutes.html

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

Issues

TimCole: Rob posted a question about agent requirements

<TimCole> Issue - agent requirements : https://github.com/w3c/web-annotation/issues/349

TimCole: noted that there are no MUST requirements on agents involved in creating annotations or resources that serve as bodies
... do have SHOULDS but no MUSTS
... doesn't prevent checking for agent objects (even if empty)
... not any real concerns but want to confirm that agents being unspecified is how we want it
... will leave this as -- should be closed -- but will wait for Rob's return

<TimCole> : https://github.com/w3c/web-annotation/issues/348

TimCole: other issue is an editorial recommendation for textDirection
... discussion participants from internationalization group; suggesting wording changes

ivan: should add the editorial labels [have added them]
... not clear is whether proposals to close the related textDirection discussions, e.g., #335

<TimCole> https://github.com/w3c/web-annotation/issues/335

ivan: is 348 a proposal to close 335?

TimCole: no other actions out of this

Testing

TimCole: model testing

<TimCole> http://testdev.spec-ops.io:8000/annotation-model/annotations/annotationMusts-manual.html

TimCole: posted a few links to the test area Shane set up
... can go there, paste in an annotation, and determine if all of the keys specific to "annotation" are valid, i.e. does not test body/target properties
... it does check optional annotation properties, e.g., created
... if 0 or 1 it passes but 2+ fails
... if these tests look usable to implementers then should potentially move to the production region so that more implementers can use them
... will be similar sets for bodies and targets
... want to verify this approach works first

ShaneM: want to pay attention to the readability of the assertion list
... existing ones readable, make sense, etc. but wish they could be more ledgible
... not critical but will want to make it even clearer what is being tested, e.g., "leap off the page"

TimCole: can we embed html into the text here?

ShaneM: yes but not sure how this will propagate through the tool chain

Ben: could use markdown instead of embedding html

ShaneM: good idea, will embed markdown processing

<TimCole> http://testdev.spec-ops.io:8000/annotation-model/annotations/annotationOptionals-manual.html

TimCole: recommended / optional assertions are harder to word
... [summary of web-page]
... how should these be worded? a lot of text explaining the "failure" result
... which is followed by some fairly arcane json validation text

ShaneM: could use the OR structure
... e.g., branch A, "property not included", branch B, "property value invalid"

TimCole: Could cascade several...e.g., creator key
... was it implemented? then was only one implemented?

<ivan> +1 to Shane

ShaneM: makes sense but more important to get the test out there, don't need to be perfect
... can defer this issue until later

TimCole: will move on to body/target tests then
... haven't started on annotation collection tests
... wanted help from Rob, so not starting them until late next week
... in the interim should we solicit feedback on the three tests (annotation, body, target)?

ivan: anything we can do to get the community more involved would be good
... running very behind on the CR schedule
... need to publish asap, even if additional / new tests are coming

ShaneM: will move the existing tests to the main repo, tagging tim and benjamin as reviewers
... then peer-reviewed step will be accomplished

TimCole: will be cleaning some of the unused / older folders out to simplify the merge
... other thing we are doing is testing locally using ajv / nodejs
... relatively easy process
... going to write some additional json schemas to allow local annotation testing in a similar manner to the existing test infrastructure

ShaneM: if there's a way to add that to the repo, can do that

TimCole: script is a command line, just using a text file for it but can look at making a more formal ajv script

ShaneM: there is a make_tests.py script, which should generate a test so long as valid schema are available

TimCole: json allows a certain amount of recursion, e.g., choice has items, items may be lists, etc.
... need to be careful not to loop to infinity
... will provide instructions next week on how to run these in ajv
... hopefully Rob will help us provide instructions on how to do the same with python libraries

ivan: should look at implementor list and generate some emails to get community involved

ShaneM: will take some cycles to get the changes merged

Benjamin: should we use github to rally the implementers?
... would allow implementers to self-identify

ivan: need to still email those we know; the more the better

Benjamin: github issue will also go out to the list

TimCole: any concerns about reporting the test results?
... clear what was/wasn't implemented, etc.

ShaneM: will put an example result using the W3C's reporting tool (makes a table of who's implementing which features)

Protocol Testing

TimCole: testing example 42 is nice, implements many of the model's features

<TimCole> s /42/44

ShaneM: continuing to work on the ldp hand-off from Benjamin
... physically adding a "route" into the server that knows that for certain things goes through our protocol
... making internal changes for short-term data
... converted the client-side testing to WPT framework

Benjamin: moving to hunting to Wiley's implementation status and open-source implementations
... revisiting past annotation work to get them involved, provide more options

ShaneM: protocol test can be demo'd now, just not in the WPT context
... client-side experience would be similar to what we have now, server-side will have a page
... to-do list: integrate the route and html page for client-protocol testing, server-side is a single test case

TimCole: will there be pushback from implementers who received the invalid result but insist they have implemented correctly, how do they note this?

<ShaneM> annotation-protocol/client and annotation-protocol/server are the paths

<ShaneM> I have written the documentation - not yet checked in.

ShaneM: via github -- then we prove they were wrong or fix the test

TimCole: other action items?

<bigbluehat> I know csarven is interested in the HTML note if we can get that on the schedule

ivan: html note, can be done when the CR is done
... internationalization will probably be a topic next week

<Zakim> ShaneM, you wanted to ask if there is any danger of having to recycle CR?

<csarven> Not in the call.. but, yes. Interested in pushing a NOTE. I'll send an email out - would like to narrow down on exactly what we are expecting from this note.

ivan: nothing has yet to come up to cause us to restart the CR, but the internationalization discussion could result in a technical change
... @ShaneM: will the testing specs built for us be reused for other groups

ShaneM: yes, was the reason specops moved on it
... general case of testing the shape of a json data structure is critical for many standards
... protocol testing a little less important but will reuse the protocol testing model for other protocols
... was why the effort to take a neutral approach was taken

TimCole: will be updating the assertions with markdown in the next couple of hours
... adjourn