See also: IRC log
<azaroth> trackbot, start meeting
<Loqi> *sniff*
<azaroth> scribenick: azaroth
TimCole: Let's get started
TimCole: (walks through agenda) Anything
else we need to talk about?
... Okay. Want to announce that at the next couple of DPUB IG meetings
will have topics of interest for this group
<TimCole> http://spec-ops.github.io/html-note/index.html
TimCole: Draft note from Shane, any background?
ShaneM: Happy to. Short story is, A11y
folks and DPUB folks have talked about the need for semantically rich
way of marking up notes
... HTML is not good at this. Gathered some ideas a year ago and
recently revised
... Possible to do as an HTML extension. Can implement as what was
called a web component
... Revived the interest in that, put together a skeleton, and going to
see if there's support in the IG to move forwards
TimCole: Would be nice to have that.
There's a reference to the WAWG doc, so feedback would be welcome
... Not sure if this relates to Doug's interest in HTML serialization
issues
shepazu: Not sure if this is related or a separate branch. What I tried was very similar
TimCole: Other thing, the following week
(May 2) has a discussion of WDs of our group
... Rob and I will be on the call, and try to describe where we are
... see if there's feedback on the drafts. Might be useful to have it
before Berlin, so we can discuss any feedback
... Ivan any thing else? (no)
... Other announcements?
<TimCole> PROPOSED RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/04/15-annotation-minutes.html
RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/04/15-annotation-minutes.html
TimCole: First, need to get a sense of
progress and what we need.
... Can you review for the group, Shane?
ShaneM: We've done some thinking and there's some momentum to get the infrastructure in place
<TimCole> https://lists.w3.org/Archives/Public/public-annotation/2016Apr/0077.html
ShaneM: But that's where we're at, haven't
solved any problem yet
... Talked with web platform tests to see if that's the right place, and
it seems to be
<TimCole> https://github.com/Spec-Ops/web-platform-tests
ShaneM: The reason that was a question at
all is that those tests are about exercising user agents
... And components are not UA centric. So didn't want to violate
principles, or step on toes
... We can drive the testing from the browser, which is good, people
used to running W3C tests will be familiar with interface
... have set aside the question of is it possible to automate the
testing of clients when selecting parts of documents
... Can be manual intervention though
<shepazu> conversation on public-test-infra https://lists.w3.org/Archives/Public/public-test-infra/2016AprJun/0000.html
ShaneM: For a given assertion, eg a MUST in
the rec, that say the annotation takes a certain form
... there's a couple of different ways to do it, but we can express
tests in a declarative way with sample data
... Select the region, run it through the client and push the data to
make sure it has the right form
... that sort of testing.
... Don't think this is anything new, but we now have a model in mind
and some people to put it together
... There'll be some back end tooling for the web platform test
environment
... to support the declarative test cases
... and a folder to put the tests in. Then running them is just select
the folder and say run the tests
... it'll run the automated ones for you. If you're a testing geek it's
very interesting :)
... I'll send out a mail to the group for an example test
... Spec Ops has taken it on, as it's tightly coupled to the projects
that we already have funded
... was able to finesse it in
... Don't have funding for annotation, but we need it elsewhere
(Payments)
shepazu: Another question came up...
Shane's initial one was should we do client side testing
... The testing methodologies for related things were like checking for
self consistency and the shape of the data
... Ontology/vocab specs has just been to test consistency, not the
implementation
... Exception for CSVW
... Wanted to see what the feeling of the group was
<ShaneM> good question!
shepazu: Should test what the user agents
generate, but could be just is it consistent
... Should we test both or just one?
<tilgovi> Yes
<tilgovi> Both
TimCole: The tests as described involve whether its consistent with the model
<ShaneM> Servers MUST be tested for the protocol spec.
TimCole: but semantics harder to test
<bigbluehat> +1 to both
ivan: One thing is that we have
implementations, some are here in the group, that are not specifically
browser based in the way that I understand the web platform to work
... one of the differences might be that the media on which the
annotations happen are not HTML but say images
... we need the implementations, they're equally valid for the CR or
should be, and whether that fits the testing model?
<ShaneM> it fits the model.
ivan: in some sense the extreme case, but
perhaps for purely timing reasons, might have implementations that are
part of an epub reader
... have two, one mainly, but are completely out of the browser picture
... Other question is that I presume this doesn't relate to the protocol
testing?
... Presume has to go through some different means? And also, agree that
both should be tested, but on a practical level if we have timing then
the priority is the testing of the model
<bigbluehat> to be clear, all we can test is the Web Annotation Data Model serialization provided from the clients--where that JSON hits the testing code (browser, server, command line) is a matter of deployment
ivan: that's what's critical to have the CR phase complete
<ShaneM> ePub reader testing could be done here - but the connection between the ePub reader and the test environment is an exercise for the ePub reader implementor
ivan: Have to be careful on priorities
shepazu: There's a class of user agent that
won't be able to use the test framework, so the tests themselves should
run in both the platform and elsewhere
... for those user agents that aren't browser based, we could do self
reporting
... need a validator that they send their output to
... Here is the JSON-LD, I'll put it in this form for the test, and the
test gets run
... does that seem reasonable?
... if we should test the UAs, the spec is written so its largely about
the vocab, not the UAs
... not sure if we need a different spec to talk about what a UA should
do
... don't have a strong opinion
... Could add normative assertions to the spec for conformance of UAs,
which would help with testing
<bigbluehat> we can't test what isn't spec'd, and we haven't spec'd UA conformance and (under this current charter) we don't have time
shepazu: maybe just at the beginning, UAs
of this class, must do bla bla bla
... then apply it to the different clients
... recap existing assertions as applying to the generator of the
content, rather than the model itself
<bigbluehat> browser-based UA's won't have the same conformance requirements as a screen-scraper (for instance)
<Zakim> ShaneM, you wanted to mention that it would be possible to provide an endpoint on the web platform tests to which an ePub reader could push their annotation or whatever
ShaneM: if any epub reader implemented the
protocol we couldprovide a testing endpoint
... the framework could open another endpoint for annotations
... we're going to put that framework together regardless
... your point is really good Doug, there's hardly any discussion of UA
requirement sin the spec right now
... I don't have an opinion on whether the group shuold define these or
not
... If you do, I encourage you to do it as a profile. They don't have to
support all annotations, but they have to support them in the way you
define it.
... You have a lot of different ways of using annotation.
<Zakim> azaroth, you wanted to describe image case
TimCole: Let's go forward in the queue for now.
azaroth: Like the image case, it's not
native in the browser, but I think what Shane's just described would
work very well for our types of user agents
... they implemented an early version of the protocol, they could
relatively easily be updated
... we could add the validator endpoint as somewhere to send the
annotations and have the validator run the tests that it thinks it can
based on what it's received
... at least all of the syntactic validation should fit right in
ivan: On the UA requirement, I am doubtful we can do something really useful and complete, at least in the lifetime of this working group.
<azaroth> +1 to Ivan -- priorities important, get what we need first, then nice to haves around different UAs
<bigbluehat> +1 to focusing on testing and shipping what we've already spec'd
ivan: If I look at the various types of user agents, from Hypothesis to epub readers, we have too many and I don't think we can do a meaningful work on that so it would not be my priority in view of the time we have
TimeCole: We talked before about grouping
some of the features by things like media type as a way to have like
profiles and acknowledged that no single implementation, as Shane
mentioned, will do it all
... is that what we talked about previously, Ivan?
ivan: yeah.
TimCole: Maybe other implementors on the
call have thoughts.
... We talked a couple weeks ago about how we still need to do the work
of identifying, in our documents, what are the testable features.
... I think we still have to do that.
... Am I right?
ShaneM: I believe you're correct. I know
that I had an action to identify some things. I dind't do that and I
apoligize.
... Greg Kellogg did do some of that, in the context of the discussions
we were having.
... Showing how we might craft a declarative test.
<Loqi> gregg has 1 karma
ShaneM: You use a declarative grammar to
say "this is what is to be tested" and then you write a framework that
is the script
... We are looking for the possibility that anyone can write a test.
Since the declarative grammar is JSON and you are all very familiar we
JSON that's one fo the reasons we're looking at this route.
<bigbluehat> here's the draft from gregg https://gist.github.com/gkellogg/4ff74c27313e95a6b3dcbad6cc64277a
ShaneM: There's a gist he put up. Thank
you, Benjamin.
... I hadn't planned to go through this because it's embryonic, we just
started the work.
<bigbluehat> it's 75% JSON Schema fwiw
ShaneM: If you follow that link, the test is the input about the test that defines the context and the annotation. It's the input for a test.
TimCole: Maybe if people look at that you can get more people to help find and make those declarative tests about the assertions.
ShaneM: Yes. If we can get a few examples, hopefully we can cut up the spec and one person can go off and look at a section and add these testable assertions
<bigbluehat> advantage of declarative is that we can use them in the browser, via the command line, or an API
TimCole: In the interest of times, I'd like to wrap this discussion up for the day, in ten minutes or so.
takeshi: I'm implementing a sort of
annotation application as a prototype and that is a native application,
not based on the browser engine.
... Since we are focusing on handwriting, the text selection is in
second priority.
... Even if we receive the text selection annotation from the server it
might be ignored or just show up as an annotation to that web page.
... That could be different from the expectation for others, but at this
time this is what I am planning to do.
... If the specification requires that any of the feature has to be
implemented in the annotation application, I'm afraid that my
application could not meet that criteria.
TimCole: Would you application be able to send annotations that you generate as JSON-LD to a validator.
<tbdinesh> how do you test if a feature (such as selection) is implemented in an annotation appl?
<Zakim> azaroth, you wanted to ask about automation of declarations from ontology
takeshi: Even though all the annotation data will be sent in the JSON-LD, we might ignore some annotations we have in JSON-LD
azaroth: Many of the requirements are in
the vocabulary with which properties they should be used with and
whether you can have more than one, etc
... It may be useful if we create at least stubs of all of the possible
tests going forward, and workin with the IDPF to make the JSON schema
... there's a lot of shared tooling around what sorts of tests can be
written given the flexibility of RDF and JSON-LD, but still keeping it
within the spec.
... Question then is, is that something that we should look into? I'm
happy to spend a bit of time working on it.
ShaneM: That would be fantastic.
... We envisioned doing certain kinds of exercising automatically. We
have some tooling for that, but let's not monopolize this meeting.
ivan: Rob almost said everything I wanted
to say. I have one additional thing to add.
... I think having JSON Schema around as an additional tool we give to
current and future implementers would be useful anyway.
... We can have an informative reference on the website alongside the
context file.
ShaneM: Obviously, JSON Schema is much more restrictive in terms of structure than JSON-LD, but that's okay.
TimCole: I don't think I heard any formal
actions, but clearly members need to look at how these assertions and
testable features are expressed in a declarative way and think about how
to contribute to that.
... The JSON schema would be useful.
... And we have the potential automating of some of the tests.
... We probably need to think about timeline for getting these things
done.
<ShaneM> Here is my ask: Anyone who wants to be looped in, go to http://lists.spec-ops.io/listinfo.cgi/testdev-spec-ops.io and join the list
TimCole: Can I suggest we make it of prime importance for next weeks call to think about what we want to get done before the face to face.
<ShaneM> and yes - let's set a schedule in the next week
TimCole: Does that sound like a way forward? Did I miss something important?
TimCole: Issue #200 was should oa:start and oa:end always use xsd:nonNegativeInteger.
<TimCole> https://github.com/w3c/web-annotation/issues/200
TimCole: I think we talked about lat week
that this proposal was the way to do it. The answer was yes. We wanted
to give people a chance to think about it for a week.
... Do we need further discussion on this?
azaroth: I think we can make it an
editorial action to update the context.
... The concern that I had that stain proved was not a concern, whether
or not JSON-LD compaction causes nonNegativeInteger to stick around.
<azaroth> PROPOSED RESOLUTION: Accept git issue #200, make start and end nonNegativeInteger in @context
<ivan> +1
<azaroth> +1
<PaoloCiccarese> +1
<TimCole> +1
<tbdinesh> +1
<takeshi> +1
<davis_salisbury> +1
<ShaneM> I am abstaining - too new here
I can't reproduce the success described.
With compaction removing it.
RESOLUTION: Accept git issue #200, make start and end nonNegativeInteger in @context
<TimCole> https://github.com/w3c/web-annotation/issues/203
TimCole: The discussion last week on selectors vs media types, there was a lot of positive response about what's been put together.
ivan: I think the idea that came out of
some discussion was that this table should exist, so I sat down on made
it. I think it should go back to the editors to look at.
... There are comments I made in the issue, but I think they are all
editorial.
... I would propose this is something Benjamin, Rob, and I can handle on
email.
<azaroth> +1 with a few minor tweaks (e.g. Fragment should be either tick or ?, as we don't know future fragment specs and don't want to suggest they're not to be used)
TimCole: So a proposal would be to put this to editor action.
<azaroth> PROPOSED RESOLUTION: Accept proposed media/selector table towards conformance section of the specs
<azaroth> +1
<TimCole> +1
<ivan> =1
<ivan> +1
<PaoloCiccarese> +1
<takeshi> +1
RESOLUTION: Accept proposed media/selector table towards conformance section of the specs
<TimCole> https://github.com/w3c/web-annotation/issues/195
TimCole: Let's take one more issue today.
... this was the issue involving refining state by selector.
... As I understood the thread, there's some confusion about what is
needed here.
ivan: There is a question if I can mix,
with some limitations, the refinements. Can I refine a state with a
selector?
... I have the impression that there is no disagreement on that between
us.
azaroth: There are no disagreements on that. It would be good to be able to refine a state with a selector.
ivan: I would propose to do that, then, and let that be an editorial action.
azaroth: To be clear, where we may disagree, I think it should still be possible to have both hasState and hasSelector on a specific resource.
ivan: I'm saying I'd like to separate these two questions.
TimCole: Can we do that? Can a new issue be
created and some resolution be posted to the issue to Github.
... in the meantime we can close the other issue.
ivan: I think that the issue is saying, can
a refinement be made on a state?
... we can make that a sepraate issue and make it editorial right away.
TimCole: I want to give people a chance over the week before we actually close it out.
<TimCole> https://github.com/w3c/web-annotation/issues/147
TimCole: We don' thave time to talk about
HTML serialization in depth, we don't have time, but there was
discussion in 147
... about the challenges in that RDFa people will be using different
labels because you don't have the context available in RDFa that we have
in JSON-LD.
... Do we need to talk about this?
<PaoloCiccarese> +1 to the namespace
ivan: To have that namespace document
before the end of the WG is probably a good idea.
... I can look at doing it, or someone else can. At this moment I cannot
do it and I think it should not have a high priority for the coming
weeks.
TimCole: Let's leave it in there and we'll get to it after Berlin, I guess.
ivan: A question to Rob.
... Rob, I am in a complete mess right now... what happens to the
vocabulary file and the context file that should be pushed on to /ns?
... I haven't done anything on installing it on the W3C side because I
have no idea where we are.
azaroth: I'm in the same state, I must admit.
ivan: At some point we have to do that. We
are already out of sync.
... By the time we go to CR, when tests become available, these things
should be in sync.
TimCole: Anything else?
... Thanks, everybody. We'll talk next week.
<ivan> trackbot, end telcon