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

Comments on "Locators for Web Publications"

From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Date: Fri, 8 Dec 2017 15:13:30 +0100
To: public-publ-wg@w3.org
Message-ID: <ef265682-5220-5275-8d4d-43fd705e0dd6@disruptive-innovations.com>
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 Friday, 8 December 2017 14:13:59 UTC

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