Re: For the discussion on the PWP

Hello Ivan,

I'm adding Ric & Laurent since this also concerns reading systems directly.

It's not entirely clear to me what canonical locators are used for, a few
things comes to mind:

   - on the Web, a link@rel="canonical" is used when multiple URIs return
   the same resource, the URI referenced in that link is then considered to be
   the canonical location for that resource
   - it seems that there's also a use case for packaged publications, where
   you might want to update individual resources by keeping the original URI
   in the manifest
   - and finally you seem to describe a use case based around redirections,
   if I'm not misunderstanding your previous email

When the world "canonical locator" is used, I tend to think strictly about
the first use case, for which I'm not sure that we need to do much.
Shouldn't we simply let HTTP do its job and eventually provide a Link
header with rel="canonical"?

For the second use case, this involves packaged publications and reading
systems and becomes potentially complex:

   - first of all, using "hrefsrc" or a similar key should work fairly well
   for that purpose
   - in order to update individual resources in the package, we could then
   rely on the URI in "hrefsrc", but I don't know when/how this content should
   be updated and what happens if the original version is deleted/modified
   without proper HTTP status codes being returned
   - overall, I think it's much easier to update the package as a whole, by
   keeping a link to the original manifest in the packaged version
   - but intercepting "https://example.org/books/1/img/mona_lisa.jpg" and
   serving "/img/mona_lisa.jpg" from the package instead isn't necessarily
   easy for a reading system. Since most of them are based on a webview, you
   would either have to:
   - generate dynamically a Service Worker for each publication based on
      the info that you extract from the manifest, and then inject
that SW in the
      publication's resources. This means that you need to serve all your local
      resources using HTTPS and a webview that supports SW, which
might be tricky
      on some platforms (iOS for instance). I also need to double check if SW
      work on localhost and on any port.
      - the other option would be to rewrite all URIs referenced in the
      manifest and used in the publication's resources, which is something that
      IMO we'd like to avoid with Readium for instance
   - same problem the other way around if we'd like to say something like
   "prioritize the resources available on the Web vs those in the package"

While I can understand the potential benefits if we can figure this out,
this might be a very challenging problem to solve for people building
reading systems.

Am I missing anything or misunderstanding the use cases for canonical
locators?

Thanks,
Hadrien

2016-11-15 18:00 GMT+01:00 Ivan Herman <ivan@w3.org>:

> Hi Hadrien,
>
> On 15 Nov 2016, at 17:34, Hadrien Gardeur <hadrien.gardeur@feedbooks.com>
> wrote:
>
> Hello Ivan,
>
> Just a quick note: this document uses "pwp_manifest" as the rel value to
> discover a manifest, but I believe that we should actually use the same rel
> value ("manifest") as the Web App Manifest, just with a different media
> type.
> We don't really need a dedicated relationship for PWP since the
> relationship isn't affected by the format of the manifest.
>
>
> Probably. To be honest, the document did not really go into these details,
> nor I am sure it should (this may just be an input to a possible WG, and
> the details will have to be clarified at that point).
>
> But I am fine changing it right now. Can you make a pull request?
>
>
> For the canonical locator, I'm still not sure that I understand fully what
> this will be used for (there are potentially a lot of use cases), but could
> this behave slightly like "hreflang", by providing a hint on a link?
>
> For example:
> {"href": "img/mona_lisa.jpg", "hrefsrc": "https://example.org/books/1/
> img/mona_lisa.jpg", "type": "image/jpeg"}
>
>
> Yes, except that it is probably two-directional. (But all this is
> still/again a bit in the air.) Two directional in the sense that if a
> renderer receives  https://example.org/books/1/img/mona_lisa.jpg then it
> should get to "img/mona_list.jpg". A functionality that may be covered by a
> SW in the background, actually; that text was written before we _really_
> dived into the SW world. Let alone the fact that SW may not be the _only_
> implementation vehicle.
>
> Cheers
>
> Ivan
>
>
>
> Hadrien
>
> 2016-11-15 17:16 GMT+01:00 Ivan Herman <ivan@w3.org>:
>
>> I made a first re-shuffling of the PWP draft
>>
>> http://w3c.github.io/dpub-pwp/
>>
>> mostly along the lines of
>>
>> https://github.com/w3c/dpub-pwp/blob/gh-pages/TODO.md
>>
>> 'Mostly', because I made copy-pastes from the previous version and some
>> of the items in the TODO are in a single section now. But, I believe, the
>> content is there.
>>
>> I will not touch this document until next week and, afaik, a more
>> detailed discussion will happen on the call on Monday. Until then, have a
>> look at it and, of course, feel free to contribute to the text!
>>
>> Ivan
>>
>> ----
>> Ivan Herman, W3C
>> Digital Publishing Technical Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>
>>
>>
>>
>>
>
>
> --
> Hadrien Gardeur
> Co-founder, Feedbooks
> http://www.feedbooks.com
> T: +33.6.63.28.59.69
> E: hadrien.gardeur@feedbooks.com
> 54, rue de Paradis
> 75010 Paris, France
>
>
>
> ----
> Ivan Herman, W3C
> Digital Publishing Technical Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>
>
>
>


-- 
Hadrien Gardeur
Co-founder, Feedbooks
http://www.feedbooks.com
T: +33.6.63.28.59.69
E: hadrien.gardeur@feedbooks.com
54, rue de Paradis
75010 Paris, France