See also: IRC log
<trackbot> Date: 25 February 2015
<fjh> Agenda: https://lists.w3.org/Archives/Public/public-annotation/2015Feb/0154.html
<fjh> ScribeNick: dwhly
fjh: main topic is rangefinder api
... … implementations
<fjh> JSON-LD Introductory videos https://lists.w3.org/Archives/Public/public-annotation/2015Feb/0094.html
<fjh> LDP F2F likely to be 21st April
fjh: not sure what's going on w/ LDP f2f
shepazu: doesn't seem like there were a lot of LDP folks that could attend
... what's azaroth's role?
fjh: Ashok is working on this, wanted to share that this is being considered
<fjh> proposed RESOLUTION: 18 February 2015 minutes approved adding Rob as co-chair to minutes
<fjh> http://www.w3.org/2015/02/18-annotation-minutes.html
RESOLUTION: 18 February 2015 minutes approved adding Rob as co-chair to minutes
<fjh> http://w3c.github.io/web-annotation/rangefinder-api/
shepzau: discussions w/ tilgovi influenced approach
... at TPAC introd findtext API
... struggled w 2 architectures
... 1) treating this as a method on the element
... 2) having it as its own object, can execute it multiple times
... went with option 2
... went with attributes vs setters
... each selector is an attribute
... poorly described at this point, wanted to get something out.
... given all the selectors you'd kick off the search.
... (technical description complicated to transcribe)
<fjh> shepazu: hope you don't have to use multiple incremental searches, with appropriate selectors can return result in one pass
shepzau: a fjh: main design feature is that it has to meet the use cases and simple searches
... right now the find dialogs in browsers aren't exposed to developers
... a goal is to unify the search capabilities and expose these to browsers
... do we want to have strict case matches, fwd backwards, etc.
... do we want to have unicode mapping from o to o umlaut....
<fjh> http://w3c.github.io/web-annotation/api/rangefinder/
shepzau: these are the kinds of things that can allow browsers to implement this.
shepazu: one thing i didn't add was wraparound
... to the top of the search tree. it's the dom subtree in which we are searching
<Zakim> fjh, you wanted to ask about finding best match
shepazu: there are two ways of determining if we have all the results
... if you have wraparound you can do a detect if the result is same as previous
... doesn't handle changing documents
... and also doesn't handle realtime
... changes
... particularly realtime insertions that could affect the search term
... propose that he adds how you can tell that you've finished a search
csillag: in your intro you mention that there might be an application with content that could be searches and not searchable.
... text could be bigger than the DOM tree for instance
... with PDFjs
... do we want to support this use case?
shepazu: my impression is that the API should not address this use case. obviously this deals with specifying an element to search.
... the application itself could be aware that the entire document has not been presented, and could create multiple rangefinder instances.
... could try to look ahead to find things that hadn't been searched
... there are a number of techniques you could use to work around.
csillag: do we want to support several applications working together?
<fjh> what is the use case for applications working together?
shepazu: if they're both in the same document then the rangefinder would work as you would expect.
... if they're in two separate frames....
csillag: not asking about that
shepazu: if they're both in the same document. they could instantiate multiple rangefinders to target the specific areas.
... and display the results the as needed
fjh: i don't understand the multiple application use case.
csillag: let me restate. do we want to make it possible for applications to implement the native search capability.
shepazu: that's a browser UI question. up to individual browsers. not for us.
csillag: do we want to provide capability that could augment the browser's native search. we might want the browser to search inside the document. we'd need another api that could inform the browser where the actual searchable content lies.
... this is the same as the two application situation.
shepazu: i want to split out the discussion. you're talking about a couple different things.
... common knowledge in W3 circles.
... there is a separation between chrome/UI features and DOM features.
... in the past browsers have been insistent that we not try to describe things that are UI features.
... i think there would be a lot of resistance to that.
... that's a non-starter. there are two paths forward
... 1) you can do what they do today, which is to override the native search capability. if I use ctrl-F in google docs, then gdocs grabs the keys and does it itself.
... what i propose is a compromise, we expose the functionality, but that we override the native search functionality.
... if that's successful, then possibly we come to
... 2) browsers decide on their own to expose this functionality and expose an API for developres
... for example, not every browsers UI let you do case matching, wrap around, etc.
... it could be that if they implement this, they add those elements
... it would be a very different API if we had a different way to push results into the browsers native API
csillag: ok, forget that, lets focus on the other.
... (missed the question)
shepazu: we can either have multiple rangefinders, or we can have one whose parent contains both.
... i don't know what you mean by multiple applications
... either they're friendly and they expose their APIs. it's up to the applications expose their search capability.
fjh: good questions, but can you write these downs and submit to the mailing list.
shepazu: can i add one thing to the minutes...
... kristof reminded me that we assume that everything we're searching for is in the DOM, but we could have a big body of text that hasn't been inserted yet.
... we might want to search that instead.
<csillag> We are doing lots of fun things with pdfjs
<csillag> not sure what you are asking
shepazu: one of the optimizations that pdfjs makes is that it doesn't render the DOM all at one things
... but it already has all the content in memory
... so, it searches within the bytestream as a look ahead... and then informs PDFjs this is the part they want to navigate to.
fjh: 1) yeah makes sense, 2) is this a v2 feature?
... it's complicated already, can we simplify.
csillag: we can keep it simple if we define the extension points.
... could provide the text we want to search on.
... extension point would allow overriding the text we want to search on.
... pdfjs could provide the whole text for instance.
shepazu: two possible extension points 1) here's a block of text you want to search on
... 2) not an extension point actually. this app is not designed to be the sole search capability. it's designed to be an instance.
... the extension point is actually not in the application itself but in the way it was designed.
fjh: Kristof I think it would be very helpful for you to send an email with your issues and ideas to the list, so we can consider and see if we've missed anything
<Zakim> fjh, you wanted to ask about need for html canonicalization for whitespace or selector canonicalization
fjh: i was looking at examples at end of doc. will these work in various cases, whitespace, line breaks, parsing, etc.
shepazu: two ways to answer: 1) yes, the DOM4 or HTML5 spec has a normalize capability
... i need to make this more explicit. there's a big part of the spec that's missing.
... the algorithms are missing.
... 2) you might want to search in a white space sensitive way.
... search for two spaces separated by another word. not sure how difficult that would be.
... not sure the use cases justify it.
fjh: as a developer i don't need to worry about normalization.
shepazu: i need to explain it in the docs.
... honestly, I could walk through the issues. it's more important to work through issues i know are unaddressed.
fjh: matter of using algorithms that already exist
shepazu: there is a lot of prior art on this.
... i'm not qualified to read all the literature.
... more efficient to get this to the state where it's credible and then ask folks.
... levenstein is still alive!
... more than most other W3C specs this is in a space with a lot of literature.
dwhly: there's a list at the bottom of our fuzzy anchoring blog post
shepazu: this isn't done there are huge gaps.
... i'd much rather receive annotations than emails
<fjh> https://lists.w3.org/Archives/Public/public-annotation/2015Feb/0144.html
shepazu: benjamin sent a message on this, benjamin?
bigbluehat: i've added some wiki pages one for annotations feeds, one for [ ]...
... i'd love to find other prior implementations for atom feeds
... right now I'd just like to collect and gather them
... i'll drop the links in the chat
<bigbluehat> Annotation Feeds wiki https://www.w3.org/annotation/wiki/Annotation_Feeds
fjh: the search related to feeds looks like it can get complicated. do we want to delve into this?
bigbluehat: sure, lorestore included their own search endpoints
<fjh> so we can keep this simple with focus on annotation feed format and possibly simple discovery
<bigbluehat> Existing Protocol Implementations wiki https://www.w3.org/annotation/wiki/Existing_Protocol_Implementations
fjh: when we say discover what are we saying?
bigbluehat: that needs discussion... there are a lot of places to provide the discovery
... it's helpful if we can separate that.
... they could all be shipped as separate thngs.
... if you have your own CMS that implements it, etc.
... we can expect that people will ship their own annotations as a feed.... etc.
fjh: don't want to ask questions... oh i do have one more
<fjh> fjh: do you think topic maps might be relevant to organizing annotations
shepazu: i think the idea of topic maps has become superceded by hashtags and other things
<fjh> shepazu: superseded by tagging
shepazu: the advantage of a topic map it's a defined vocab. and enables synonyms
... but not sure it's common practice
<fjh> Lorestore, https://lists.w3.org/Archives/Public/public-annotation/2015Feb/0141.html
<fjh> Protocol Reference Work: Annotopia https://lists.w3.org/Archives/Public/public-annotation/2015Feb/0156.html