(If you are not yet familiar with all the details of the locations, this may be noise for you; sorry…) Tim & Co, this is just general musing, hence sending it to the ML and not raise this as a specific issue. What the Locator draft[1] defines is a way to express various types of selections. This is in line with what (afaik) EPUBCFI did, but is also in line with the origins of [1], namely the Annotation Spec; after all, what the annotation spec defines is a data format aimed at interchange among annotation systems, and the selectors were part of that. However, if we consider [1] in the setting of Web Publications, we may want to have a world where a WP implementation consists of a number of interrelated items, javascript programs, polyfills, whatever; the question whether we want to, or whether we have to, define some level of interoperability of possible modules. I guess, fundamentally, what I am looking for is to understand what it means to implement [1]. Would there be a "locate" function that would return… return what, in fact? A data structure referring to URL-s and references to DOM nodes? If so, how would that look? More importantly, do we need to formally define the return structure? I guess those of you who have been part of Annotation implementations have more idea on how selectors were implemented internally, and may have, therefore, a better idea. Similarly, those of you who have implemented EPUBCFI even for internal reasons may have a better idea, too... So… WDYT? (I realize that we may enter a slippery slope; doing this for locators may open the flood gates of defining other API-s around WP, and I am not sure we should do that…) Cheers Ivan [1] https://w3c.github.io/publ-loc/ <https://w3c.github.io/publ-loc/> ---- Ivan Herman, W3C Publishing@W3C Technical Lead Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/> mobile: +31-641044153 ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>
Received on Tuesday, 31 October 2017 10:38:16 UTC