Re: [PWP] Manifest definition in PWPWP

> 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