Re: [PWP] Manifest definition in PWPWP

> hence the very practical question on what the GET should return for a PWP URI.

Doesn't it largely depend on the "state" of the PWP, which can be packed or unpacked?

What is "a PWP URI"? What does it mean for a packed PWP? and an unpacked PWP? I assume the URL is not the same in both cases.

Romain.



> On 06 Jan 2016, at 13:46, Ivan Herman <ivan@w3.org> wrote:
> 
>> 
>> On 6 Jan 2016, at 12:06, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>> 
>>> what information do we have to provide to the world about a PWP
>>> 
>> That’s one way of looking at a “manifest”, Ivan.  The other is, “what information does a PWP RS need in order to process it as the author intended”.   These may be the same, but I suspect they are not.
> 
> I am not really sure I get the difference in all its depth. I provide an information so that tools out there can do something with a PWP.
> 
>> 
>> 
>>> After all, we also say somewhere that what is returned, as a result of an HTTP GET for the PWP instance is manifest
>>> 
>> This isn’t something that we all agree on, so please don’t treat it as such.
>> 
> 
> This is what we say in
> 
> https://w3c.github.io/dpub-pwp/#what-should-be-the-response-of-an-http-s-get-request
> 
> 
>> Consider that if you implemented what you describe above, then what URI would be used to fetch the entire PWP?  IMO, a GET on the PWP URI MUST return the entire PWP - that’s what is expected as per the REST model. To get a “manifest”, you would need a URI for that specific resource (eg. foo.pwp/manifest).
>> 
> 
> I do not know what it means to return the entire set of resources.
> 
> We get into a slippery slope here, though, that we should try to avoid. The distinction becomes close to the HTTPRange-14 issue[1] about what the URI of a PWP really represents. We should avoid getting into that discussion, hence the very practical question on what the GET should return for a PWP URI. I believe what the draft says is fine in this sense.
> 
> Ivan
> 
> 
> [1] https://en.wikipedia.org/wiki/HTTPRange-14
> 
> 
>> Leonard
>> 
>> 
>> 
>> 
>> On 1/6/16, 5:03 AM, "Ivan Herman" <ivan@w3.org> wrote:
>> 
>>> 
>>>> On 5 Jan 2016, at 21:41, Siegman, Tzviya - Hoboken <tsiegman@wiley.com> wrote:
>>>> 
>>>> We are going to have start speaking in aliases too. All our words are overburdened.
>>>> 
>>>> I have been using the term "manifest" as short-hand to mean that we have to have a method of indicating to the tool that makes the PWP (as opposed to a bunch of unrelated resources).
>>> 
>>> Yep. Formulation of the PWP (draft!) put aside, I think the generic issue is "what information do we have to provide to the world about a PWP"? Ie, looking at the manifest in a general sense. Yes, the word is overloaded, and I am not sure what else to use.
>>> 
>>> I think that, for a while, we should try to keep in that generic level and not being bogged down on whether we would use a JSON file or something else. However, once we have a better idea we should also begin to think about how that generic manifest could manifest itself on the Web. After all, we also say somewhere that what is returned, as a result of an HTTP GET for the PWP instance is manifest (or a link to a manifest), ie, a physical representation should be defined at some point. But we should probably postpone that for now.
>>> 
>>> Ivan
>>> 
>>> 
>>>> 
>>>> There are many models for manifests that exist in the real world. We have to assess how best to approach this:
>>>> 
>>>> 1. The zip/epub manifest model lists every element in the container.
>>>> 2. The epub TOC (and spine) is a directory of what EPUB calls "content documents". These are the major resources, from which other resources (e.g. images, fonts, css, scripts) may be referenced.
>>>> 3. The web app manifest is metadata for how to start an application. It contains basic information, such as language, and, perhaps most notable for our purposes, defines scope [1].
>>>> I'm sure there are other models as well. I have not even considered concepts such as sequence of components.
>>>> 
>>>> How do we address components of a PWP if we do not know what is in the PWP?
>>>> 
>>>> [1] https://w3c.github.io/manifest/#scope-member
>>>> 
>>>> Tzviya Siegman
>>>> Digital Book Standards & Capabilities Lead
>>>> Wiley
>>>> 201-748-6884
>>>> tsiegman@wiley.com
>>>> 
>>>> -----Original Message-----
>>>> From: Cramer, Dave [mailto:Dave.Cramer@hbgusa.com]
>>>> Sent: Tuesday, January 05, 2016 1:41 PM
>>>> To: W3C Digital Publishing IG
>>>> Subject: [PWP] Manifest definition in PWPWP
>>>> 
>>>> The PWPWP [1] says, a manifest "is a web resource that includes information pertaining to the overall publication structure, such as the default logical reading order(s) of the set of resources that comprise the publication (the "spine"), as well as predictable user-facing meta-structures, such as one or several tables of contents, glossaries, etc."
>>>> 
>>>> I'm having a bit of trouble parsing that sentence. Does this mean that the "predictable user-facing meta-structures" are part of the manifest? Or does it just mean that a manifest should identify such things?
>>>> 
>>>> More broadly, I think we need to be much clearer about what functions a manifest might serve, and if some of those functions are better served in a different way. The horribly named "spine" is a good example. EPUB uses a manifest element [2] to provide an "exhaustive" (it's in the spec!) list of the publication resources, assigns an ID to them, and then uses a spine element to determine the sequence of resources. But some of us think that existing HTML structures (such as nav and/or link relations) may better serve that need.
>>>> 
>>>> It's also confusing because we've been talking about lots of different kinds of manifests. The EPUB manifest is quite different from the web application manifest [3], which is different from the manifests I've used with service workers to control which publication resources are cached.
>>>> 
>>>> So before we decide that manifests will solve all our problems, let's be clear on what problems, and why a manifest is the best solution.
>>>> 
>>>> Dave
>>>> 
>>>> [1] http://w3c.github.io/dpub-pwp/#manifest
>>>> [2] http://www.idpf.org/epub/301/spec/epub-publications.html#sec-manifest-elem
>>>> [3] https://w3c.github.io/manifest/
>>>> 
>>>> This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.
>>>> 
>>>> 
>>> 
>>> 
>>> ----
>>> Ivan Herman, W3C
>>> Digital Publishing Lead
>>> Home: http://www.w3.org/People/Ivan/
>>> mobile: +31-641044153
>>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>> 
>>> 
>>> 
>>> 
> 
> 
> ----
> Ivan Herman, W3C
> Digital Publishing Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704