DAISY Pipeline 2.0 High-Level Requirements
The DAISY Pipeline 2.0 project is the follow up of the DAISY Pipeline 1.0 project hosted and maintained by the DAISY Consortium. It consists mostly in preparing for the future by redesigning the core Pipeline framework to embrace new technologies and standards and better integrate with the DAISY community and publishing mainstream.
This document describes the high-level domain and functional requirements, and should serve as a reference for the core architectural decisions. You are invited to send comments via the DAISY Pipeline Developers Google Group.
General Requirements
Maximize cross platform support
In order to leverage the skills and codebase developed in the Pipeline 1.0 and the surrounding projects, the Pipeline 2.0 project will keep on being developed on the Java platform. Additionally and as the proposal suggests, a particular focus on cross-platform support should simplify its integration into the heterogeneous infrastructural contexts that constitute the current DAISY community.
- the core engine implementation should run on multiple operating systems (at least Windows, Linux, Mac OS X)
- the use of standard exchange formats and protocols should be favored over custom solutions
- the core engine functionality should be delivered as a software component that can be embedded in third party applications
- a Web Service layer should be provided to expose the core engine functionality to possibly remote, non-Java applications (e.g. .Net or Python applications)
- different user interfaces should be made available: at least a minimalist UI and a web-based front-end
Maximize extensibility and customizability
The Pipeline is a community-driven project: the wide range of features should be customizable to cover the different usage scenarios, and the platform should be easily extensible to welcome external contributions.
- the Pipeline 2.0 deliverables should be liberally licensed and allowed to be reused in both open source or commercial contexts
- the Pipeline 2.0 framework should heavily rely on a component model (e.g. based OSGi)
- the feature set should be split into several reusable software components
- a plugin mechanism should be provided to facilitate the contribution of a piece of functionality as a cohesive module, with no restriction on the programming language used.
- it should be at least possible to write a simple plugin delegating the work to an external process.
- potentially, fine-grained integration to the Pipeline could be made available via a language-agnostic communication protocol (e.g. web services)
- possibly, the underlying component model should allow dynamic addition/removal of feature components
- it should be possible to use only a subset of the available components to create dedicated distributions
- the configuration of the components functionality should be based on standard formats and patterns and be as unified as possible
Maximize likelihood of integration with the XML publishing mainstream
The DAISY standard is obviously not the only XML-based publication format and the Pipeline is not the only tool for processing such XML documents. Therefore, a particular attention should be brought on its good interoperability and integration with the mainstream XML publishing standards and technologies. As hinted in the project proposal, it will eventually make it easier for partners to get involved and contribute to the project and possibly reduce both initial development and eventual maintenance cost.
- the Pipeline 2.0 should maximize the use of the XProc W3C standard and if possible use it as the central scripting language
- whenever it is possible, Pipeline 2.0 features should be implemented as purely standard solutions (e.g. XProc + standard XSLT steps)
- if possible the Pipeline proprietary additions should be streamlined with existing standards to maximize their chance of adoption
- the Pipeline 2.0 should easily reuse or be coupled with existing standard-based XML-oriented toolsets (e.g. the DocBook XSL stylesheets)
Initial Conversion/Processing Requirements
Provide a reference implementation of the DAISY 4 standard revision
The launch of the Pipeline 2.0 project concurs with the ongoing revision of the DAISY standard. As obviously stated in the project proposal "by supporting DAISY 4 early in the lifespan of the standard, we lower the entry threshold and speed up the adoption rate of said standard."
- the initial feature set should at least contain support for simple XML processing of Z39.86-2010 Authoring and Interchange (aka "ZedAI") documents (possibly implemented using XProc+XSLT)
- Z39.86-2010 Authoring and Interchange to dtbook
- the Pipeline functionality should facilitate the production of content compliant with the Z39.86-2010 Distribution specification (aka "ZedDist"). Possibly, a Z39.86-2010 Authoring and Interchange to Distribution narrator/producer should be implemented)
Provide a new multi format validator
- the ongoing DAISY Validator project should be eventually integrated in the Pipeline 2.0 effort
- see the DAISY Validator requirements for a detailed description