This wiki has been archived and is now read-only.

Functional Requirements

From Digital Publishing Interest Group
Jump to: navigation, search

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.