See also: IRC log
<ivan> trackbot, start telcon
<trackbot> Date: 07 October 2015
<fjh> trackbot, start telecon
<trackbot> Meeting: Web Annotation Working Group Teleconference
<trackbot> Date: 07 October 2015
<ivan> https://www.w3.org/Member/Mail
<ivan> scribenick: bjdmeest
<fjh> central script repository - https://lists.w3.org/Archives/Public/public-annotation/2015Oct/0001.html (Doug)
<fjh> webex issues on chrome for mac https://lists.w3.org/Archives/Public/public-annotation/2015Sep/0228.html
<fjh> proposed RESOLUTION: Minutes from 30 September approved, http://www.w3.org/2015/09/30-annotation-minutes.html
RESOLUTION: Minutes from 30 September approved, http://www.w3.org/2015/09/30-annotation-minutes.html
<ivan> Chair: fjh
<fjh> http://w3c.github.io/web-annotation/model/wd/RequireSpecificResource.html
<fjh> discussed on last call, http://www.w3.org/2015/09/30-annotation-minutes.html#item05
TimCole: There were 3 things
... 1: consensus: allow embedded content in SpecificResource
... 3: multiplicity: where do roles come in multiplicity
... defer 3
<Jacob> That's my recollection too. Multiplicity is going to be a complex topic so best to defer until after the next release.
<fjh> Second was need for subclass for embedded content
azaroth: subclass of embedded content...
embedded content is for included resources that are not necessarily body or target
scribe: e.g. inline svg or css
... those resources shouldn't have roles
... subclass TextualBody could have 1. role associated with it but not
embeddedContent
... 2. you have a nicer class when you don't want to embed svg or css
shepazu: I don't think this or any issue
should stop us from publishing a WD
... they don't have to be perfect
<ivan> +1 to Doug
shepazu: as long as we have general consensus that the spec has improved
<fjh> +1 to publishing early and often
<azaroth> Also +1
shepazu: my opinion now: I think
consistency, a single clear way, trumps simplicity for simple things
... one level of hierarchy is not a big price to pay
... that added complexity also adds options
... consistency is better for understanding, writing parsers, etc.
<azaroth> +1 to a consistent model
<Jacob> +1 for consistency
fjh: proposal 1 introduces complexities, last weeks poll there was consensus for proposal 2
azaroth: we might not be able to break this
apart, there are consequences
... example: if SpecificResource is required
... then it should be introduced much earlier
... so +1 to keeping current draft
... trade-offs of consistency vs flexibility
fjh: we should get the draft published
<Zakim> shepazu, you wanted to discuss point of order
<TimCole> +1 to publish using best guess now
ivan: we have more or less an agreement, this is the direction we take now, let rob and paolo finish the document, discussions can happen once the document is more stable
<Jacob> +1 to what Ivan is suggesting
ivan: cfc is not necessary
<fjh> +1 to not requiring CfC for publication ( was not suggesting that) also agree we need clarity on decisions
ivan: in practice, we can just go on and publish
TimCole: agree with Ivan, cfc should come
after next publication, if needed
... there is a trade-off: more classes to avoid hierarchy vs. patterns
to be more rigid about hierarchy
... we have to allow literaltext as bodies, and have roles on that
... a next class for that seems, to me, too much
<Jacob> If we didn't have another class then I'd just want to shoehorn it in as a sub-class of specific resource so...
TimCole: so let's take best guess on multiplicity, and see what happens when implementations catch up
<Zakim> azaroth, you wanted to note multiplicity
azaroth: cultural heritage community has
implemented multiplicity
... eg multiple images that depict one object (e.g in a museum)
... they use choice
<shepazu> (I tend to think that some sort of choice mechanism is pretty important, though I fear the complexity of a general solution)
azaroth: depending on location, quality of
picture, etc, users can choose
... Composite and List, not really found (except maybe List in DPUB)
<Jacob> Ordering is verbose in RDF
<Jacob> and so fairly tedious.
<ivan> (well verbose and ugly, although conceptually simple)
shepazu: I think ordering is difficult in
RDF, a sequence is very important for some (e.g. priority, selectors),
not that important for others
... construct specific for use case could be more simple
<davis_salisbury> +1
azaroth: more focussed, the better, so
use-case driven is good
... to complete the implementations (cfr charter)
... we'll continue with the WD as it stands, multiplicity could be
handled at TPAC
shepazu: I put something together, fit for a FPWD
<fjh> https://lists.w3.org/Archives/Public/public-annotation/2015Oct/0017.html
shepazu: we got technical feedback from WebApps (great!)
<fjh> http://w3c.github.io/findtext/
shepazu: feedback1: what about Shadow DOM (a
way do develop custom components, to be reused, e.g., a slider)
... behind the scenes of the slider, a tiny DOM is added underneath the
<slider>-element --> shadow DOM
... shadow DOM increases the complexity of the tree, so will have effect
on FindText
... no good way to represent ranges in shadow DOM yet
... feedback2: positive feedback from google Japan, connected me with
Yandex people
... he pointed out serializing DOM is not only way, 2 other
(non-standardized) methods exist
... but it's out there :)
azaroth: cfc is out, +1 is encouraged
TimCole: what were the other serialization methods?
shepazu: textSerializeAPI, which is done
under covers
... of browsers
... findText uses hidden - but similar - mechanisms under the hood
... for at least Blink and Gecko browsers
TimCole: better strategy is making these hidden mechanisms normative?
shepazu: if we specifying currently existing mechanisms, it slows down the spec, but speeds up the uptake
<azaroth> +1 to paving cowpaths
<fjh> need 5 min for that
fjh: last possible publication date is 20/10
... we need to do an e-mail, also takes some days
... maybe we need a (short) cfc
... if we want to publish before TPAC, there is tight timing
shepazu: FindText needs formalities (because FPWD), other publications do not
<azaroth> +1 to auto publishing
<fjh> +1 to auto piublishing
shepazu: what about: cfc now, whether to publish or not
<Jacob> +1 to no CFC and +1 to publish
<azaroth> Draft: http://azaroth42.github.io/web-annotation/model/wd/index-renamed.html
Topic model draft
azaroth: up to 4.4
... should be done by tomorrow
... working on protocol next
<fjh> ivan, can you please set up auto WD publishing for model and protocol so Rob can use it?
azaroth: we should be easily good to go for
a publication next week
... protocol has less text, and significant change is about paging, so
that should also go quickly
fjh: you can send cfc when you are done with
the draft
... cfc until tuesday, publication request for thursday
... about protocol, maybe not that urgent
azaroth: maybe we can publish the protocol document by the 15th or 20th
fjh
fjh: joint meetings: social is possible,
DPUB request has been sent, WebApps not necessary, TAG is constrained on
monday, I18n also sent request
... breakout is possible, if anyone can lead
azaroth: I will be there
fjh: breakout can be used to reach out to community
azaroth: I can lead the breakout, at least
for model and protocol
... can FindText also be put in the breakout session?
shepazu: I think it is appealing to a larger group of people
<azaroth> ACTION azaroth to set up wiki page for breakout on Annotation
<trackbot> Created ACTION-28 - Set up wiki page for breakout on annotation [on Robert Sanderson - due 2015-10-14].
fjh: exact planning for TPAC is pending, depending on the answers of the other groups