Open Publication Structure (OPS) 2.0 v0.9871.0
Recommended Specification July 11, 2007September 11, 2007
Copyright © 2007 by International Digital Publishing Forum™.
All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum.
Table of Contents
1.3: Relationship to Other Specifications
1.3.2: Relationship to XML Namespaces
1.3.4: Relationship to XHTML and DTBook
1.3.6: Relationship to Unicode
1.3.8: XML Style Sheet Processing Instruction
1.4.1: OPS Content Document Conformance
1.4.1.2: XHTML Content Document Requirements
1.4.1.3: DTBook Content Document Requirements
1.4.1.4: Out-of-Line XML Island Content Document Requirements
1.4.2: Reading System Conformance
1.4.3: Compatibility with Future Versions
2.0: OPS Content Document Vocabularies
2.2: XHTML Modules in the OPS Preferred Vocabulary
2.3: Certain Element and Attribute Semantic Differences From, and Restrictions Beyond, XHTML 1.1
2.3.1: General Comments on URI References
2.3.6: object and param Elements
2.3.7: script and noscript Elements
2.3.8: type attribute of the style element
2.3.9: Value of align attribute
2.4: DTBook Preferred Vocabulary
2.4.2: DTBook Usage Requirements
2.4.2.1: Exceptions to Section 4 of the DAISY/NISO Standard
2.5.1: General Notes on SVG Usage
2.5.2: SVG’s Use as a Standalone Image File
2.5.3: Mixing SVG and XHTML Mark-up in the Same Document
2.6.1: Introduction to XML Islands
2.6.2: Out-of-Line XML Islands
2.6.2.1: Document Requirements
2.6.2.2: Fallback Requirements
2.6.2.3.1: Document-Level Links
2.6.3.1: The switch Element and Contained Elements
2.6.3.1.2.1: required-namespace Attribute
2.6.3.1.2.2: required-modules attribute
2.6.3.2: Processing Inline XML Islands
2.6.3.3: Displaying Inline XML Islands
2.6.3.3.1: Advanced Display Semantics
2.6.3.4: Linking Considerations
In order for electronic-book technology to achieve widespread success in the marketplace, Reading Systems need to have convenient access to a large number and variety of titles. The Open Publication Structure (OPS) Specification describes a standard for representing the content of electronic publications. Specifically:
Another related specification, the Open Packaging Format (OPF) Specification, defines the mechanism by which the various components of an OPS publication are tied together and provides additional structure and semantics to the electronic publication. Specifically, OPF:
The OPF specification is separated from this OPS markup specification to modularize the
described packaging methodology separate from the described content. This will help
facilitate the use of the packaging technology by other standards bodies (e.g.
DaisyDAISY) in non-OPS contexts.
A third specification, the OEBPS Container Format (OCF) Specification, defines the standard mechanism by which all components of an electronic publication may be packaged together into a single archive for transmission, delivery and archival purposes.
Content Provider
A publisher, author, or other information provider who provides a publication to one or more Reading Systems in the form described in this specification.
Deprecated
A feature that is permitted, but not recommended, by this specification. Such features might be removed in future revisions. Conformant Reading Systems must support deprecated features.
Extended Module
A module of a modularized XML vocabulary (i.e. a set of named modules is defined in its specification) that is not required to be supported by its specification (e.g. the XHTML ruby or forms modules in the OPS context).
Inline XML Island
An Inline XML Island is an XML document fragment using a non-Preferred Vocabulary or using an Extended Module that exists within an XHTML Preferred Vocabulary document within an OPS Publication.
NCX
A declarative table of contents (the Navigation Center eXtended or NCX).
NVDL
NVDL (Namespace-based Validation Dispatching Language) is a specification which allows for cross-schema validation of documents. This specification uses the NVDL language as a means of unambiguously defining how various schemas are handled within the context of OPS.
OCF
The OEBPS Container Format defines a mechanism by which all components of an OPS Publication may be combined into a single file-system entity.
OEBPS
The Open eBook Publication Structure. Previous versions of this specification (OPS) and its related specification, OPF, were unified into the single OEBPS specification. For this version, OEBPS was broken into OPS and OPF to aid modular adoption of the specifications. OEBPS 1.2 was the highest version of the previous unified specification.
OPF
The Open Packaging Format is the sister-standard to this standard. It defines the mechanism by which all components of a published work conforming to this standard along with metadata, reading order and navigational information are packaged into an OPS Publication.
OPF Package Document
An XML document that describes an OPS Publication and references all files used by the OPS Publication that are not part of the OPF Package Document itself. It identifies all other files in the publication and provides descriptive information about them. The OPF Package Document is defined by the OPF Specification.
OPS
The Open Publication Structure — this standard.
OPS Content Document
An XHTML, DTBook, or Out-Of-Line XML Island that conforms to this specification that may legally appear in an OPF Package Document spine element.
OPS Core Media Type
A MIME media type that all Reading Systems must support.
OPS Publication
A collection of OPS Content Documents, an OPF Package Document, and other files, typically in a variety of media types, including structured text and graphics, that constitute a cohesive unit for publication.
Out-of-Line XML Island
An Out-of-Line XML Island is an XML document, which exists within an OPS Publication, and is either not authored using a Preferred Vocabulary or is authored using a Preferred Vocabulary but uses Extended Modules. It is an entirely separate, complete, and valid XML document.
Preferred Vocabulary
XML consisting only of OPS-supported XHTML modules and/or DTBook markup.
Reader
A person who reads a publication.
Reading Device
The physical platform (hardware and software) on which publications are rendered.
Reading System
A combination of hardware and/or software that accepts OPS Publications (preferably packaged in an OCF Container) and makes them available to consumers of the content. Great variety is possible in the architecture of Reading Systems. A Reading System may be implemented entirely on one device, or it may be split among several computers. In particular, a Reading Device that is a component of a Reading System need not directly accept OPS Publications, but all Reading Systems must do so. Reading Systems may include additional processing functions, such as compression, indexing, encryption, rights management, and distribution.
XML Document
An XML document is a complete and valid XML document as defined by XML 1.1 standard. (http://www.w3.org/TR/xml11/).
XML Document Fragment
Referred to as either a document fragment or as an XML Document Fragment, as defined in Document Object Model Level 1 (http://www.w3.org/TR/REC-DOM-Level-1/) but with the additional requirement that they be well-formed.
XML Island
An Inline XML Island or an Out-of-Line XML Island.
XML Namespaces
Referred to as XML namespaces, or just namespaces, these must conform to XML Namespaces (http://www.w3.org/TR/xml-names11/).
XPointer
The XML Pointer Framework is a W3C specification that defines a method of
pointing into specific locations within an XML document, thus identifying document
fragments, as defined in XML Pointer Framework (http://www.w3.org/TR/xptr-framework/).
This specification combines subsets and applications of other specifications. Together, these facilitate the construction, organization, presentation, and unambiguous interchange of electronic documents:
OPS is based on XML because of its generality and simplicity, and because XML documents are likely to adapt well to future technologies and uses. XML also provides well-defined rules for the syntax of documents, which decreases the cost to implementers and reduces incompatibility across systems. Further, XML is extensible: it is not tied to any particular type of document or set of element types, it supports internationalization, and it encourages document markup that can represent a document’s internal parts more directly, making them amenable to automated formatting and other types of computer processing.
Reading Systems must process XML namespaces according to the XML Namespaces Recommendation at http://www.w3.org/TR/xml-names11/.
Namespace prefixes distinguish identical names that are drawn from different XML vocabularies. An XML namespace declaration in an XML document associates a namespace prefix with a unique URI. The prefix can then be employed on element or attribute names in the document. Alternatively, a namespace declaration in an XML document may identify a URI as the default namespace, applicable to elements lacking a namespace prefix. The XML namespace prefix is separated from the suffix element or attribute name by a colon.
Example:
xmlns:ops="http://www.idpf.org/2007/ops"
The root element of all OPS Content Documents must
explicitly specify the namespace of the document. For the XHTML Preferred Vocabulary,
this namespace is http://www.w3.org/1999/xhtml. For
the DaisyDAISY Talking Book Preferred Vocabulary, this
namespace is http://www.daisy.org/z3986/2005/dtbook/.
If the OPS namespace is used in a document it must be
explicitly declared http://www.idpf.org/2007/ops. If a
namespace prefix is used, it is recommended that authors
bind the ops prefix to that namespace and not use
ops as the prefix for other namespaces.
Example:
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ops=" http://www.idpf.org/2007/ops">
As OPS has additional functionality and validation requirements beyond the preferred document types and XML islands, there are other namespaces associated with OPS, which are used in specific contexts.
This specification uses the NVDL language (see http://standards.iso.org/ittf/PubliclyAvailableStandards/c038615_ISO_IEC_19757-4_2006(E).zip) as a means to unambiguously define the interaction between the various schemas used in this specification. NVDL allows for interaction and validation between various XML schema languages. See Appendix A for a normative NVDL definition of OPS.
This specification does not require the use of NVDL tools to validate OPS documents, although such tools are available and may be used for validation.
This specification recognizes the importance of current software tools, legacy data, publication practices, and market conditions, and has therefore incorporated certain XHTML 1.1 Document Type Modules and DTBook as Preferred Vocabularies. This approach allows content providers to exploit current XHTML and DTBook content, tools, and expertise.
To minimize the implementation burden on Reading System implementers (who may be working with devices that have power and display constraints), the Preferred Vocabularies do not include all XHTML 1.1 elements and attributes. Further, the modules selected from the XHTML 1.1 specification were chosen to be consistent with current directions in XHTML.
Any construct deprecated in XHTML 1.1 is either deprecated or omitted from this specification; CSS-based equivalents are provided in most such cases. Style sheet constructs are also used for new presentational functionality beyond that provided in XHTML.
This specification defines a style language based on CSS 2. (Note that the CSS 2.1 specification is currently still at "Working Draft" status.) The style sheet MIME type text/x-oeb1-css has been deprecated in favor of text/css.
The CSS-based style sheet constructs in this specification define required rendering functionality. To minimize the burden on Reading System developers and device manufacturers, not all CSS 2 properties are included. A few additional properties and values have been added to support page layout, headers, and footers. These, taken together, constitute the OPS CSS 2.0 required subset.
In a number of cases, this specification does not require Reading Systems to provide the full range of rendering that a standard CSS style sheet might request. For example, some Reading Systems will use monochrome displays. It would neither be acceptable to limit all Reading Systems to monochrome, nor to declare color use a non-standardized extension beyond OPS. In such cases, the CSS settings are allowed, and keep their meanings; but a conforming Reading System may gracefully degrade to a simpler rendering.
A conforming Reading System must render all OPS CSS 2.0 required subset properties. A Reading System may support CSS properties beyond the OPS CSS 2.0 required subset, however, any unsupported properties must be gracefully degraded per the CSS 2.0 specification.
This specification supports the style attribute (though deprecated), the style element, and externally linked style sheets. Reading Systems must perform XML-namespace handling while processing style sheets.
Style sheets can be associated with an OPS Content Document in several ways:
The relative priority of the first three cases is as defined for XHTML 1.1 and CSS 2. Style sheets linked via a processing instruction are treated as if they had been linked via XHTML link elements preceding any actual XHTML link elements. As defined in the Conformance section, if no style sheet is defined or no applicable style is found for a given element, XHTML rendering is the default as defined elsewhere in this specification.
External style sheets linked via the XHTML link element
or by the processing instruction xml-stylesheet,
however, may use thisCSS or any
other style language, such as XSL (see http://www.w3.org/TR/xsl). Reading Systems are
not required to support any style sheet language beyond the CSS specified herein.
Reading Systems that implement only the OPS CSS 2.0 required subset may ignore any style sheets using other style languages. Reading Systems that support extended style sheet functionality may choose among any of the other external style sheets. It is strongly recommended that unique MIME media types be defined for any style sheet languages supported beyond the OPS CSS 2.0 required subset, and that style sheets in those languages be detected by examining the MIME media type.
Use of the CSS position property values to achieve absolute positioning (i.e. absolute and fixed) is strongly discouraged.
Publications may use the entire Unicode character set, using UTF-8 or UTF-16 encodings, as defined by Unicode (see http://www.unicode.org/unicode/standard/versions). The use of Unicode facilitates internationalization and multilingual documents. However, Reading Systems are not required to provide glyphs for all Unicode characters.
Reading Systems must parse all UTF-8 and UTF-16 characters properly (as required by XML). Reading Systems may decline to display some characters, but must be capable of signaling in some fashion that undisplayable characters are present. Reading Systems must not display Unicode characters merely as if they were 8-bit characters. For example, the biohazard symbol (0x2623) need not be supported by including the correct glyph, but must not be parsed or displayed as if its component bytes were the two characters "&#" (0x0026 0x0023).
To aid Reading Systems in implementing consistent searching and sorting behavior it is required that Unicode Normalization Form C (NFC) be used (See http://www.w3.org/TR/charmod-norm/).
This specification defines a list of OPS Core Media Types that all Reading Systems must support and publications may include. Publications may include resources of other media types, but each such resource must include an alternative resource of an OPS Core Media Type using methods defined in this specification or the OPF specification.
The OPS Core Media Types are:
| MIME Media Type | Reference | Description |
| image/gif | http://www.w3.org/Graphics/GIF/spec-gif89a.txt | Used for raster graphics |
| image/jpeg | http://www.w3.org/Graphics/JPEG/ | Used for raster graphics |
| image/png | RFC 2083 | Used for raster graphics |
| image/svg+xml | http://www.w3.org/TR/SVG11/ |
Used for |
| application/xhtml+xml | XHTML 1.1 | Used for OPS Content Documents |
| application/x-dtbook+xml | http://www.niso.org/standards/resources/Z39-86-2005.html | Used for OPS Content Documents |
| text/css | CSS 2.0 | Used for OPS CSS-subset style sheets |
| application/xml | http://www.w3.org/TR/xml11/ | Used for Out-Of-Line XML Islands |
| text/x-oeb1-document | OEBPS 1.2 specification | Deprecated; Used for Basic or Extended OEBPS 1.0.1 and 1.2 Documents |
| text/x-oeb1-css | OEBPS 1.2 specification | Deprecated; Used for OEBPS 1.0.1 and 1.2 CSS-subset style sheets |
| application/x-dtbncx+xml | DTBook specification | The NCX |
This specification includes support for the XML style sheet processing instruction xml-stylesheet, defined in the W3C Recommendation "Associating Style Sheets with XML Documents" (http://www.w3.org/TR/xml-stylesheet). This processing instruction is placed in the prolog of the XML document. It can appear multiple times as can link.
The keywords "must", "must not", "required", "shall", "shall not", "should", "recommended", "may", and "optional" in this document must be interpreted as described in RFC 2119.
This section defines conformance for OPS Content Documents and Reading Systems.
This section defines conformance for OPS Content Documents.
A document is considered an OPS Content Document if and only if:
A conformant XHTML Content Document must meet these conditions:
A document is a DTBook Content Document if and only if:
A document is an Out-of-line XML Island Content Document if and only if:
This specification defines only one level of conformance for a Reading System. A Reading System is conformant if and only if it processes documents as follows:
When presented with an OPS Content Document the Reading System must:
It is the intent of the contributors to this specification that subsequent generations of this specification continue in currently established directions. Specifically:
Version 2.0 of OPS offers fairly significant enhancements over its preceding version, OEBPS 1.2. Version 2.0 adds substantial functional enhancements over 1.2, these include: supporting enhanced control over content presentational fidelity, providing an enhanced extension mechanism, improving accessibility, and improving alignment with the standards upon which OPS is based. Specifically, the following are the most substantive additions:
While most changes from version OEBPS 1.2 to OPS 2.0 have been done via deprecation rather than removal of previous functionality, OEBPS version 1.2 is not a fully compatible subset of OPS 2.0 (e.g. new XML validity and namespace processing requirements).
XML Islands are the recommended mechanism for adding functionality, information or structure beyond that supported by the Preferred Vocabularies.
Out-Of-Line XML Islands may be used in any publication. Inline
XML Islands maymust
not only be used within documents authored using other
than the XHTML Preferred Vocabulary.
This specification incorporates features that ensure content can be made accessible to, and usable by, persons with reading disabilities. Existing accessibility features developed by the World Wide Web Consortium (W3C) for XHTML 1.1 for content accessibility are incorporated into this specification.
OPS XHTML Content DocumentsPublications should be authored in accordance with the W3C Web Content Accessibility
Guidelines 1.0 (http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/) or,
if it is released while the Working Group is active, the Web Content Accessibility
Guidelines 2.0 (the current draft is available at http://www.w3.org/TR/WCAG20/ to ensure that the
broadest possible set of users will have access to books delivered in OPS format.
In addition, recommendations from the W3C HTML 4.0 Guidelines for Mobile Access (http://www.w3.org/TR/NOTE-html40-mobile/) and the W3C Web Accessibility Initiative's proposed User Agent Guidelines (http://www.w3.org/TR/WD-WAI-USERAGENT/) ought to be reviewed and applied by OPS implementers to ensure that Reading Systems will be in conformance with accessibility requirements.
This specification is designed to take advantage of current practices while preparing
for future developments. Although details of subsequent versions of this specification
remain to be determined, it is the expectation of the Publication Structure Working
Group that continued evolutionary development will occur. The themes driving the
creation of version 2.0 of OPS are: standards compliance (e.g. full namespace support),
accessibility support, support for any XML document typesupport for a
wide-range of XML document vocabularies, enhanced navigation support, and
improved content presentational fidelity.
Other themes deemed important for future versions include: more rigorous separation of content and presentation, greater accessibility, better support for international content, Reading Device-specific presentation control and/or Reading Device profiles, enhanced support for inter-Publication linking, layering and managing markups (e.g. inking, highlighting, notes) within Publications, application-specific markup (e.g. math, chemical), multiple reading orders, and support for active content (e.g. multimedia, scripting), all while maintaining alignment with relevant standards. Additionally, maintaining backward compatibility to this version of this specification ought to remain a high priority. Future directions can be tracked at http://www.idpf.org.
OEBPS 1.2 and its predecessors specified a "Basic" document vocabulary, drawn from the XHTML 1.1 document type, which all Reading Systems were required to support. This specification no longer creates its own subset of XHTML 1.1, but instead references entire XHTML modules, as described in XHTML Modularization 1.1 (http://www.w3.org/TR/xhtml-modularization/). In addition to XHTML, OPS adds the DAISY DTBook document type as a Preferred Vocabulary (see http://www.niso.org/standards/resources/Z39-86-2005.html).
The XHTML modules listed in this section and the DTBook vocabulary are considered the OPS Preferred Vocabularies. The concepts of "Basic" and "Extended" documents are no longer used by this specification. OPS publications should use one of the Preferred Vocabularies. Publications that use other vocabularies, either as entire documents or as XML fragments, must use the Inline or Out-Of-Line XML Island mechanisms, described elsewhere in this specification. XHTML modules beyond those listed here (Extended Modules) may be used in a conforming publication, but must follow the guidelines set forth in the XML Islands section of this document.
As with any DTD referenced from the DOCTYPE declaration, OPS XHTML Content Documents must not reference the XHTML DTD unless such documents are valid with respect to that DTD (i.e. it do not include Inline XML Islands or inline SVG).
OPS requires all conforming Reading Systems to support the following modules consistent with their descriptions in the XHTML and HTML specifications, unless otherwise specified in this document.
| XHTML 1.1 Module Name | Elements (non-normative) |
| Structure | body, head, html, title |
| Text | abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p, pre, q, samp, span, strong, var |
| Hypertext | a |
| List | dl, dt, dd, ol, ul, li |
| Object | object, param |
| Presentation | b, big, hr, i, small, sub, sup, tt |
| Edit | del, ins |
| Bidirectional Text | bdo |
| Table | caption, col, colgroup, table, tbody, td, tfoot, th, thead, tr |
| Image | img |
| Client-Side Image Map | area, map |
| Meta-Information | meta |
| Style Sheet | style |
| Style Attribute (deprecated) | style attribute |
| Link | link |
| Base | base |
As previously noted, the semantics and rendering behavior of the XHTML Preferred Vocabulary (elements, attributes, and associated attribute values) strictly follows that of XHTML 1.1. However, there are several restrictions beyond that of XHTML 1.1, as noted below. These restrictions have no effect on the XHTML 1.1 conformance of OPS documents.
A number of attributes reference resources using URI values (Uniform Resource Identifier, see RFC 2396, http://www.ietf.org/rfc/rfc2396.txt). Depending on the particular attribute, the URI referenced resource can either be an abstract entity or a physical object.
Except where noted or where not applicable, Reading Systems may use or render a URI referenced physical resource not listed in the Manifest (i.e., it is not a component of the Publication), but they are not required to do so.
It is assumed, in formatting, that the default rendering for body is consistent with the CSS property page-break-before having been set to right (which behaves like always on one-page Reading Systems), but may be overridden by an appropriate style sheet declaration.
The optional attribute cite may be used in blockquote, q, del and ins to provide a URI citation for the element contents. Reading Systems are not required to process or use the referenced URI resource, whether or not the resource is listed in the Manifest.
The inline element img should only be used to refer to images with OPS Core Media Types of GIF (http://www.w3.org/Graphics/GIF/spec-gif89a.txt), PNG (RFC 2083), JPG/JFIF (http://www.w3.org/Graphics/JPEG) or SVG (http://www.w3.org/TR/SVG11/). The required URI attribute, src, is used to reference the image resource, which must be listed in the Manifest.
The required alt attribute should contain a brief and informative textual description of the image. This text may be used by Reading Systems as an alternative to, or in addition to, displaying the image. The text is also an acceptable fallback for an img with src referencing a non-OPS Core Media Type for which no viable fallback was found in the manifest. The alt textual description is useful for Reading Systems having limited resolution displays, or for non-visual presentation. Use of the object element is the preferred mechanism for including non-core media types in an OPS Content Document.
For long descriptions, the optional title attribute may be used. Reading Systems may display the title attribute in addition to or in place of the alt text or displaying the image.
For greater accessibility, it is strongly recommended that OPS Content Document authors include a URI reference in the optional longdesc attribute referencing a resource (such as another OPS Content Document in the Publication) describing the image in finer detail. Reading System developers are also strongly urged to recognize and render in an appropriate fashion (and with accessibility in mind) the resource specified in longdesc. For further information on the use of this attribute and related accessibility attributes, see http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#gl-provide-equivalents.
The link element allows for the specification of various relationships with other documents. Reading Systems must recognize external style sheet references specified via the href attribute and the associated rel attribute (for the values rel="stylesheet" and rel="alternate stylesheet".)
The object element is the preferred method for generic object inclusion. When adding objects whose data media type is not drawn from the OPS Core Media Type list or which reference an object implementation using the classid attribute, the object element must specify fallback information for the object, such as another object, an img element, or descriptive text. Inline fallback information is provided as OPS content appearing immediately after the final param element that refers to the parent object. Descriptive text for the object, using inline content, an included OPS Content Document, or some other method, should be provided to allow access for people who are not able to access non-textual content.
The classid attribute of an object gives the URI value of an implementation for the object. Conformant Reading Systems are not required to render objects that use external implementations, although they may do so. The MIME media type values for the codetype and type attributes must match those specified in the Publication's Manifest.
The associated param empty element is used to specify initialization values for objects. The param element must only appear before the renderable content of an object. Reading Systems must examine only param elements that are direct children of the object.
Example:
<object classid="clsid:AFAFAFA-0101-1010-0101-ABABABABABA"
codebase="http://www.example.com/SomeScriptingLanguage/">
<param name="code" value="TicTacToe.class">
<param name="codebase" value="html/">
<param name="type" value="application/x-somescriptinglanguage">
<param name="model" value="models/TicTacToe.model">
<param name="scriptable" value="true">
<object type="image/png" data="tictactoe.png">
Tic-Tac-Toe, a <em>dull</em> game.
</object>
</object>
Reading Systems must not, by default, render the
textual content of the script element, and should not execute the script itself. The content must be readable
without execution of script elements.
If noscript is included, whose purpose is to display some message if the Reading System chooses not to execute the script, it must appear after the closing tag of the script it is associated with. Reading Systems must, by default, render the content contained in noscript if they do not execute script (as is recommended), the default of which can be overridden by CSS display:none. Note that for XHTML 1.1 conformance the content model for noscript is Block.mix (block level elements plus the "level-independent" elements); it cannot directly contain text or inline elements and is identical to the content model for body and blockquote, even if noscript itself appears inline.
The attribute type, which specifies the scripting language for script, is required.
One potential problem with script, whose content model is #PCDATA, is that if the code contains the characters "<" and "&", there is a potential conflict with XML. Thus, these characters, if used, must either be escaped, or put into a CDATA section. Reading System developers who include script execution capability need to be aware of this potential problem.
The type attribute of the style element is required (per XHTML 1.1 requirements) and must be given the value of text/css or the deprecated text/x-oeb1-css. For browser rendering of an individual OPS Content Document as an XHTML 1.1 document, instances of the deprecated text/x-oeb1-css should be changed to text/css.
The value of char for the align attribute is not included in the OPS XHTML subset. To achieve similar formatting, use the CSS text-align property with a string value.
DTBook is an XML vocabulary defined in the DAISY/NISO standard, formally, the ANSI/NISO Z39.86-2005 Standard. This vocabulary is specifically designed for eBook content. Many structures not found in XHTML are included: footnotes, sidebars, annotations, page numbers, etc. Identifying the beginning of pages and the number of the page in the original print publication enables direct NCX navigation to the beginning of each page as reflected in the print publication. These pages will vary in size from the screens of information displayed by a typical Reading System. The retention of print page marking will enable a user to move to the identical location as someone who may be using a printed book.
It is strongly recommended that Content Providers select this XML Preferred Vocabulary for their educational publications and for content that is highly structured.
Many publishers may already have their content in DTBook as a result of the U.S. Individuals with Disabilities Education Improvement Act (IDEIA) of 2004 or other similar international legislation. Transforming it into an OPS publication can be accomplished with ease. Having the publication available using the DTBook vocabulary may help publishers market their publications to all students in the education market place, including those with print disabilities.
Section 4 of the DAISY/NISO Standard defines the DTBook DTD. This can be found on the NISO Web site at: http://www.niso.org/standards/resources/Z39-86-2005.html.
Additional information such as DTDs, issues tracking, samples and more can be found on the DAISY Web site at: http://www.daisy.org/z3986/.
DTBook, as described in Section 4 of the DAISY/NISO Standard, must be followed in DTBook OPS Publications. The content must validate against the dtbook-2005-2.dtd, which was the latest version at the
time of this writing. This DTD version, all previous versions, and all future
versions will be available on the DaisyDAISY website. This will
ensure that OPS Publications created under any version of the DTD remain valid.
It is essential that the semantics of the DTBook elements be applied correctly. To assist with this, a set of "Structure Guidelines" has been created. Documents created conforming to DTBook should use the Structure Guidelines for information regarding the correct application of the semantics of the elements. The Structure Guidelines can be found at: http://www.daisy.org/z3986/structure/.
There is a single attribute on elements in DTBook called smilref. This attribute is used for SMIL (http://www.w3.org/TR/2005/REC-SMIL2-20050107/)
coordination. SMIL is not supported in OPS Publications. Leaving this attribute
out of DTBook documents in OPS Publications must
not will not cause validation errors.
Many images, such as maps, charts, graphs, etc., originate from vector graphics systems, not photographs. Such images can be represented in a vector (as opposed to raster) format that describes the image in terms of lines, curves and absolutely positioned blocks of text (as opposed to an array of pixels). Replacing raster images with vector ones makes documents more accessible and searchable. This additional effort on the part of Reading Systems and authors can improve accessibility significantly. Vector images also improve the visual quality of documents (since vector images are inherently scalable) and tend to decrease document sizes.
OPS Reading Systems must support SVG (Scalable Vector Graphics) as an OPS Core Media Type.
OPS supports the full SVG 1.1 Recommendation. The only exception is that since OPS is not targeting interactive content. SVG animation and scripting features are not supported and must not be used by publication authors; a Reading System should not render such content. CSS styling of SVG must be fully supported.
Text in SVG images should be selectable and searchable. SVG images may contain links (a elements) and thus may be used for navigation. If a Reading System supports "tabbing" through links, SVG links must be included.
Inline SVG is only supported within documents using the XHTML Preferred Vocabulary. It must not be used within DTBook documents.
SVG content can be used in OPS in any place where other image types can be used. This includes:
To ensure maximum portability, the dimensions of SVG images should always be specified on the top-level SVG element . As with bitmap images, referencing elements may override an SVG image’s dimensions causing it to scale.
Each SVG image is considered a separate document for the purposes of styling. Referencing document style sheets do not apply to referenced SVG images, nor are CSS properties inherited by SVG images. Common styles should be achieved by creating style sheets that are referenced by both SVG and XHTML. Note that this is consistent with situations in which an object element references an XHTML element.
The other way of using SVG is to embed SVG mark-up directly in XHTML mark-up. The SVG
root element (svg) must be
considered replaced by its content in the CSS layout, so svg elements may be used anywhere XHTML
img or object
elements could be used. Other SVG elements may only be used
as svg element descendants. Since SVG and XHTML elements
have different namespaces, care needs to be taken to assign proper namespaces to each
element using namespace prefixes or the xmlns
attribute.
In this case, there is only one document and CSS style sheets apply to the document as a whole (including cascade and inheritance). In the usual manner, each element only makes use of the properties that are applicable to it. The root svg element’s role in CSS layout is determined by the display, float and position properties, just like it works for the img element. SVG image dimensions are determined by the width and height attributes on the root svg element (which are considered to be the replaced element’s intrinsic dimensions in the CSS box layout) and the width and height properties assigned by CSS. See http://www.w3.org/TR/CSS2/conform.html for a definition of "replaced element" and "intrinsic dimensions." For portability, authors should avoid assigning XHTML-only CSS properties to SVG elements and vise-versa.
This section describes the markup and a processing model for the inclusion of generic XML content in OPS Publications.
This section defines a method of including generic XML markup in OPS Publications. The motivation is to achieve the maximum backwards, sideways, and forwards compatibility with other XML vocabularies, including Extended OEBPS, as defined in OEBPS 1.2.
This is consistent with the stated future directions of OEBPS 1.2.
To that end, this document introduces the idea of "XML Islands." Two variants exist:
Out-Of-Line XML Islands are any complete XML document that is not authored in one of the Preferred Vocabularies (i.e. DTBook or XHTML) or uses an Extended Module in an otherwise Preferred Vocabulary document.
An Inline XML Island is an XML document fragment using a non-Preferred Vocabulary or using an Extended Module of a Preferred Vocabulary that exists within an XHTML Preferred Vocabulary document within an OPS Publication. Inline XML Islands are also namespace-qualified to the OPS namespace and are not contained within object elements.
Inline XML Islands must not be used within documents using the DTBook Preferred Vocabulary; they must only be used within XHTML documents.
Following are the use cases that justify the existence of XML Islands in OPS: