See also: IRC log
<trackbot> Date: 11 March 2015
<fjh> Agenda: https://lists.w3.org/Archives/Public/public-annotation/2015Mar/0037.html
<fjh> ScribeNick: azaroth
<stain> I can scribe when azaroth is talking
<fjh> Thanks to Rob and Stian for scribing, no announcements.
<fjh> proposed RESOLUTION: 4 March 2015 minutes approved, http://www.w3.org/2015/03/04-annotation-minutes.html
RESOLUTION: 4 March 2015 minutes approved, http://www.w3.org/2015/03/04-annotation-minutes.html
<fjh> Social Web F2F and preparation, https://lists.w3.org/Archives/Public/public-annotation/2015Mar/0016.html
<fjh> Discussion items https://lists.w3.org/Archives/Public/public-annotation/2015Mar/0018.html (Randall)
<fjh> More Discussion https://lists.w3.org/Archives/Public/public-annotation/2015Mar/0024.html (Benjamin)
fjh: Social web f2f next week. 2 days in Boston. Randall, Benjamin, Frederick attending
Paolo: Will try to attend
fjh: Plan to go first day at least. If you can go, put your name on their wiki.
shepazu: Had thought about it, but because there are others from the Web Annotation WG attending, decided against attending for budget reasons
fjh: Talking about the data model, and how we fit in with activity streams. Wondering about their vocabulary, and how annotations fit in
... Federation is also interesting, to share annos across systems
... We need to do a bit of preparation before the F2F
... Do we need additional actions or hooks, need to compare notes on LDP
... If you can respond to the message on the list, that would be helpful
... Does anyone have anything that would be helpful?
<fjh> azaroth: had discussion of fit after TPAC so should review that
<stain> ScribeNick: stain
azaroth: just too remove the assumption that non-annotation blobs would be handled by the same protocol
... if you have an annotation with a body, it's out of scope for the annotation protocol to say how that video ends up in the system
... we could add something about that..
... but it would be outside the Annotation Protocol
<scribe> ScribeNick: azaroth
fjh: IndieWeb ideas of hosting your own annotations as well
... These might fit together too, but haven't looked at the details. Might fit under Federation
shepazu: IndieWeb approach has some bits and pieces. Would be good to find some way to pull that work in.
fjh: Don't see why that can't be the case. Should be able to work together. Differently administered systems should work together.
shepazu: Think their response would be just to use HTML
... and decorate with microformats
... would be good to find a way to co-exist and find mutual aspects
fjh: Agreed. We need to get it on the table.
... Anything more about the Social F2F?
... Otherwise please share on the list. I'll check in with others before hand.
... Not sure we'll have enough time to run everything by the WG, so long as it's clear it's not a WG statement
... But we only have a week
shepazu: Agreed. Not sure we have a grand strategy, so probably better for individuals to state their own views
fjh: I think we're set for that.
fjh: Any new news?
<fjh> azaroth: nothing new, calls every other week, slowing down preparation
<fjh> azaroth: ashok has asked sandro about funding for food, dan has prepared room, thanks
shepazu: Not our topic any more.
<fjh> RangeFinder discussion https://lists.w3.org/Archives/Public/public-annotation/2015Mar/0023.html
<scribe> ScribeNick: azaroth
fjh: ... Good message on the list, think we should talk about it.
shepazu: Read it, and have some other aspects.
... immediate reaction is that it's a real use case -- something might not be in the DOM
... less sympathetic to pdf.js case, as PDF is not very web friendly
... more sympathetic to the infinite scroll use case
... where you don't know if entire document is in memory or not
... looking through Cristof's email, impression was that would make it more complicated
... not sure the place to solve it is in this API
... One of the new things we're trying to do is to break them down into building blocks
... so can reuse in multiple situations
... and make simple APIs that plug together
... talked to Peter Linss of CSS WG, and he suggested making it simpler would be better
... so going to remove many attributes, as you can do it with other parts of the platform
... should use query selector API to find something and turn it into a range, which would be input to this
<fjh> +1 to simplification by using pipe model as appropriate
shepazu: then increase the odds that implementers would use it, and decrease up front design
... JS devs can already find ranges, should reuse it
... so get rid of XPath, query, etc and you put in a starting range.
... unicode string matching as well, e.g. e with acute accent, such as fiancee but don't necessarily spell it that way
... so if I want to search for a word, I'd rather find matches and collapse them
... Peter suggested that functionality should be elsewhere too
... So the question becomes should we be adding new functionality to search in non DOM contexts, or should we find some way to provide a DOM context to content not in the document
... which would allow other things than search
... so should try to find a way to fit non DOM content into the DOM as general functionality
fjh: to summarize, we have to get the layering and simplicity right
<csillag> Excuse me, I can't unmute my stupid phone
<stain> ..always fun with Zakim insisting on his full attribution befroe you are allowed to enter the code..
csillag: in favor of making general APIs if we can do it without losing functionality
<fjh> csillag: realistic need PDF
csillag: in our implementation we didn't build a dom finder, but used generic finder and interfaced with DOM
... all for building smaller more reusable parts
... some cases harder, e.g. for non DOM use cases
... would like to see the specs to figure out how much sense it makes for our use cases
... likely too hard to do over a call, should discuss in email
... would like to see more of the context
shepazu: haven't gotten around to updating, but will do soon. will include examples of use in the revised way, so code samples
... useful for the discussion phase even if they don't end up in the final version
... on range finder vs dom decoupling, I think that's reversing the order of priorities
... Essence of range finder is DOM, a range is a specific entity in the DOM
... not just a text / character offset.
... Point of the range finder is to find a piece of content and return the Range including the elements it pertains to. So decoupling range finder from DOM seems like it misses the point of what the API is
... concerned that we would make it harder to work with if it is decoupled
... muddies what the return value is
... Not sure what the result would be if it wasn't on DOM
<csillag> I have answers to all those questions,
<csillag> let me know when I can speak
shepazu: makes it harder to decide when text is or isn't in the DOM
... possible solutions: 1 -- put the text in the DOM somehow, 2 -- use a different technique
csillag: talking about 2 different things
... first issue is finding the piece of text. Then export to the js. and then get the DOM range for it
... end of the first stage just finding the text
... end of that phase isn't a range yet, just a data structure
... the next phase you can get the range for it, if it's in the DOM
... second phase can't be decoupled
... then third phase is to use selectors
... if we drop the first phase, we're just kludging the first phase into DOM ranges
<stain> ScribeNick: stain
azaroth: question about scope of work for annotations if there's going to be designing an API that is of general use and far beyond that
... we would need to be actively involved in ??ex people to work through the use-cases they would know about
... trying to solve it in a general way, rather than trying to solve it in an annotation (??) way
fjh: important to think about phases.. can see how it can simplify testing
<scribe> ScribeNick: azaroth
shepazu: Would be happy to separate to multiple specs
... matching the text bit should be in its own section
... agree that there's two things. I'm working on phase two, finding content and returning its dom range
... if there's suggestions for how to handle the other parts, that would be great
<fjh> we need to get this discussion on the public list
shepazu: also text that hasn't been loaded yet. Maybe the ultimate solution combines text finder, range finder, and server side components
... then collate the results to have a coherent solution
<fjh> server side search
shepazu: Re idea of use cases / requirements, would be wonderful to have them, but the process can slow or stall work
... would prefer to do them in parallel as thinking through the API lets us think about use cases
... and needs to be implemented/reviewed anyway
csillag: not sure if it's robust if it's split up and simple. Still anchoring but how robust is it?
... can improve naming of course
shepazu: Not talking about dropping fuzzy anchoring
csillag: But that starts with the collation of information -- you really need the first part too
fjh: Need a summary of the key points, separate from the spec
... then look at gaps from the use cases, what's important and so forth
shepazu: Will make changes to the spec and send a mail to the list
... helpful to talk about things
fjh: Yes, but hard to keep things on track. Don't want to just have people talking past each other
... simplification is good, but if it loses the use case requirements, that's less good
shepazu: The current API doesn't handle those use cases
... there needs to be additional work beyond what I'm doing
fjh: But it would be related, and we need to maybe layer it differently
shepazu: Not that changing it, just that they were never covered
... should be covered somewhere else
... we don't have to make everything part of one API, can have multiple
... the application can then use them as it sees fit
... it's in the web application layer they should be merged
<fjh> we need roapmap and idea of the architecture
fjh: Need an idea of the architecture then
<fjh> ScribeNick: stain
azaroth: not sure there is a data model point we could cover
... any advances on use-cases and/or perhaps ...
fjh: need to figure out the issues and (?)
azaroth: it would be good at technical work of (?) and does it cover what it indended to cover - and for what it doesn't cover, is it easy to work on another API to add those
... agree with technicalyl everything that has been said
... PDF is a real usecase - as much as we want everything to be HTML
... cross-format annotation is something we have talked about
... having an architecture for what this API container (??) this area it leaves alone, and this is how you would implement a different usef case with a different API
... that would probably be easiest way forward to ensure that we cover all of the requirement that we have in our stufF (?)
fjh: and doug's suggestion has a lot of merit, as way to (?A) to make it easier implement - be clear about what we are doing and not doing, what is supported and not
<azaroth> ScribeNick: azaroth
shepazu: scope of what we've talked about in the charter
... this is the web annotation wg, not everything in the world annotation wg
... the main use case is on web
... plugging this into web use cases and leaving extensions for other formats
<Jacob> So the assumption is all HTML all the time?
shepazu: works in PDF JS not a pdf document
... extensibility points are good, but we're trying to solve web applications
... don't mind if there's other things, but that's not what we're working on
<fjh> ScribeNick: stain
azaroth: agreed - however.. (?) the Web Platform is the focus, not the lower-case web
Stian Soiland-Reyes
azaroth: ... using the components of the web platform.. .. (?) can ..
... web is our main focus - but given the current environment, it's not what we're designing for a perfect world, but to be useful for people
... and that would involve handling things slightly outside the perfect world
... and there might be other directions where the same functionality would be useful
... we should not discard things that are not in.. ? the perfect world
shepazu: I'm talking about client-side APIs and the implications there
azaroth: how to deal with PDF rendering is a client-side issue (?)
<paoloC> but PDF.js produces still a DOM
<fjh> ScribeNick: fjh
azaroth: should consider PDF given that browsers handle PDF these days
shepazu: am i wrong about PDF
<scribe> ScribeNick: stain
shepazu: so PDF.js documents is an approxmiation.. it's not the same data structure you would see in a native renderer
<fjh> ScribeNick: fjh
csillag: partially, much can be handled with PDF.js, more limited than full PDF implementations
<azaroth> +1 to csillag
paoloC: PDF.js as well as other renderers all produce a DOM, but the DOM is very intricate, doesn't look like a web page
<stain> my main point: Even though the DOM is made by an application like PDF.js or any Ember.js-based application - it's just a UI application and not a document suitable for annotations
paoloC: structure is complicated, can still search it
<stain> just like you would not annotate emails in GMail by describing the element in the HTML that is open
shepazu: each structure is unique it itself; an HTML5 web page sent to browser will all make same DOM from it
... consistent DOM
... no consistent DOM between PDF renderers
csillag: correct
<stain> and although our annotation model is for Annotations on the Web - it is usually good to be closer to the data model than the rendering - so annotations on a PDF rendered in PDF.js should ideally talk relate to PDF elements, e.g. a position on the page
csillag: PDF.js best way to copy paste, avoid any direct references to DOM
<azaroth> +1
azaroth: doug can you send to a list a summary of problem rangefinder is intended to solve
shepazu: yes
fjh: thanks all
... I'll generate minutes, much thanks Rob and Stian for scribing
<stain> so we want to use the Annotation model in a web application that is displaying chemical molecules -- the annotations created by the user is related to the URI of those molecules - not to our particular presentation (that is the oa:hasScope)
fjh: thanks Doug for the work on RangeFinder