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

Re: Identifying a book on the Web today

From: Romain <rdeltour@gmail.com>
Date: Thu, 3 Aug 2017 00:08:25 +0200
Cc: Benjamin Young <byoung@bigbluehat.com>, David Wood <david.wood@ephox.com>, MURATA Makoto <eb2m-mrt@asahi-net.or.jp>, "public-publ-wg@w3.org" <public-publ-wg@w3.org>
Message-Id: <55BD32F4-E5C8-45FB-B638-B4CACA6B9FD8@gmail.com>
To: Baldur Bjarnason <baldur@rebus.foundation>

> On 2 Aug 2017, at 22:04, Baldur Bjarnason <baldur@rebus.foundation <mailto:baldur@rebus.foundation>> wrote:
> 
> To summarise:
> 
> * A URL as both a locator and identifier is a given—if it’s on the web, that’s how it’s going to work—but we can’t change how a URL functions or behaves.
> * Using a URL that doesn’t identify the publication (e.g. an external HTML page) to help people indirectly locate a publication should be a feature that we provide by specifying some form of discovery mechanism (some form of link—HTTP header or link tag—with a format-specific rel value is the usual way of doing this).
> * A secondary globally unique identifier that is separate from the identifying and locating URL is useful for a variety of reasons but requiring one has as many downsides as it has upsides—the biggest downside being that most developers won’t provide one even if that makes the web publication invalid. I’m sure we will debate this but given that the functional advantages are largely in the area of distribution and portability I don’t see why this should be a requirement for non-portable web publications.
> * We absolutely should not venture into the territory of extending existing protocols, minting new identifying schemes, or specifying a locator mechanism that mandates the implementation and maintenance of what are likely to be non-trivial server systems.

+1, fully agree.

Romain.
Received on Wednesday, 2 August 2017 22:08:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:49:06 UTC