W3C home > Mailing lists > Public > public-publ-wg@w3.org > October 2017

[Locators] Do we need to specify the 'result' of selections?

From: Ivan Herman <ivan@w3.org>
Date: Tue, 31 Oct 2017 11:38:03 +0100
Cc: Tzviya Siegman <tsiegman@wiley.com>, Garth Conboy <garth@google.com>, W3C Publishing Working Group <public-publ-wg@w3.org>
Message-Id: <480707D6-9FD6-4822-98D8-76A2F19F0238@w3.org>
To: Tim Cole <t-cole3@illinois.edu>, Benjamin Young <byoung@bigbluehat.com>, Robert Sanderson <azaroth42@gmail.com>
(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

This archive was generated by hypermail 2.3.1 : Tuesday, 31 October 2017 10:38:16 UTC