ZedDist Profiles
From zedwiki
This is a discussion page for the profiles target in ZedDist_Design_Goals. It is part of the architecture groups' inception activity, and will eventually contain a finalized proposal on whether to use a profile approach in ZedNext, and if so what the fundamental properties will be.
This page is under construction
Contents |
Strawman Linkage Area
ZedDist_Profiles_Component_Pool_Principle
Discussion area
The monolith approach
Previous specifications defining the DAISY DTB have been of a "monolithic" nature: they have defined one single logical model of the DTB.
A certain amount of variation (some may remember the "six types of DTB") has been enabled by making some parts of the DTB fileset optional; an NCX-only DTB does not have textual content document; a Text-only DTB does not have any audio elements in SMIL, etc. But apart from this, there is a quite dominant staticity: there is one grammar for SMIL, one grammar for the NCX, one grammar for textual content, and the rules for how these interact and co-depend does not vary.
The Profile approach
As DAISY expands into new usage domains, the requirements on what functionality DAISY should encompass increases. In the 2010 revision, the planned addition of video and interactivity are two examples. At the same time, the "classic" usage scenarios (some of which are already satisfied by previous specs) remain, and must not be threatened by this expansion.
Whilst the new functionality is needed and welcomed in some contexts, the added cost of implementation and the added complexity is a threat in other contexts. Threats include both cost of implementation (a vendor threat) and feature bloat (a threat to users).
Enter as a possible solution the profile approach: the idea to recast the Z3986 spec as a framework which defines a set of building blocks that can be strung together in different ways to achieve a particular feature set (aka a profile). Some building blocks may be optional, others may be unique (created only for a particular profile), others may be universally required (omnipresent).
Benefits of the Monolithic approach
- Guarantees interoperability and predictability. A device that that is compliant to a monolithic spec will never encounter any surprises
- Can possibly be claimed to minimize implementation cost: "implement once, read everything"
Drawbacks of the Monolithic approach
- Can result in suboptimal (not maximally effective) solutions to problems or needs. Trying to squeeze our expanding feature set and usage domains into one single logical model is becoming increasingly difficult.
- Does not allow adaption to specific contexts @@TODO write
- Limits extensibility @@TODO write
Benefits of the Profile approach
- Allows distributed DTBs to be tailored for their intended use, without overhead or noise. This benefit applies to both implementors and end users.
- Allows tool vendors to specialize in specific subdomains. A vendor wanting to focus on low-cost hardware devices for classic audio books can do so without having to spend any cycles dealing with video, interactivity or MathML rendering. A vendor wanting to focus on scientific work-books can do so, and provide highly specialized tools in support of this.
- Potentially allows the subsequent addition of new content types or features without requiring a revision to the spec. Many frameworks built on modularization principles allow for foreign content to be brought in, as long as that "island" is accompanied by some kind of fallback, or complies with some other set of rules that guarantee processability in tools that do not recognize the island. (The simplest of these rules being: "ignore what you dont understand")
Drawbacks of the Profile approach
- Poses a threat to interoperability. What happens if a reading device is fed a Profile that it does not support (or does not recognize)? DAISY Users have not had to worry (much) about this so far.
- Can possibly be claimed to increase implementation cost due to overhead in terms of the inherent variability of content.
Discussion Topics
In designing a candidate architecture for DTB profiles, the below discussion topics needs to be covered initially. We should remember that a monolith approach is not excluded as an alternative. A candidate architecture should help us decide whether to go for the monolith or the profile approach.
- What constitutes a well-designed profile?. How does one decide what goes in a profile and what does not? Is a profile designed to cover the needs of a particular (set of) user group(s)? A particular set of usage patterns? Cost-of-implementation thresholds? Or is this ad-hoc? Even if the spec itself remains silent on this, we need principles to guide us when we define the profiles that ship with the spec itself.
- What would be a candidate set of profiles to ship with the spec? Even if we allow additional profiles to be created post-spec (see below), having a set of profiles defined when the spec ships is of paramount importance as it will set a precedence, and have impact on the adoption rate.
- What aspects should be allowed to vary between profiles, and what aspects (if any) must be static?. As examples,
- in terms of navigation, we could (theoretically) say that a) any or no means for navigation may be included in a profile, or b) that navigation must be available, and use modules from the NCX namespace (using a modularized NCX to allow profiles to pick only the parts they need).
- in terms of textual content, we could allow any text content type (as long as it is, say, XML, or an SGML derivative) or we could mandate XML and the use of a particular root grammar (possibly modularized so that it could be customized), and hooks for foreign namespace islands (for the latter approach, see ZedAI).
- in terms of package identity, would the OPF be an always-required member of the fileset?
- Can we develop a universal fallback mechanism that is employed to maintain compatibility in the field? Intent: content should be able to "present itself" to a reading device in multiple ways (polymorphism) so that the device can pick a shape and form it supports.
- Is it desirable to define a mechanism to create new profiles without the need to revise the spec?. This is the "framework" approach discussed in DAISY_Accessibility_Framework, and comes with both threats and promises. A mechanism like this is defined in ZedAI, but the ZedDist context is so fundamentally different that the question on the desirability of this feature needs to be raised. Note - an alternate approach to this is to not allow new profiles, but have profiles define their own internal extension points (such as XML islands in textual content documents).
