>
> 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).
> 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