Web Annotation Working Group Teleconference

<trackbot> Date: 21 October 2015

<azaroth> TPAC Agenda page: https://www.w3.org/annotation/wiki/Meetings

<azaroth> Chair: Rob_Sanderson

<azaroth> Scribe: Tim_Cole

<ivan> scribenick: TimCole

<azaroth> ScribeNick: TimCole

azaroth: no conference call next week because of TPAC
... will decide about post-TPAC call (1st week of Nov) while at TPAC

Minutes

<azaroth> proposed RESOLUTION: Minutes from 21 September approved:

<azaroth> http://www.w3.org/2015/10/14-annotation-minutes.html

RESOLUTION: Minutes from 21 September approved: http://www.w3.org/2015/10/14-annotation-minutes.html

State proposal (Benjamin)

<azaroth> https://lists.w3.org/Archives/Public/public-annotation/2015Oct/0106.html

bigbluehat: hypothes.is we render pdf through pdf.js, will do same with EPub or may use Readium
... the DOM layout in the PDF rendering has changed several times, requiring us to fall back to fuzzy anchoring, etc.
... but if we recorded the viewer used when annotating we could fall back better
... in html we use an XPointer approach, but even there you might want to know that viewer being used
... if all you record in the annotation is the selector with out regard to viewer you could have issues
... know the viewer allows you to do more

<Zakim> azaroth, you wanted to ask if the "state" is about the annotation creation state, or the representation state of the resource

azaroth: the state that you're interested in is the state of the renderer of the resource when the annotation was created
... not the state of the resource at a particular time, or the representation provided to the viewer
... could hasState be used to record this?

bigbluehat: it is not really request state, but it is rendered resource state (i.e., client side)

azaroth: regardless of how the information is recorded in the annotation, what would a subsequent client use this information for
... so if you used a particular version of pdf.js and htat was recorded, a client could revert to that version?
... or have some other intelligence to help recreate the proper anchoring.

bigbluehat: the client could choose the right viewer, decide when to go to fall back, etc.

azaroth: it seems like to me that a generator might be sufficient, so hypothes.is and the version of pdf.js used

bigbluehat: perhaps, you need to understand the selector in light of the generator
... you need to understand from the generator (or whereever) that this resource was rendered this way.

shepazu: generator makes sense, but is the annotation being created through a component of hypothes.is rather than the whole thing
... the generator of that annotation as a whole is a package, but the component doing the work may be external to the package
... sensible to think about multiple strings for generator, but it is not exactly a good fit to current understanding of generator
... but seems state-like as well
... people are going to use non-standard states, and arbitrary values in generators, making it hard for other engines to adapt to it

<bigbluehat> agree on the !generator stuff

<Zakim> azaroth, you wanted to agree re !generator

<azaroth> http://www.idpf.org/epub/oa/#h.sfczx2yhse91

azaroth: I am convinced about state rather than generator
... equivalent to EPub rendention state
... EPub clients make use of rendition state in a similar fashion to what's wanted here.
... perhaps there is a generic rendering state property, but not sure what that would be
... perhaps we want to discuss DPub folks during TPAC

<azaroth> +1 to avoiding "Best Viewed in X"

shepazu: i do get uncomfortable talking about having to use a particular generator product

<bigbluehat> agreed. this can also totally be ignored by the consumer--and should be speced as such

shepazu: so would prefer not to say 'this is best viewed in IE' (or whatever)

<bigbluehat> the other states can also be ignored, fwiw, if someone wants to attempt reanchoring on the "latest" etc

shepazu: something more generic would be better, and avoid browser-sniffing
... some mix of standard rendering state values and custom values

bigbluehat: this should be optional, and should not change our understanding of selectors in general. Mostly for optimization and should be safe to ignore.

azaroth: I noted that different browsers and toolkits will rewrite HTML to insert extra nodes, etc. Maybe we could align with that sort of thing
... and say here is a transformation of the original resource on which the annotation was made.

<Zakim> azaroth, you wanted to note HTML rewriting?

azaroth: less about the agent and more about the format and structure on which the annotation was made.

