RE: For the discussion on the PWP

Hi Hadrien,

Ivan is travelling today, so I will attempt to answer this. I also require a bit of clarification, please.


1.       We may need to reconsider the use of the term “Canonical Locator”, given its implications in the world of HTML/HTTP. We all but removed the term from our Use Cases & Requirements, and I am going to log an issue to clarify the usage of the term in this document. We may come back to using rel=”canonical” for (P)WP, but we may not. I believe the usage intended here has more to do with identification, as explained in Addressing and Identification [1]. That being said, this document needs a lot of work, and we need to work out many details.



2.       One of the things we would very much like to accomplish is the ability to address components of the package using the same URI, regardless of package state (packaged, unpackaged, whatever terms we create in the future). Essentially, we need to create a fragment identifier. If I’m understanding your  proposal correctly, you are suggesting creating a link attribute “hrefsrc”. Is that correct? Will that work on an <a> element? I think your proposal will do well for the manifest, as it’s discussed in this document, but that is a work-in-progress as well.  Further, we need something that works for those who are not already inside the “package”, such as citations. This can be viewed as a replacement/improvement of CFI.  We looked at Packaging on the Web [2], which has not been pursued in the W3C, but the work that they did is worth reviewing.  Looking at HTTP with all its flexibility is an excellent suggestion.



3.       I would love to hear more from you, Ric, Laurent, Daniel about what requirements a reading system has and how we can make this work.

[1] https://w3c.github.io/dpub-pwp/#identification

[2] https://www.w3.org/TR/web-packaging/


Tzviya Siegman
Information Standards Lead
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Hadrien Gardeur [mailto:hadrien.gardeur@feedbooks.com]
Sent: Wednesday, November 16, 2016 5:37 AM
To: Ivan Herman
Cc: W3C Digital Publishing IG; Ric Wright; Laurent Le Meur
Subject: 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<mailto:ivan@w3.org>>:
Hi Hadrien,

On 15 Nov 2016, at 17:34, Hadrien Gardeur <hadrien.gardeur@feedbooks.com<mailto: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<mailto: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<tel:%2B31-641044153>
ORCID ID: http://orcid.org/0000-0003-0782-2704







--
Hadrien Gardeur
Co-founder, Feedbooks
http://www.feedbooks.com<http://www.feedbooks.com/>
T: +33.6.63.28.59.69<tel:%2B33.6.63.28.59.69>
E: hadrien.gardeur@feedbooks.com<mailto: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<tel:%2B31-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<mailto:hadrien.gardeur@feedbooks.com>
54, rue de Paradis
75010 Paris, France