ZedDist Container Component
From zedwiki
This is the working area for filling out details on the ZedDist Container Component.
Contents |
Background
Up to this point in time, DAISY filesets have been delivered in whatever packaging made the most sense to a particular distributor, and with minimal layout requirements. Having a common container definition is felt to offer significant advantages for both consumers and producers, offering simpler management of DAISY documents, better interoperability between reading devices, and a consistent way to offer player fallback when providing a single fileset for use on multiple devices.
The container definition also provides a mechanism for expressing metadata about the fileset structure, replacing the "distInfo" file in DAISY 2005. (more detail on this...)
To continue building on the work of the ePub standard, the container definition is an extension of the Container Format (OCF) specification. It builds on the Abstract Container definition to provide the mechanism for container-level fallback, and defines Physical Containers that could provide backward compatibility with ePub players and work with scenarios such as delivery.
Note that we also follow the OCF specification in defining this as a container for a single publication, albeit with potentially multiple renditions.
The Abstract Container
Following the OCF, we divide the component definition into that of an Abstract Container and a Physical Container. The Abstract Container is the description of the filesystem layout of the contents of the container. It defines the names of the required files and their relationship to one another.
The DAISY abstract container defines some specific customizations of the OCF abstract container:
- Renditions of a publication other than ePub
- The OCF allows multiple renditions within a container, with their rootfiles identified in the META-INF/container.xml file, but requires that at least one rendition be an ePub. The DAISY container allows an ePub rendition, but instead requires that at least one rendition be a DAISY publication.
- Common media storage
- To make efficient use of the storage, the audio and video media files for a publication may be kept in one location within the container, with each rendition of the publication referring to them. This common storage area would not be required, but recommended.
- Container level fallback
- The DAISY container will have a mechanism for describing a precedence of renditions of a publication, so that a single distribution file can be used by playing systems with different capabilities. See below for a fuller description of the fallback mechanism.
See the example container for what this layout would look like.
Metadata Files
The OCF defines a single required metadata file, container.xml, and a set of more specific metadata files that are all optional. We will need to decide which of these, if any, we might specify for DAISY.
| Name | Description | Include in DAISY container? |
|---|---|---|
| container.xml | Points to the rootfiles for the different renditions of a publication | Yes |
| manifest.xml | An ODF 1.0 manifest file | No |
| metadata.xml | No structure defined beyond valid XML with namespace-qualified elements. It is intended for container-level metadata, but with no ePub use yet, and intended for extension. This could be where we specify the precedence of renditions for container-level fallback. Could also be used to express distInfo-like information on publications spanning multiple CDs | Yes? |
| signatures.xml | Holds digital signatures of files, in XML-Signature notation | No? |
| encryption.xml | Holds encryption information of files, in XML Encryption notation | Maybe? Instead of pdtb? |
| rights.xml | Intended for DRM information, with no structure defined beyond valid XML with namespace-qualified elements. | Maybe? |
(Note: Reuben had suggested considering a 'compression.xml' file for per-file compression information. Are there situations where we might want per-file compression? Audio and video would already be compressed, and OCF only allows the default deflate compression for the ZIP container.)
Rendition Names
The OCF specification defines "OEBPS" as the name to be used for the directory holding the ePub rendition of a publication. We should recommend the use of the following names for DAISY renditions:
- Audio profile: Z3986-2010-AU?
- Classic profile: Z3986-2010-?
- Pro profile: Z3986-2010-PRO?
- Text-only profile: Z3986-2010-? or simply OEBPS (if we end up being 100% compatible with EPUB 3.0)
Media Types
To identify the media type of a container file, we will need to have a unique extension and mimetype. When the container holds an ePub rendition, we may use the ".epub" extension and "application/epub+zip" mimetype to allow the container to be recognized by ePub reading systems.
For containers with DAISY-only renditions:
- File extension: .dpub? .dsy? .dzy? (to imply ZIP container)
- Mimetype for ZIP container: application/daisy+zip?
- Mimetype for TAR container: application/daisy+tar?
The Physical Container
The intent is to allow three types of containers.
ZIP Container
See ZIP description (copy here?).
This container is allowed by the OCF.
This container would be used when shipping a single rendition, and when targeting standard EPUB readers.
Filesystem Container
See File_Systems description.
This container is allowed by OCF.
This container would be used during production stages, and for CD-based distribution.
TAR Container
See TAR/Gzip for technical points.
This container is not allowed by OCF 1.0.
This would be used when shipping renditions with audio/video, and when targeting online reading/distribution.
This would be a case where we would mandate the use of another mime type and another file extension (.dpub). (The other case when another mimetype+fileextension is used is when the container does not contain an epub.)
Container Level Fallback
- Container level fallback would not be required but recommended.
- The notion of "lowest common denominator" rendition remains: its either an EPUB or a DAISY audio profile, or both.
- Spec needs description of how the provider/publisher can express the "precedence" order. Either:
- read container.xml, evaluate each entry in the order that they occur, pick the first one thats supported.
- use metadata.xml to describe the precedence
- Spec needs to describe the canonical names of the rendition types in the abstract container.
Actions at Profile Creation Time
Perhaps: decide which of the physical containers to support in the profile.
On the other hand, it makes sense to require all profiles to support all containers, since in many cases profiles are used as fallbacks.
Extension Points
None.
