RE: [PWP] Manifest definition in PWPWP

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

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.

Received on Tuesday, 5 January 2016 20:41:57 UTC