Re: Comments on "Locators for Web Publications"

Hi,

I have been uncomfortable wit this specification as well, but I was not sure how to articulate it until now.

However, I think I see it more clearly after having written [1] (if you haven't read that mail yet, please do that first, this mail will make a lot more sense afterwards).

Most of the normative statements in publ-loc read something like “FOO SHOULD have exactly 1 BAR”, “BAZ MUST be QUX"...

This means the majority of the spec is, as I was warning against in [1], is defining the conformance of a document/resource format, and hardly says anything about what software that produces or processes it is expected to do. I know that there are a few statements about what UAs must do, but they generally are terribly vague (“UAs should be aware of…”, “UAs should assume…”).

All in all, I think that the problem is that this spec describes Locators without the context of APIs (in the broad meaning) that consumes or produces them. This makes it impossible to describe what a UA should do when it encounters them.

Are these meant to be used from existing JavaScript APIs that take URLs with fragment identifiers? Are they meant to be used in existing APIs that consume DOM Ranges or Selections? Probably not, but if so, we need to describe what the UA is expected to do *in terms of these APIs*. If not, we need to describe what APIs consume them, and how these behave.

Until we have that, I'm afraid the spec isn't something UAs can meaningfully implement. It also seems to me that trying to answer many of the points raised by Daniel would not conductive without doing so in the context of a specific API.

I am sure that these were introduced not just for the heck of it, but to solve a specific (or several specific problems). I suggest we start with the proposing the APIs that are supposed to consume these, and from there we can work out how much or how little complexity we want to deal with in the parameters to these APIs.

—Florian

[1] https://lists.w3.org/Archives/Public/public-publ-wg/2017Dec/0011.html

PS: there are also a number of notes with RFC2119 language in them, which is wrong. RFC2119 language is for normative statements. Notes are for non-normative statements

> On Dec 8, 2017, at 23:13, Daniel Glazman <daniel.glazman@disruptive-innovations.com> wrote:
> 
> 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.
> 
> </Daniel>
>

Received on Monday, 11 December 2017 13:18:13 UTC