W3C home > Mailing lists > Public > public-digipub-ig@w3.org > January 2016

[PWP] Manifest definition in PWPWP

From: Cramer, Dave <Dave.Cramer@hbgusa.com>
Date: Tue, 5 Jan 2016 18:40:55 +0000
To: W3C Digital Publishing IG <public-digipub-ig@w3.org>
Message-ID: <C994F950-66B6-48DD-B2B9-47D2ABF45279@hbgusa.com>
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 18:41:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:21 UTC