From Digital Publishing Interest Group
Functional Requirements for Packaging Spec
- a package must exist (as opposed to a publication being fully online).
- portability: not the same as caching (share an entity a thing, not just cache it on browser)
- itemized list of components (manifest), including file type, size, compression etc.
- multiple methods of navigation/content mapping
- robust metadata for package and components
- no file size limitations
- hooks for encryption, rights management, signatures, licensing
- random access to content (including disjoint content)
- access to whole package and package components online and offline
- streamable (at least of components) (start rendering the beginning of chapter, article before download last octet)
- update/refresh of new components (ONLY), not whole package
- multiple users of package (in authoring, in publication, annotation, etc - get away from single user use cases)
- allow for nested packages (hierarchy)
- links within the package should remain stable whether package is online or offline (relative URIs)
Additional comments from Dave Cramer
- Perhaps the most fundamental principle is the need to determine what's part of the "thing" we're packaging, and what's not. I'll call the thing we're packing a "publication". If we try to avoid packaging altogether, is what we end up with just the web as it exists today?
- We need to identify a publication with a URI
- We need to point to a publication with a URL
- taking a folder of web content and turning it into a package should be easy. Contrast how hard that is to do with EPUB.