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

Re: Comments on "Locators for Web Publications"

From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Date: Mon, 11 Dec 2017 18:43:26 +0100
To: "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>, "public-publ-wg@w3.org" <public-publ-wg@w3.org>
Message-ID: <a4728e41-ccad-b844-1af5-6451e78e97e2@disruptive-innovations.com>
Le 11/12/2017 à 17:18, Siegman, Tzviya - Hoboken a écrit :

> The _editorial_ choice that was to start with the separate Working Group Note produced by the (closed) Annotation WG[3]. The purpose of the Note was to "extract" the locator model [1] from which a number of annotations features are not relevant to the Publishing Working Group, and extend that document by adding those (few) extra locators and concepts that are considered to be relevant for Web Publications. Specifically, looking at the latest (Dec 6) version of the current draft[4], only subsections 4.10, 4.11, and 4.12, plus the whole of section 6 are normative content put forward by this WG. Everything else is non normative, and are essentially copy of what is in [1], without changing the semantics. This means that your reference to issues surrounding Fragment Selectors, Range Selectors, or CSS selectors, though they may be justified, are not issues that we can act on, because they refer to specifications that are not our own.
> 
> Looking at your reactions it turns out that the editorial choice may have been a mistake, and it contributed to misunderstandings. There is now a separate commit (not yet a Pull Request) on the repository[5] that cuts out of the document everything that is _not_ normative. Although the introduction should be adapted, it may well be that [5] is a better choice for a FPWD than [4], simply to avoid misunderstandings as yours. This is a decision the WG has to make now.

Woah. Thanks for the explanations, Tzivya. You are right, I was far,
very far, from understanding where that spec comes from...

Let me be sure I understand: a large part of the Locators spec is an 'in
extenso' copy of the Web Annotation Data Model REC and some others come
from a Note? If that's correct, I just don't understand why things are
copied instead of being referenced; we __never__ do that.

On the technical side, let me repeat what I said earlier: "selectors" in
the Web Annotation Data Model are very strange, if not very weak, to say
the least. The whole Locators document clearly gives the impression that
this is a generic mechanism ALSO made for "external" use.

> If in your opinion, the choice of starting with [1] was not the right one then the WG will want to revisit this decision, but possibly after FPWD

I think the Web Annotation Data Model is, in the context of an EPUB
package, raising so many hyper-complex questions the choice is
questionable. Given the complexity of the issues, the whole Locators
spec is also questionable. I have strictly no idea what is a Range
inside an EPUB package: on which ToC is it based? What is the default
ordered manifest used for package traversal? How can we change it?
Should we target the resources directly or through their shortnames in
the XML manifests?

All in all, the FPWD only scratches the surface of what is needed to
make an interoperable system workable for Reading Systems, with (much)
higher constraints than in the Desktop Browser's world.

If you keep on that path, the WG will *necessarily*, at some point in
the future, need a fragment identifier dedicated to EPUB or WP in URLs,
through a new RFC. My take is that we should start from there, through
an analysis of requirements, prioritization of these requirements and
focus on the two or three most important things instead of directly
using a Mother Of All Bombs. In that light, JSON is certainly too verbose.

And if the whole thing is only made to be "used by implementers
internally" as you said, I am not even sure we need a REC.. A Submission
by a few Members could be enough.

Side note: "Selectors" is a normative word in the scope of Web
Standards: https://www.w3.org/TR/css3-selectors/

</Daniel>
Received on Monday, 11 December 2017 17:44:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:52:18 UTC