Re: [PWP] Manifest definition in PWPWP

Dave - I reordered your email, in order to address things in a different order, I hope you won’t mind…


On 1/5/16, 1:40 PM, "Cramer, Dave" <Dave.Cramer@hbgusa.com> wrote:



>More broadly, I think we need to be much clearer about what functions a manifest might serve, 

I agree 100%!


>and if some of those functions are better served in a different way. 

Here is where we need to step back from specific implementations (such as the one used by EPUB or even web applications) and instead focus strictly on the requirements (either technical or user) and not how it is represented.


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

I would put forth that even “existing HTML structures such as nav or link” is still a manifest.  It’s about what it needed/required and not about how you represent it.


>It's also confusing because we've been talking about lots of different kinds of manifests. 

Have we?  We’ve been talking about different representations of the data found in a manifest - but I think we’ve been focused on what types of things would go in there.


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

We should fix that.  It makes a number of assumptions (including that the manifest exists and is a web resource)..


Leonard

Received on Tuesday, 5 January 2016 19:54:33 UTC