Functional Requirements

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.