This document discusses overarching themes related to deploying the DAISY Pipeline within an organisation.
Target audience: system integrators, administrators, developers
Latest update: 2007-11-26
As defined in the original system requirements document of the DAISY Pipeline project, the tool is designed to allow deployment in both desktop- and serverbased environments. This means that the tool
The choice of which of these deployment options to use obviously varies with which parts of the Pipeline functionality is to be exposed, and the nature of the clients.
Many organisations within the DAISY community engage in creation of XML documents that serve as a basis for output formats such as DTBs, E-text, Braille etc.
Via its support for (for example) RTF, ODF, and WordML as input formats, the Pipeline can serve as a utility tool for creating XML masters (typically, but not restricted to, the DTBook format), and then manipulating/converting these further, either to enrich the master quality, or to create concrete output formats via automated processes.
As the DAISY Pipeline scope includes both processing of singular XML documents as well as filesets (such as DTBs), much of the functionality in the Pipeline pertains to DTBs, and includes functionality that targets pre-production, production and post-production stages. The Script and Transformer summary should give an overview of what the DTB-related processing options are.
The validation framework built into the DAISY Pipeline supports many content types and all standardized Schema languages. As such, the validation framework can be used to perform canonical validation of XML documents and DTBs, but it also supports the addition of local (organisation-specific) subset rules.
The general philosophy regarding validation within the Pipeline is to strive to integrate validation seamlessly into production flows, by removing the need to use separate applications for validation. This means that validation is typically integrated into other Scripts as a last (and/or intermediary) step. However, the Pipeline can be used for validation-only purposes as well.
The DAISY Consortium is during 2007 and 2008 investing in the "DAISY Content Migration and Safety Suite", a subproject within the Pipeline which (by building on the already existing validation framework) will provide functionality relating to content migration and repair. The migration aspect of this project will deliver tools to move DTBs between differernt versions of the DAISY standard (such as upgrading a Daisy 2.02 DTB to Z3986 for longevity and archival purposes, and "downgrading" a Z3986 DTB to Daisy 2.02 (for distribution purposes). A migration suite for DTBook documents will also be provided, as well as a "repair" utility (available in a first version in the December 2007 release of the Pipeline) for DTBook documents.
The Narrator Script within the Pipeline is a highly configurable XML and TTS-based DTB production system that is built to support scalable high-speed rendering server-side.
Parts of or all transformation services within the Pipeline can be exposed either publicly or to a restricted set of users (say, within the context of a university) to process and/or create various types of output media from a single input document.
The Pipeline can be integrated as a transformation service provider at distribution time, allowing the distributed media to be dynamically taylored for a particular user or a particular user group.
The Pipeline can be integrated as a service provider at input media delivery time, acting for example as a gateway for a centralized storage area that receives different types of input from multiple locations.
The validation framework of the Pipeline can be exposed online to allow a set of distributed production agencies to have a single point of entry for content validation.
The default (and publicly available) functionality of the DAISY Pipeline has been written to be globally applicable. Many times (and thanks to the fact that we are using standards), this functionality can be directly transferred and used within a local organisational context. However, there are cases when localization and/or functionality additions are needed to allow a Pipeline deployment to reach its full potential.
A majority of the Pipeline Transformers have been written to allow localization via extensions or via provision of external behavioral guidance configurations.
Some of these extensions can be realized using only script parameters; others will need the intervention of a systems admin or a developer.
The localization features are typically described in the Transformer documentation. As an example, see Localizing and customizing Pipeline Narrator.
When the default Pipeline functionality does not cover all local needs, the solution is to develop one or several local Transformers (which, if they have use cases outside of your own organisation, you may choose to contribute back to the public). Sometimes, it is enough to append or replace a Transformer in an existing Script; sometimes an entire Script (with one or many transformers referenced) is needed.
A Pipeline installation can contain any combination of public and organisation-specific Transformers and Scripts. A Pipeline installation can also contain any combination of free and commercial Transformers and Scripts.
Developers, please see the Transformer Authoring Guide for more information.
The Pipeline is written to be a context-agnostic tool to be deployed within varying technical and business infrastructures. As such, it naturally does not provide nor impose any business logic layers; such layers must always be provided locally.
The Pipeline ships with a set of prebuilt interfaces:
In some circumstances, it is desirable to provide distributions which limit the functionality of the Pipeline for a certain use case, and which provide a user interface taylored for that limited functionality.
The Pipeline can be made to accomplish this by doing the following: