Re: For the discussion on the PWP

>
> You mean links in the resources within a WP? My answer would be no. The
> resources, when put into a package, should be unchanged (with a possible
> exception for the manifest, maybe).
>

But if they're unchanged, then we hit the issue that I've described before,
where it becomes tricky for a reading system to properly display such a
packaged publication.
You either have to dynamically create your own Service Worker, act as a
proxy for a a webview (same idea than a Service Worker) or rewrite those
links dynamically in the RS.

Now, to go back to the example that Dave has provided, let's get into a
little more details:

   - Publisher P publishes Orlando and uses
   https://www.publisher-P/new/Orlando/ as the unique identifier for it
   - The manifest for Orlando is available at
   https://www.publisher-P/new/Orlando/manifest.json

User A gets access directly to the Web Publication Manifest (I'm using the
syntax that I've used until now to illustrate this entirely):

{
  "metadata": {
    "identifier": "https://www.publisher-P/new/Orlando/",
    "title": "Orlando"
  },

  "links": [
    {"rel": "self", "href": "
https://www.publisher-P/new/Orlando/manifest.json", "type":
"application/webpub+json"}
  ],

  "spine": [
    {"href": "c001.html", "type": "text/html"},
    {"href": "c002.html", "type": "text/html"},
    {"href": "c003.html", "type": "text/html"},
    {"href": "c004.html", "type": "text/html"}
  ]
}

To reference "c001.html" in this specific publication, a locator could
either use:

   - the identifier (https://www.publisher-P/new/Orlando/) +
   https://www.publisher-P/new/Orlando/c001.html
   - the canonical link to the manifest (
   https://www.publisher-P/new/Orlando/manifest.json) +
   https://www.publisher-P/new/Orlando/c001.html

All three references should remain stable, no matter how you access the
publication.

Now User B gets access to a packaged version of that book. There are many
different ways this publication could have been packaged, for instance:

   - by the publisher, at the same time that the Web Publication itself was
   published on the Web
   - by a third party client, that simply accessed the manifest and its
   resources to create a new package

While I've read quite a few times in this group mentions that packaging the
publication should not impact the path to the resources, I think that this
is completely unrealistic. But frankly, it doesn't really matter as long as
the canonical location of each resource is preserved.

For instance, let's say that User B version of the same packaged
publication looks like this:

{
  "metadata": {
    "identifier": "https://www.publisher-P/new/Orlando/",
    "title": "Orlando"
  },

  "links": [
    {"rel": "self", "href": "
https://www.publisher-P/new/Orlando/manifest.json", "type":
"application/webpub+json"}
  ],

  "spine": [
    {"href": "chapter1.html", "hrefsrc": "
https://www.publisher-P/new/Orlando/c001.html", "type": "text/html"},
    {"href": "chapter2.html", "hrefsrc": "
https://www.publisher-P/new/Orlando/c002.html", "type": "text/html"},
    {"href": "chapter3.html", "hrefsrc": "
https://www.publisher-P/new/Orlando/c003.html", "type": "text/html"},
    {"href": "chapter4.html", "hrefsrc": "
https://www.publisher-P/new/Orlando/c004.html", "type": "text/html"}
  ]
}

It doesn't really matter if one packaged version renamed "c001.html" to
"chapter1.html" or moved it to a different folder in the package, I can
still find back what the reference is by using "hrefsrc".


Hadrien – I have been looking towards the Selector model of the Web
> Annotation specification as ways that we might be able to specify text
> locations in a reliable fashion (and without re-inventing the wheel).  It
> provides a number of well-defined (and implemented/tested) models for how
> to refer to either specific semantic text pieces, arbitrary text or ranges
> of both/either.  This should hopefully remove the need for fragments – at
> least in the context of a larger environment.
>

Leonard, I don't really think it does, but the selector model is a good
starting point.
The main issue that I have with it, is that there are many different
options for such selectors. Some are quite stable but lack precision,
others are quite the opposite.
We might not need (or want) to define a brand new fragment identifier, but
we'll need to take a close look at the selectors that are available and
have a clear decision about the ones that we'll actually use.

Hadrien