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

RE: Comments on "Locators for Web Publications"

From: Siegman, Tzviya - Hoboken <tsiegman@wiley.com>
Date: Mon, 11 Dec 2017 16:18:42 +0000
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, "public-publ-wg@w3.org" <public-publ-wg@w3.org>
Message-ID: <CY1PR0201MB16111DE24C8CC16A9B986C74D5370@CY1PR0201MB1611.namprd02.prod.outlook.com>
Hi Daniel,

Thank you for the feedback. It did trigger us to take a closer look at some of the language in the document. But, I think there are some misunderstandings about the intentions of the WG with this document. If that is correct, the responsibility is obviously the WG's, it is our job to be clear.

The work on the locator comes from the premise that epubcfi is not really usable for the purpose of WP (due to its strong reliance on the XML syntax among other things). The EPUB3 WG conducted some research when the IDPF was working EPUB 3.1 on whether epubcfi is used. The outcome was that it is not used in terms of EPUB3 content production, but it is used by implementer internally. So, we have to consider finding a replacement, at least for systems and processing purposes.

Because one of the main implementation use cases for epubcfi is annotations, it was a natural choice for the WG to look at what the W3C Annotation WG has produced, in the form of the Web Annotation Model[1] (a model that is implemented by several different implementations[2]). That document contains a definition for ‘Specific Resources’, which the WG decided to use as the starting point for WP Locators. Because the Publishing Working Group is not in position (and it is not chartered for) to change the locator model [1], we looked into extending the model for publications. 

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.

I hope this helps dissipate at least part of the disconnect. 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. We of course also welcome any issues raised on the entries added by this Working Group (more clearly listed in [5]). But please understand that this WG cannot act on any detailed issues on entries in the Annotation Model[1], I think the charter made it fairly clear that this WG must build upon what is already there and not to 'fork' existing standards.


[1] http://www.w3.org/TR/annotation-model/

[2] https://w3c.github.io/test-results/annotation-model/all.html

[3] http://www.w3.org/TR/selectors-states/

[4] https://w3c.github.io/publ-loc/

[5] https://rawgit.com/w3c/publ-loc/new-things-only/index.html

Tzviya Siegman
Information Standards Lead

-----Original Message-----
From: Daniel Glazman [mailto:daniel.glazman@disruptive-innovations.com] 
Sent: Friday, December 8, 2017 9:14 AM
To: public-publ-wg@w3.org
Subject: Comments on "Locators for Web Publications"

Dear Publishing WG,

I have discovered the first public Editor's Draft for "Locators for Web Publications" and spent some cycles studying it. I tried understanding how it fits with the Web, how it can be useful and used for Web Publications, and more. I have carefully reviewed everything so let's put it bluntly but precisely: I am appalled.

The spec is so full of holes, inconsistencies with the Open Web Platform, incredible redundancies with RFCs (the Fragment Selector is just a JSON explosion of a URL having a fragment id, with a useless spec reference redundant with the content type of the resource), underspecifications for instance related to XPath or CSS Selectors resulting in multiple nodes in the document tree or leading to invisible nodes like xml comments or processing instructions, lack of mutating mechanisms for instance for Text Selectors in response to changes in the referenced instances, lack of error handling (e.g. if a Locator relies only on XPath but the UA does not implement XPath), and more that I can forecast a failure. Even if this spec reaches REC status, I bet a box of cookies the REC will rely on niche implementations but will probably never hit mainstream user agents.

I have at least 50 critical if not totally blocking comments to make on the spec... That is _not_ normal. I wrote a few of them here on post-its and picked a random one (I really did):

  a Range Selector implies an ordered manifest. For a DOM Selection,
  that ordered manifest is the document tree. EPUB has several ordered
  manifests... Which one is the one to use? Oh, ok, then we miss a
  reference to that ordered manifest because otherwise, it will be UA-
  dependent! Yes, but then you need to describe the format of the
  manifest for the same reason, right? And then it's totally overkill
  and unusable. Ahem.

Furthermore, that draft is fundamentally a dereferencing mechanism and I have the gut feeling dereferencing is NOT what we should be doing. I think we need URIs. I also think selections starting in one document instance and ending in another one are a very, very, VERY complex topic if we want to make it in accordance with the habits of the OWP; this spec does not seem to me a good OWP-compliant approach to solve this problem. FWIW, I do NOT buy a ServiceWorker-based approach; from what I recently heard, a large part of the industry does not buy it either.

All in all, this Draft feels and smells like the standardization of a proprietary implementation in a given UA relying far too much on the pure magic in that given UA. From a Web Architecture's point of view, it feels like an error. I am urging the Publishing WG to reconsider the future of this document and focus instead, in a Level 1, on a URL- based mechanism allowing two features: target a single instance inside a package, and target a single element inside such an instance inside a package. This is the minimum minimorum the industry needs.

Thank you.


Received on Monday, 11 December 2017 16:19:15 UTC

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