<bigbluehat> So. It strikes me that all of this is actually Selector related

shepazu: we could say that the resource was modified like html5 is modified when rendered, and this is what you need to know to understand the annotation
... the question is where do we put this in the data model

bigbluehat: a lot of our original use cases from DPub were about optimizing the selector
... and a lot of this needs to be about optimizing the selector and deciding when to fall back (when you can't reconstruct the rendering state)
... we want to be careful not to invite viewer-specific fragment identifiers

shepazu: are you suggesting it needs to be on the selector not on the resource state?

bigbluehat: yes, if I knew that the XPath selector was for the PDF, and then made an equivalent anchor in another format, that's what I want to make sure is possible.

ivan: what's the next step

<bigbluehat> +1 to discussing with DPUB

azaroth: we should discuss with DPub at TPAC, and potentially also without other folks (e.g., HTML 5 rewrite)

ivan: must be careful not to mix up EPub and DPub in our discussions next week
... DPub has not really looked at details of annotation in EPub.

azaroth: Benjamin, can you work up a proposal such that we can discuss at TPAC internally and on the mailing list?

<bigbluehat> +1

<azaroth> ACTION bigbluehat to create draft proposal for Rendering state/selector

<trackbot> Created ACTION-29 - Create draft proposal for rendering state/selector [on Benjamin Young - due 2015-10-28].

Agenda for TPAC

<azaroth> https://www.w3.org/annotation/wiki/Meetings

azaroth: first day mostly meeting with other groups and talking about client side issues
... and coming to grips with the second half of our deliverables
... second day will be more about protocol and other issues.
... this accommodates Doug's schedule.
... there are some open, unstructured times to discuss other issues as needed.
... but want feedback from those who are going to be there.
... in particular are there other joint meetings needed.

shepazu: only the last quarter of the day would be focused on findText
... not sure how much we can get done on clientAPI if Nick isn't there

azaroth: will update agenda accordingly, but need at least a brief discussion of what we need to do and how we're going to get there.

ivan: on social web slot, do we have people from the social web grouop? who will be around?

azaroth: at least Sarven and Amy Guy
... if it turns out we don't have enough from social to make it useful, we will still have other protocol issues, e.g., search, to make progress on.

<chrisbirk> I will not be able to make it there, correct

ivan: at some point we have to begin discussing about testing
... we need to start by looking at what do we want to test? What are the things in the spec that have to be tested.

<Zakim> azaroth, you wanted to suggest testing at 1:30 Monday ?

ivan: in some cases relatively clear, in other cases not so much.

<shepazu> +1 to talking more about testing in general

chrisbirk: will not be at TPAC, but happy for conversation to start at TPAC and then come in with first call after TPAC.

azaroth: suggested a specific slot for this discussion.
... one more topic -- priroritization for notification
... should we work on search or notification first? will social deal with this well enough for us?
... notification, for example, is about the publisher of a target gets notified that an annotation has been made

shepazu: are we encompassing notifications of annotations of annotations, they might have different mechanisms for subscriptions (for example)
... seems like there are a whole bunch of potential channels for notification, etc.

<azaroth> use cases ++ :)

<bigbluehat> yeah...those

shepazu: we should start by spelling out what we mean by notification

azaroth: having use cases should be one of the first steps
... this is definitely something to discuss when we have social WG members in the room
... distinguishing between annotation requriements and social requirements.
... propose to put notificaiton in same slot as social, search right after lunch, model after the break...

ivan: comment - there are 2 issues with social. 1) notification, 2) design choices that each of the groups have made and there is feeling that these decisions should align
... not sure if we'll have right people there

azaroth: James Snell would best on this topic, but he won't be there. We can still bring the issue up and then move to email.

good, scribe has to leave in 4 minutes

azaroth: Reminder no call next week, may be a call in 2 weeks

shepazu: calling into TPAC?
... no infrastrucutre in place, but we could set up skype or some other ad hoc method

ivan: and a WebEx room is available if we need it (assuming someone at TPAC has a computer with WebEx).

adjourned

<ivan> trackbot, end telcon