- From: Ivan Herman <ivan@w3.org>
- Date: Wed, 23 Nov 2016 11:48:11 +0100
- To: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>
- Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org>, Ric Wright <rkwright@geofx.com>, Laurent Le Meur <laurent.lemeur@edrlab.org>
- Message-Id: <E368DFE7-B268-4012-A91C-9A52A652893A@w3.org>
> On 23 Nov 2016, at 11:13, Hadrien Gardeur <hadrien.gardeur@feedbooks.com> wrote: > > I am not sure why you say that. I think it is perfectly fine to say that once I create a WP, the _relative_ paths of the content remain unchanged. Whether I (temporarily) package it and unpackage it later, the file hierarchy should remain unchanged, only the root should change. If I change the file hierarchy then it is _another_ WP as far as I am concerned. > > That's where IMO things get completely unrealistic. A WP can potentially link to resources all over the Web, I don't even believe that there's any hierarchy in the first place. > > As long as we know the canonical URI for each resource, we should simply let clients package resources however they want and rewrite links at the same time. It's the only way we can get something that reading systems won't have a hard time rendering, and since we know the canonical URI, it still supports the core use cases (locator & updates). > Ok, I see where you come from. This goes back to how exactly we would draw the line for what a WP is (and maybe we get to the profiling discussion!). I could envisage two approaches. A WP is indeed a collection of resources, but: 1. it is all under the "control" of the publisher; essentially looks like an unpacked EPUB put on the Web, all the resources are "local". There are of course references to external resources, but they are external 2. there is no limitation, it is an arbitrary collection of Web resources regardless of where they are, which domain, under whose control, etc. You see to refer to a WP version 2 above and, in that case, you are of course right. But, as we just see, things become more complicated. My mental model is currently dominated by version #1, which is of course way more restrictive but also simplifies things. At some point we will have to decide which way we go; I am not convinced that the general approach of #2 is a direction we really want to take. But that is up for discussion. Ivan > > If, as I maintain, the file hierarchy should not change for a specific WP, then I do not think this is all necessary. If the manifest is allowed to change, then the only change that might be necessary for some of the use cases is to have, maybe, a change in the metadata, something like: > > { > "metadata": { > "identifier": "https://www.publisher-P/new/Orlando/ <https://www.publisher-p/new/Orlando/>", > "breadcrumb": [ "h <https://www.example.com/my-books/Orlando/c001.html>ttps://www.library-L/stacks/fiction/Orlando/ <>","h <https://www.example.com/my-books/Orlando/c001.html>ttps://www.library-L/user-U-bookshelf/Orlando/ <>"], > "title" : "Orlando" > } > … > } > > which allows the reconstruction of all kinds of URL-s. > > A Web Publication could appear in packaged form in an unlimited number of URIs, I don't see how this can replace "hrefsrc" at all. > > Hadrien ---- 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
Received on Wednesday, 23 November 2016 10:48:28 UTC