See also: IRC log
ivan: any reason not to accept the minutes?
... minutes accepted
ivan: item on the agenda is findtext
shepazu: we got some feed back from TPAC.
mixed. some like the idea, some had problems. am trying to put them on
github. meantime.. some minor typos like that i am cleaning up
... dont feel like we have enough substance re which direction to go. am
trying to get people to do a tech review of it
ivan: one tech discussion before TPAC:
usage or not of promises
... we have to ask someone who is better at it in understanding promises
shepazu: lets ask someone from the TAG
... make it an issue (ivan will do it)
ivan: pending discussion at TPAC - whether to keep 1 big entry in the api or simple + 1
shepazu: not got feedback on this yet from
anyone
... prob we will hear more after xmas
<shepazu> https://github.com/w3c/findtext/issues/18
shepazu: it is caputured as issue #18
... another thing. a feedback i got at TPAC (from Paul Cotton?): the use
cases - dont know if we have concrete use cases about robust anchoring
or deep linking.
... i could use some help about documenting so we can communicate why i
made the choices about it.
... (dinesh will help)
... paul said that the case was not presented well on why they had to be
different. 1) needed to be parameterizable (param: fragment identifiers)
<Jacob> Tim and I will look at CG use cases to see if any might apply. If so, we will add as issue on current document.
<Jacob> Please do.
<Jacob> make a wiki (probably github wiki?)
shepazu: will make a page on the github wiki
<shepazu> https://github.com/w3c/findtext/wiki/Use-Cases
ivan: we should make some sort of planning.
do we have any idea on how we develop findtext
... we will need a fairly aggressive schedule
shepazu: i think the next step is simply to get feedback.
ivan: can we reach out for somebody re promises issue
shepazu: will reach out first to Dominic Denicola;
shepazu: i could get try contact Travis,
and possibly inviteĀ to this call
... (re browser acceptence)
ivan: that would be 1 more microsoft and we need from from others (like chrome)
TimCole: one thing that comes up: where in the original blog .. (can hear well) .. i would be interested in surfaceing such use cases. need to think about additional doc
<Jacob> TimCole: one of the CG use cases was how blogs are a chain of annos
<Jacob> ... would be helpful if the addons could be linked to places higher up in the chain
<Jacob> ... seems like the data model, findtext api, etc. could be helpful
<Jacob> ... would like to get conversations about this, rdfa, other microformats started to determine if we are already accommodating it enough
<Jacob> ... or if we need something further down the road. mainly getting it on the radar for now.
<Jacob> shepazu: realistically, probably won't get traction from conceptualizing blogs as a chain of annotations
shepazu: 1) while i can see why you say
blogs can be seen as a set of annos, realistically thats not how we get
traction as thats not ho wppl think of blogs today
... where we could get traction is comments and footnotes, as ref to
content
<Jacob> @shepazu, I'm pretty sure that Tim was talking about the comments and footnotes and their relationships to each other and the original blog post.
shepazu: we need to figure out a cannonical
serialization .. many annos are going to bethings that are ultimately
rendered in html
... but if we have a few elemnts that cannonically fit the model then we
can get ppl to start rendering their annos in (to a datastructure)..
<shepazu> http://schepers.cc/annotations/note-element/note-element.html
shepazu: an example page playing with
footnotes and what behaviour .. about notes. eg., blockquote
... where you quote wht a person said and you say something about it
<Jacob> Is the expectation that implementers are using this instead or within the context of kinja or disqus or similar commenting widgets?
shepazu: if you look at the source of the
page you can see it maps back
... i am thinking footnotes, comments, user generated social feedback
like tweets
TimCole: (lost sound)
shepazu: experts disagreed. when i looked at the resulting syntax, .. with rdfa .. i have given up on ppl undestaning namespaces
<Jacob> TimCole: if we want to raise this as an issue, where do we put it?
<Jacob> shepazu: maybe a branch called serializations
<Jacob> ivan: create a separate label
ivan: have separate labels for this
... as a tech comment, as one of the authors of rdfa, i agree. as the
structure gets complicated it has the draback as more namespaces are
used
shepazu: we need our own set of attributes adding decorators at the element level
ivan: agree, data attributes are not the accepted way
shepazu: not that we shd not have rdfa serialization but that it is not the reference one
TimCole: we are going to move forward with
rdfa for now
... next few months and maybe we get better ideas
ivan: once the document becomes stable, we code them in rdfa
TimCole: we can certainly do that for ones with html examples
ivan: doug do you know what the current state is of web components
shepazu: i am using the web components
model to define a prototype
... only google and microsoft are looking at this seriously and i dont
think this will be ready for 2 or 3 yrs
... dont see what that as to do with this
ivan: so its not your proposal to use web components here
shepazu: no
<tilgovi> web components is an umbrella term... some things are proposed or standardized: shadow dom, custom elements, html imports
<tilgovi> "web components" is not a standard itself
shepazu: web components are used by web
developers and if they come up with a good idea, it will be standardized
and will be put up in the html namespace
... tim will raise the issue
<TimCole> bye bye
<ivan> trackbot, end telcon