Open eBook™ Publication Structure 1.2

D R A F T

April 17, 2002

This is an Open eBook Forum Working Draft for review by OeBF members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. The Publication Structure Working Group will not allow early implementation to constrain its ability to make changes to this specification prior to final release. It is inappropriate to use OeBF Working Drafts as reference material or to cite them as other than "work in progress."

Copyright © 2002 by Open eBook 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 Open eBook Forum.

TABLE OF CONTENTS

• 1  Overview
  • 1.1  Purpose and Scope
  • 1.2  Definitions
  • 1.3  Relationship to Other Specifications
    • 1.3.1  Relationship to XML
    • 1.3.2  Relationship to XML Namespaces
    • 1.3.3  Relationship to XHTML
    • 1.3.4  Relationship to CSS
    • 1.3.5  Relationship to Dublin Core
    • 1.3.6  Relationship to Unicode
    • 1.3.7  MIME Media Types
    • 1.3.8  XML Style Sheet Processing Instruction
  • 1.4  Conformance
    • 1.4.1  Document and Publication Conformance
    • 1.4.2  Reading System Conformance
    • 1.4.3  Compatibility with Future Versions
    • 1.4.4  Compatibility of Version 1.2
  • 1.5  Extensibility
  • 1.6  Accessibility
  • 1.7  Future Directions
• 2  The OEBPS Package
  • 2.1  Package Identity
  • 2.2  Publication Metadata
    • 2.2.1  <dc:Title> </dc:Title>
    • 2.2.2  <dc:Creator> </dc:Creator>
    • 2.2.3  <dc:Subject> </dc:Subject>
    • 2.2.4  <dc:Description> </dc:Description>
    • 2.2.5  <dc:Publisher> </dc:Publisher>
    • 2.2.6  <dc:Contributor> </dc:Contributor>
    • 2.2.7  <dc:Date> </dc:Date>
    • 2.2.8  <dc:Type> </dc:Type>
    • 2.2.9  <dc:Format> </dc:Format>
    • 2.2.10  <dc:Identifier> </dc:Identifier>
    • 2.2.11  <dc:Source> </dc:Source>
    • 2.2.12  <dc:Language> </dc:Language>
    • 2.2.13  <dc:Relation> </dc:Relation>
    • 2.2.14  <dc:Coverage> </dc:Coverage>
    • 2.2.15  <dc:Rights> </dc:Rights>
  • 2.3  Manifest
    • 2.3.1  Fallback items
  • 2.4  Spine
  • 2.5  Tours
  • 2.6  Guide
• 3  Basic OEBPS Document Vocabulary
  • 3.1  Introduction
  • 3.2  Basic OEBPS Document Vocabulary Components
    • 3.2.1  The Common Attributes
    • 3.2.2  Elements and Attributes of the Basic OEBPS Document Vocabulary
  • 3.3  Certain Element and Attribute Semantic Differences From, and Restrictions Beyond, XHTML 1.1
    • 3.3.1  General Comments on URI References
    • 3.3.2  body element
    • 3.3.3  cite attribute
    • 3.3.4  img element
    • 3.3.5  link element
    • 3.3.6  object and param elements
    • 3.3.7  script and noscript elements
    • 3.3.8  type attribute of the style element
    • 3.3.9  value of align attribute
  • 3.4  Rendering of Documents on Reading Systems
• 4  OEBPS Style sheets
  • 4.1  Selectors
  • 4.2  Value types
    • 4.2.1  URI values
    • 4.2.2  Integers and real numbers
    • 4.2.3  Length
    • 4.2.4  Percentages
    • 4.2.5  Color
    • 4.2.6  Time
    • 4.2.7  Frequency
    • 4.2.8  Strings
  • 4.3  Properties
• APPENDIX A: THE OEBPS PACKAGE DTD
• APPENDIX B: THE BASIC OEBPS DOCUMENT DTD
• APPENDIX C: CHARACTER ENTITIES
• APPENDIX D: Differences Between the Basic OEBPS 1.2 and 1.0.1 Document Vocabularies
  • D.1 Elements in Basic 1.0 Removed in Basic 1.2
  • D.2 Attributes in Basic 1.0 Removed in Basic 1.2
  • D.3 Deprecated Basic 1.0 Attributes Undeprecated in Basic 1.2
  • D.4 Deprecated Core Attribute style
  • D.5 New Elements (and Included Attributes) Added in Basic 1.2
  • D.6 New Basic 1.2 Attributes Added to Pre-Existing Elements
  • D.7 Miscellaneous Differences in DTD Content Models, Elements and Attributes
• APPENDIX E: CONTRIBUTORS

1 Overview

1.1 Purpose and Scope

In order for electronic-book technology to achieve widespread success in the marketplace, Reading Systems must have convenient access to a large number and variety of titles. The Open eBook Publication Structure (OEBPS) is a specification for representing the content of electronic books. Specifically:

• The specification is intended to give content providers (e.g. publishers, authors, and others who have content to be displayed) and tool providers minimal and common guidelines which ensure fidelity, accuracy, accessibility, and adequate presentation of electronic content over various electronic book platforms.
• The specification seeks to reflect established content format standards.
• The goal of this specification is to define a standard means of content description for use by purveyors of electronic books (publishers, agents, authors et al.) allowing such content to be provided to multiple Reading Systems.

1.2 Definitions

Basic OEBPS Document

An OEBPS Document that restricts itself to the markup constructs defined in this specification.

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 may be removed in future revisions.

Extended OEBPS Document

An OEBPS Document that uses markup constructs beyond those in this specification, but adheres to the extension mechanism defined herein.

OEBPS Core Media Type

A MIME media type that all Reading Systems must support.

OEBPS Document

An XML document that conforms to this specification – generally containing textual content of an OEBPS Publication.

OEBPS Package

An XML file that describes an OEBPS Publication. It identifies all other files in the publication and provides descriptive information about them.

OEBPS Publication

A collection of OEBPS Documents, an OEBPS Package file, and other files, typically in a variety of media types, including structured text and graphics, that constitutes a cohesive unit for publication.

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 OEBPS Publications and makes them available to readers. 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 Reading System need not directly accept OEBPS Publications, but all Reading Systems must do so. Reading Systems may include additional processing functions beyond the scope of this specification, such as compression, indexing, encryption, rights management, and distribution.

1.3  Relationship to Other Specifications

This specification combines subsets and applications of other specifications. Together, these facilitate the construction, organization, presentation, and unambiguous interchange of electronic documents:

1. the XML 1.0 Extensible Markup Language specification (http://www.w3.org/TR/REC-xml);
2. the XML namespace specification (http://www.w3.org/TR/REC-xml-names);
3. the XHTML 1.1 Extensible HyperText Markup Language specification (http://www.w3.org/TR/xhtml11/);
4. the CSS2 Cascading Style Sheets language (http://www.w3.org/TR/REC-CSS2);
5. the Dublin Core metadata specification (http://dublincore.org/documents/1998/09/dces/) and the USMARC relator code list (http://www.loc.gov/marc/relators/);
6. the Unicode character set (http://www.unicode.org); and
7. particular MIME media types (http://www.ietf.org/rfc/rfc2046.txt and http://www.iana.org/assignments/media-types/index.html).
8. the XML style sheet processing instruction (http://www.w3.org/TR/xml-stylesheet).

1.3.1 Relationship to XML

OEBPS 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 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 be XML processors as defined in XML 1.0. All OEBPS Documents must be well-formed XML documents, although they need not be valid XML documents.

XML well-formedness requires characteristics beyond what HTML browsers typically require, such as:

• Elements must be bounded by both start- and end-tags;
• Elements must nest properly, with no overlaps;
• Attribute values must be quoted;
• Attribute assignments must use the non-minimized form (unlike some “border” usages);
• All “<” and “&” characters intended as content must be escaped as “&lt;” and “&amp;” or represented by their equivalent Unicode numerical character references;
• All element names and attribute names must be consistent in case (all OEBPS 1.2 names are, as in XHTML 1.1, lower-case); and
• All empty elements must use the XML empty element syntax (this specification also strongly encourages whitespace before the trailing slash, although such space is optional in XML; for example, “<br />”).

Empty elements (such as the HTML br and hr elements) are those that permit no content. The XML and formal HTML syntaxes for these are incompatible, though the XML form, with whitespace before the trailing slash, is accepted by most HTML browsers. The addition of this whitespace remains strictly conformant XML, as XML ignores whitespace within tags. Hence, this specification strongly encourages, though does not require, this conforming variation of the XML form (for example, “<br />”). This is the most portable syntax and it contributes to document longevity, even though, strictly speaking, it is not valid in HTML.

Syntactic transformation from valid HTML to well-formed XML is trivial (though semantic transformations that also add brand-new structure and information value may not be). Transformation from invalid but moderately clean HTML is also usually an easy process and easily automated: several free tools already exist for this, such as “Tidy” (see http://www.w3.org/People/Raggett/tidy/). Transformation from extremely dirty HTML to XML, however, is of unpredictable complexity.

Not all well-formed XML 1.0 documents are conformant OEBPS Documents. This specification imposes further constraints in order to improve interoperability. These constraints are the “OEBPS Common Requirements,” defined below.

This specification contains two XML DTDs – the OEBPS Package DTD (Appendix A) and the Basic OEBPS Document DTD (Appendix B). The OEBPS Package file (which, beyond well-formed, must be valid XML) provides the “framework” for a complete publication, and Reading Systems should use it to find and organize publication components. The Basic OEBPS Document DTD formally defines the XHTML 1.1 subset described in this specification.

This specification ensures that for any Basic OEBPS Document, there is a syntax form that:

• is a valid XML document,
• conforms to the OEBPS Document DTD,
• conforms to the XHTML 1.1 specification, and
• is effectively previewable in typical HTML browsers.

1.3.2 Relationship to XML Namespaces

This version of the specification does not require, but does allow, Reading Systems to process XML namespaces according to the XML Namespaces Recommendation at http://www.w3.org/TR/REC-xml-names.

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.

OEBPS Documents must not contain declarations of default namespaces that reference namespaces other than the XHTML namespace (“http://www.w3.org/1999/xhtml”). Conversely, any declarations of prefixed namespaces within OEBPS Documents must not reference the XHTML namespace.

If a Reading System is not namespace-aware, any element within an OEBPS Document that contains a namespace prefix is treated as an Extended OEBPS Document element, with the colon acting as a normal XML Name character, afforded no special meaning.

The use of the dc: prefix, however, is required for Dublin Core metadata element attributes in the OEBPS Package file. For upwards compatibility, the element dc-metadata in an OEBPS Package file is required to have an attribute of xmlns:dc="http://purl.org/dc/elements/1.0/" and xmlns:oebpackage="http://openebook.org/namespaces/oeb-package/1.2/". In addition, the Dublin Core elements are declared in the OEBPS Package DTD with an explicit prefix of dc:.

1.3.3 Relationship to XHTML

This specification recognizes the importance of current software tools, legacy data, publication practices, and market conditions, and has therefore based the Basic OEBPS Document vocabulary on XHTML 1.1. This approach allows content providers to exploit current XHTML 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 Basic OEBPS Document element set does not include all XHTML 1.1 elements and attributes. The elements and attributes were selected from the XHML 1.1 specification and 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.

To achieve predictable results, for greater document interoperability, and to support upwards compatibility with future versions of this specification, it is strongly recommended that Basic OEBPS Documents be valid XML documents with respect to the Basic OEBPS Document DTD.

1.3.4 Relationship to CSS

This specification defines a style language based on CSS 2, with a media type of “text/x-oeb1-css”. The Publication Structure Working Group is aware that this definition of a media type goes against the recommendation of the CSS Working Group, but has chosen to do so due to practical considerations.

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.

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 OEBPS. In such cases, the CSS settings are allowed, and keep their meanings; but a conforming Reading System may gracefully degrade to a simpler rendering.

This specification supports the style attribute (though deprecated), the style element, and externally linked style sheets. Reading Systems need not perform XML-namespace handling while processing style sheets.

Style sheets may be associated with an OEBPS Document in several ways:

1. by style attributes on specific XHTML elements (deprecated);
2. by style elements within the XHTML header;
3. by an external style sheet identified on a link elements in the XHTML head; and/or
4. by an external style sheet identified via the processing instruction xml-stylesheet (see Section 1.3.8).

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.

Styles attached via the first two methods listed above must use only those CSS constructs defined in Section 4 of this specification. External style sheets linked via the XHTML link element or by the processing instruction xml-stylesheet, however, may use this or any other style language, such as XSL (see http://www.w3.org/TR/xsl).

Style sheets of type “text/x-oeb1-css” must employ only those CSS constructs defined as supported in Section 4 of this specification. Style sheets of other MIME media types may be substituted for the text/x-oeb1-css style sheets at the discretion of the Reading System.

The XHTML 1.1 specification groups externally linked style sheets into sets by their titles (including a “persistent” set for which the title is the null string). This specification requires that at least one style sheet in each such set must be of MIME media type “text/x-oeb1-css”.

Reading Systems that implement only the OEBPS CSS 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 novel style sheet languages supported, and that style sheets in those languages be detected by examining the MIME media type.

1.3.5 Relationship to Dublin Core

The Dublin Core is designed to minimize the cataloging burden on authors and publishers, while providing enough metadata to be useful. This specification supports the set of Dublin Core 1.0 metadata elements (http://dublincore.org/documents/1998/09/dces/), supplemented with a small set of additional attributes addressing areas where more specific information may be useful. For example, the role attribute added to the dc:Contributor element allows for much more detailed specification of contributors to a publication, including their roles expressed via relator codes.

Content providers must include a minimum set of a metadata elements, defined in section 2.2, and should incorporate additional metadata to enable readers to discover publications of interest.

1.3.6 Relationship to Unicode

Publications may use the entire Unicode character set, in UTF-8 or UTF-16 encodings, as defined by Unicode (see http://www.unicode.org/). 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. They 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).

1.3.7 MIME Media Types

This specification defines a list of OEBPS Core Media Types that all Reading Systems must support (as required by this specification) and publications may include. Publications may include resources of other media types, but for each such resource must include an alternative resource of an OEBPS Core Media Type (using methods defined in this specification).

The OEBPS Core Media Types are:

1.3.8 XML Style Sheet Processing Instruction

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). In this specification, the allowed pseudo-attributes for xml-stylesheet are those corresponding to the allowed attributes for XHTML link when used to identify an external style sheet. This processing instruction is placed in the prolog of the XML document. It can appear multiple times as link can.

1.4 Conformance

This section defines conformance for OEBPS Documents, Publications, and Reading Systems.

1.4.1 Document and Publication Conformance

This specification defines two named levels of conformance for OEBPS Documents—Basic and Extended, and one conformance level for OEBPS Publications.

1.4.1.1 OEBPS Common Requirements

Each conformant OEBPS Document (whether Basic or Extended) and each conformant OEBPS Package File must meet these necessary conditions, referred to in this specification as the “Common Requirements:”

1. it is a well-formed XML document (as defined in XML 1.0);
2. it begins with a correct XML declaration (e.g. <?xml version='1.0'?>);
3. it is encoded in UTF-8 or UTF-16;
4. it does not include an XML internal declaration subset; and
5. any attribute with a type of NMTOKEN, ID, or IDREF must be an XML Name.

1.4.1.2 OEBPS Common Document Requirements

A conformant OEBPS Document (whether Basic or Extended) must meet these necessary conditions, referred to in this specification as the “common document requirements:”

1. it meets the OEBPS Common Requirements;
2. it does not contain declarations of default namespaces referencing other than the XHTML namespace (“http://www.w3.org/1999/xhtml”);
3. any declarations of prefixed namespaces do not reference the XHTML namespace (“http://www.w3.org/1999/xhtml”);
4. if external style sheets are used, then at least one style sheet in each title set (as described in the XHTML 1.1 specification), including any “persistent” set, must be of MIME media type “text/x-oeb1-css”; and
5. all style parameters specified within the document itself belong to the OEBPS CSS subset.

1.4.1.3 Basic OEBPS Document

A document is a Basic OEBPS Document if and only if:

1. it meets the OEBPS Common Document Requirements;
2. its DOCTYPE declaration, if any, references the Basic OEBPS 1.2 Document DTD;
3. it uses only the element names, attribute names, and attribute values drawn from the Basic OEBPS Document Vocabulary with all element and attribute names in lower case; and
4. it uses element names, attribute names, and attribute values in a manner broadly consistent with the intentions of the relevant descriptions in this specification and those of XHTML and the Dublin Core, with this specification taking precedence in the event of conflicts.

1.4.1.4 Extended OEBPS Document

A document is an Extended OEBPS Document if and only if

1. it meets the OEBPS Common Document Requirements;
2. it uses elements, attributes, or attribute values not drawn from the Basic OEBPS Document Vocabulary, or its DOCTYPE declaration references a DTD other than the Basic OEBPS 1.2 Document DTD; and
3. for any element not of the Basic OEBPS Document vocabulary it provides an applicable style rule using only the OEBPS CSS subset.

1.4.1.5 Validity

OEBPS Documents, Basic or Extended, may or may not be valid (as defined in XML 1.0) with respect to an associated DTD. However, all OEBPS Documents must be well-formed XML 1.0 documents.

1.4.1.6 Publication Conformance

A collection of files is a conforming OEBPS Publication if and only if

1. it includes a single OEBPS Package file that obeys the OEBPS Common Requirements listed above, and is a valid XML document conforming to the OEBPS Package DTD;
2. the OEBPS Package file includes one and only one manifest entry corresponding to each other file in the OEBPS Publication;
3. the manifest entry for each file in the publication specifies a MIME media type for the file (see http://www.ietf.org/rfc/rfc2046.txt);
4. each file whose manifest entry identifies it as being in one of the OEBPS Core Media Types, conforms as defined for those MIME media types;
5. the dc-metadata element contains at least one dc:Identifier element, at least one dc:Title element, and at least one dc:Language element;
6. the unique-identifier attribute of the package element is a correct XML IDREF to a dc:Identifier element;
7. any extended values specified for the dc:Contributor element's role attribute begin with “oth.”; and
8. any extended values specified for the guide element's type attribute begin with “other.”.

1.4.2 Reading System Conformance

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:

1. When presented with a Basic OEBPS Document the Reading System
   1. correctly processes XML as required in the XML 1.0 specification, including that specification's requirements for the handling of well-formedness errors;
   2. recognizes all markup described as permitted in this specification and processes it consistently with the corresponding explanation(s) in this specification and in those of XHTML 1.1 and CSS 2 (in case of any conflict, this specification takes precedence); and
   3. does not render objects of unsupported media types, in the absence of fallbacks. These fallbacks are clearly defined in section 2.3.1.
2. When presented with an Extended OEBPS Document the Reading System
   1. performs as required in A.i, A.ii, and A.iii;
   2. recognizes element instances not from this specification and renders them according to any applicable style sheet rules, as described in section 1.4.4; and
   3. continues processing, displaying the element inline, as if “display: inline” applied, for any element not dealt with by (i) and (ii);
3. When presented with an OEBPS Package file the Reading System
   1. processes all elements and attributes as described in section 2 of this specification.
4. When providing navigation via the OEBPS spine, the Reading System
   1. does not render content that does not have the media type text/x-oeb1-document; and
5. When presented with one or more style sheets via the XHTML link mechanism or the xml-stylesheet processing instruction, described in Section 1.3.8, the Reading System:
   1. processes the document in accordance with the text/x-oeb1-css style sheets; and
   2. if style sheets of a MIME media type other than text/x-oeb1-css are provided, may substitute those style sheets for the text/x-oeb1-css style sheets. Reading Systems (although not necessarily Reading Devices) which support other style sheet media types must provide a mechanism for requesting that those style sheets be ignored in favor of the text/x-oeb1-css style sheets.
6. When presented with an OEBPS 1.0 Document or Package file, the Reading System must process them as a conformant OEBPS 1.0 Reading System would.

Note: Reading Systems are not required to support XML entity and attribute declarations (beyond parsing past them as XML requires), because such constructs are not permitted in conforming OEBPS Documents.

1.4.3 Compatibility with Future Versions

It is the intent of the contributors to this specification that subsequent generations of this specification continue in the directions established by the 1.0 release. Specifically:

• Content format standards will be compatible with W3C (and IETF) standards;
• Future versions of this specification are expected to improve alignment with XML-based specifications, relaxing the constraints on OEBPS 1.2 Documents that are more restrictive than XML, requiring further XML processing capability of OEBPS-conformant Reading Systems, and perhaps supporting other XML-related standards such as XLink; and
• Any required functionality not present in relevant official standards shall be defined in a manner consistent with its eventual submission to an appropriate standards body as extensions to existing standards.

1.4.4 Compatibility of Version 1.2

Version 1.2 of the OEBPS Publication Structure is not meant to be a substantially “new” specification. However, version 1.2 does add functional enhancements over 1.0.1, largely supporting the goal of allowing enhanced control over content presentational fidelity. Specifically, the following are the most substantive additions:

• The Basic OEBPS Document element set has been expanded.
• All previously deprecated elements have been removed; it is now a true subset of XHTML 1.1.
• The OEBPS CSS subset has been augmented with numerous CSS2 properties and values.
• Most previously deprecated attributes have been removed.
• The OEBPS CSS subset has been augmented with a more extensive set of selectors.

It was a goal of version 1.2 that all documents conformant according to version 1.0.1 would remain conformant under 1.2. However, removal of elements deprecated in 1.0.1 (e.g. font) and the addition of namespace requirements (see Section 1.3.3) rendered full compatibility with version 1.0.1 impossible.

1.5 Extensibility

Use of Extended OEBPS Documents is the recommended mechanism for adding information and structure beyond that provided by the XHTML subset defined in this specification (e.g. to associate further semantics with content). Arbitrary non-OEBPS elements may be added as long as such elements are provided with style definitions in accompanying style sheets.

For example, the following document would be an Extended OEBPS Document excerpt:

<chapter>
<milestone n="257" />
<chapterhead>Chapter one</chapterhead>
<p>Now is the time… </p>
</chapter>

if associated with a style sheet containing the following excerpt:

chapter   {page-break-before: always; display: block}
milestone   {display: none}
chapterhead   {
   font-weight: bold;
   font-family: sans-serif;
   text-align: center;
   display: block;
   margin-top: 4ex
}

1.6 Accessibility

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 the OEBPS specification.

OEBPS Publications should be authored in accordance with the W3C Web Content Accessibility Guidelines 1.0 (http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/) to ensure that the broadest possible set of users will have access to books delivered in this 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/) should be reviewed and applied by OEBPS implementers to ensure that Reading Systems will be in conformance with accessibility requirements.

1.7 Future Directions

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 the OEBPS Publication Structure are: standards compliance (e.g. full namespace support), metadata modularization, enhanced support for linking and navigation, and better support for international content. Other themes deemed important for future versions include: more rigorous separation of content and presentation, greater accessibility, Reading Device-specific presentation control and/or Reading Device profiles, application-specific markup (e.g. math, chemical), Publication container file format, 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 is a high priority. Future directions can be tracked at http://www.openebook.org.

Metadata support for OEBPS content is currently under development in other working groups within the OEBF; the Dublin Core constructs included in the OEBPS 1.2 Package File are only intended to provide a minimal level of metadata support while the work of those groups is being completed, as well as to maintain compatibility with 1.0.1.

2 The OEBPS Package

A publication conforming to this specification must include exactly one OEBPS Package file, which specifies the OEBPS Documents, images, and other objects that make up the OEBPS Publication and how they relate to each other.

The package file should be named using the extension “.opf”, in order to make it readily identifiable within the group of files making up the publication. Package files are of MIME media type “text/xml”. This specification does not define means for physically bundling files together to make one data transfer object (such as using zip or tar).

It is not required that the OEBPS Package DTD be physically included in every publication. If included, it should be referenced from the manifest (as described below for other files).

The major parts of the OEBPS Package file are:

Package Identity

A unique identifier for the OEBPS Publication as a whole.

Metadata

Publication metadata (title, author, publisher, etc.).

Manifest

A list of files (documents, images, style sheets, etc.) that make up the publication. The manifest also includes fallback declarations for files of types not supported by this specification.

Spine

An arrangement of documents providing a linear reading order.

Tours

A set of alternate reading sequences through the publication, such as selective views for various reading purposes, reader expertise levels, etc.

Guide

A set of references to fundamental structural features of the publication, such as table of contents, foreword, bibliography, etc.

An OEBPS Package must be a valid XML document conforming to the OEBPS Package DTD (Appendix A). Appendix C includes the mnemonic character entities file associated with the OEBPS Pacakge DTD. An informal outline of the package is as follows:

<?xml version="1.0"?>
<!DOCTYPE package 
  PUBLIC "+//ISBN 0-9673008-1-9//DTD OEB 1.2 Package//EN"
  "http://openebook.org/dtds/oeb-1.2/oebpkg12.dtd">
<package>
   metadata
   manifest
   spine
   guide
</package>

The following sections describe the parts of the OEBPS Package.

2.1 Package Identity

The package element is the root element in a package file; all other elements are nested within it.

The package must specify a value for its unique-identifier attribute. The unique-identifier attribute's value specifies which dc:Identifier element, described in section 2.2.10, provides the package's preferred, or primary, identifier. The package file's author is responsible for choosing a primary identifier that is unique to one and only one particular package (i.e., the set of files referenced from the package file's manifest).

Notwithstanding the requirement for uniqueness, Reading Systems must not fail catastrophically should they encounter two distinct packages with the same purportedly unique primary identifier.

2.2 Publication Metadata

The required metadata element is used to provide information about the publication as a whole. It contains a Dublin Core metadata record within a dc-metadata element, and supplemental metadata in an x-metadata element.

The required dc-metadata element contains specific publication-level metadata as defined by the Dublin Core initiative (http://dublincore.org/). The descriptions below are included for convenience, and the Dublin Core's own definitions take precedence (see http://dublincore.org/documents/1998/09/dces/).

The optional x-metadata element, if present, must contain one or more instances of a meta element, analogous to the XHTML 1.1 meta element, but applicable to the publication as a whole. The x-metadata element allows content providers to express arbitrary metadata beyond the data described by the Dublin Core specification. Individual OEBPS Documents may include the meta element directly (as in XHTML 1.1) for document-specific metadata. This specification uses the OEBPS Package file alone as the basis for expressing publication-level Dublin Core metadata.

For example:

<metadata>
   <dc-metadata
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:oebpackage="http://openebook.org/namespaces/oeb-package/1.2/">
     …
   </dc-metadata>
   <x-metadata>
     <meta name="price" content="USD 19.99" />
   </x-metadata>
</metadata>

The XML namespace mechanism (see http://www.w3.org/TR/REC-xml-names/) is used to identify the elements used for Dublin Core metadata without conflict. Note that there is no requirement on Reading Systems to process namespaces. This syntax is used to provide for upwards-compatibility.

The dc-metadata element can contain any number of instances of any Dublin Core elements. Dublin Core element names begin with the “dc:” prefix followed by a leading uppercase letter. Dublin Core metadata elements may occur in any order; in fact, multiple instances of the same element type (multiple dc:Creator elements, for example) can be interspersed with other metadata elements without change of meaning.

For upwards-compatibility, the element dc-metadata in an OEBPS Package must have an attribute of xmlns:dc="http://purl.org/dc/elements/1.0/" and xmlns:oebpackage="http://openebook.org/namespaces/oeb-package/1.2/".

Each Dublin Core field is represented by an element whose content is the field's value. At least one of each of dc:Title, dc:Identifier and dc:Language must be included in the dc-metadata element. Dublin Core elements, like any other elements in the OEBPS Package file, may have an id attribute specified. At least one dc:Identifier, that which is referenced from the package unique-identifier attribute, must have an id specified.

Because the Dublin Core metadata fields for Creator and Contributor do not distinguish roles of specific contributors (such as author, editor, and illustrator), this specification adds an optional role attribute for this purpose. See section 2.2.6 for a discussion of role.

This specification also adds a scheme attribute to the dc:Identifier element to provide a structural mechanism to separate an identifier value from the system or authority that generated or defined that identifier value. See section 2.2.10 for a discussion of scheme.

This specification also adds an event attribute to the dc:Date element to enable content providers to distinguish various publication specific dates (for example, creation, publication, modification). See section 2.2.7 for a discussion of event.

For example:

<package unique-identifier="xyz">
   <metadata>
      <dc-metadata xmlns:dc="http://purl.org/dc/elements/1.0/" xmlns:oebpackage="http://openebook.org/namespaces/oeb-package/1.2/">
         <dc:Title>Alice in Wonderland</dc:Title>
         <dc:Type>Novel</dc:Type>
         <dc:Identifier id="xyz"
         scheme="ISBN">123456789X</dc:Identifier>
         <dc:Creator role="aut">Lewis Carroll</dc:Creator>
      </dc-metadata>
   </metadata>
   ...
</package>

There are no attributes for the elements within dc-metadata defined by Dublin Core – only the elements' contents are so defined.

The following subsections describe the individual Dublin Core metadata elements.

2.2.1 <dc:Title> </dc:Title>

The title of the publication. An OEBPS Package must include at least one instance of this element type, however multiple instances are permitted. Any Reading System that displays title metadata to the user should either use the first dc:Title only, or all dc:Title elements.

2.2.2 <dc:Creator> </dc:Creator>

A primary creator or author of the publication. Additional contributors whose contributions are secondary to those listed in dc:Creator elements should be named in dc:Contributor elements.

Publications with multiple co-authors should provide multiple dc:Creator elements, each containing one author. The order of dc:Creator elements is presumed to define the order in which the creators' names should be presented by the Reading System.

This specification recommends that the content of the dc:Creator elements hold the text for a single name as it would be presented to the user.

The dc:Creator element has two optional attributes, role and file-as. The set of values for role are identical to those defined in section 2.2.6 for the dc:Contributor element. The file-as attribute should be used to specify a normalized form of the contents, suitable for machine processing. For example, one might find

<dc:Creator file-as="King, Martin Luther Jr." role="aut">
   Rev. Dr. Martin Luther King Jr.
</dc:Creator>

If a Reading System displays creator information, the Reading Systems must display the contents of all dc:Creator elements, in the order provided, with appropriate separating spacing and/or punctuation.

2.2.3 <dc:Subject> </dc:Subject>

Multiple instances of the dc:Subject element are supported, each including an arbitrary phrase or keyword. This specification makes no attempt to standardize subject naming schemes, such as the Library of Congress Subject Heading System.

2.2.4 <dc:Description> </dc:Description>

Plain text describing the publication's content.

2.2.5 <dc:Publisher> </dc:Publisher>

The publisher as defined in RFC2413 (http://www.ietf.org/rfc/rfc2413.txt).

2.2.6 <dc:Contributor> </dc:Contributor>

A party whose contribution to the publication is secondary to those named in dc:Creator elements.

Other than significance of contribution, the semantics of this element are identical to those of dc:Creator. Reading Systems are free to choose to display dc:Creator information without accompanying dc:Contributor information.

The dc:Contributor element has two optional attributes, role and file-as. The file-as attribute is defined as for dc:Creator, and is documented in section 2.2.2.

The normative list of values used for the role attribute is defined by the USMARC relator code list (http://www.loc.gov/marc/relators/). When roles are specified, the 3-character USMARC values must be used when applicable. Although that list is extensive, other values may be added if a required role is not covered by those predefined values. Such values must begin with “oth.”, and shall be considered subdivisions of the “other” relator code. Like other constructs in this specification, these values are case-sensitive and must be coded entirely in lower-case.

For convenience, some relator code values are listed here as examples. Consult the USMARC code list cited above for the complete list.

Adapter [adp]   Use for a person who 1) reworks a musical composition, usually for a different medium, or 2) rewrites novels or stories for motion pictures or other audiovisual medium.

Annotator [ann]   Use for a person who writes manuscript annotations on a printed item.

Arranger [arr]   Use for a person who transcribes a musical composition, usually for a different medium from that of the original; in an arrangement the musical substance remains essentially unchanged.

Artist [art]   Use for a person (e.g., a painter) who conceives, and perhaps also implements, an original graphic design or work of art, if specific codes (e.g., [egr], [etr]) are not desired. For book illustrators, prefer Illustrator [ill].

Associated name [asn]   Use as a general relator for a name associated with or found in an item or collection, or which cannot be determined to be that of a Former owner [fmo] or other designated relator indicative of provenance.

Author [aut]   Use for a person or corporate body chiefly responsible for the intellectual or artistic content of a work. This term may also be used when more than one person or body bears such responsibility.

Author in quotations or text extracts [aqt]   Use for a person whose work is largely quoted or extracted in a works to which he or she did not contribute directly. Such quotations are found particularly in exhibition catalogs, collections of photographs, etc.

Author of afterword, colophon, etc. [aft]   Use for a person or corporate body responsible for an afterword, postface, colophon, etc. but who is not the chief author of a work.

Author of introduction, etc. [aui]   Use for a person or corporate body responsible for an introduction, preface, foreword, or other critical matter, but who is not the chief author.

Bibliographic antecedent [ant]   Use for the author responsible for a work upon which the work represented by the catalog record is based. This may be appropriate for adaptations, sequels, continuations, indexes, etc.

Book producer [bkp]   Use for the person or firm responsible for the production of books and other print media, if specific codes (e.g., [bkd], [egr], [tyd], [prt]) are not desired.

Collaborator [clb]   Use for a person or corporate body that takes a limited part in the elaboration of a work of another author or that brings complements (e.g., appendices, notes) to the work of another author.

Commentator [cmm]   Use for a person who provides interpretation, analysis, or a discussion of the subject matter on a recording, motion picture, or other audiovisual medium.

Compiler [com]   Use for a person who produces a work or publication by selecting and putting together material from the works of various persons or bodies.

Designer [dsr]   Use for a person or organization responsible for design if specific codes (e.g., [bkd], [tyd]) are not desired.

Editor [edt]   Use for a person who prepares for publication a work not primarily his/her own, such as by elucidating text, adding introductory or other critical matter, or technically directing an editorial staff.

Illustrator [ill]   Use for the person who conceives, and perhaps also implements, a design or illustration, usually to accompany a written text.

Lyricist [lyr]   Use for the writer of the text of a song.

Metadata contact [mdc]   Use for the person or organization primarily responsible for compiling and maintaining the original description of a metadata set (e.g., geospatial metadata set).

Musician [mus]   Use for the person who performs music or contributes to the musical content of a work when it is not possible or desirable to identify the function more precisely.

Narrator [nrt]   Use for the speaker who relates the particulars of an act, occurrence, or course of events.

Other [oth]   Use for relator codes from other lists which have no equivalent in the USMARC list or for terms which have not been assigned a code.

Photographer [pht]   Use for the person or organization responsible for taking photographs, whether they are used in their original form or as reproductions.

Printer [prt]   Use for the person or organization who prints texts, whether from type or plates.

Redactor [red]   Use for a person who writes or develops the framework for an item without being intellectually responsible for its content.

Reviewer [rev]   Use for a person or corporate body responsible for the review of book, motion picture, performance, etc.

Sponsor [spn]      Use for the person or agency that issued a contract, or under whose auspices a work has been written, printed, published, etc.

Thesis advisor [ths]   Use for the person under whose supervision a degree candidate develops and presents a thesis, memoir, or text of a dissertation.

Transcriber [trc]      Use for a person who prepares a handwritten or typewritten copy from original material, including from dictated or orally recorded material.

Translator [trl]   Use for a person who renders a text from one language into another, or from an older form of a language into the modern form.

2.2.7 <dc:Date> </dc:Date>

Date of publication, in the format defined by “Date and Time Formats” at http://www.w3.org/TR/NOTE-datetime and by ISO 8601 on which it is based. In particular, dates without times are represented in the form YYYY[-MM[-DD]]: a mandatory 4-digit year, an optional 2-digit month, and if the month is given, an optional 2-digit day of month.

The dc:Date element has one optional attribute, event. The set of values for event are not defined by this specification; possible values may include: creation, publication, and modification.

2.2.8 <dc:Type> </dc:Type>

Dublin Core provides examples of resource types “such as home page, novel, poem, working paper, technical report, essay, dictionary.” Best practice is to use a value from a controlled vocabulary.

2.2.9 <dc:Format> </dc:Format>

The media type or dimensions of the resource. Best practice is to use a value from a controlled vocabulary (e.g. MIME media types).

2.2.10 <dc:Identifier> </dc:Identifier>

A string or number used to uniquely identify the resource. An OEBPS Package must include at least one instance of this element type, however multiple instances are permitted.

At least one dc:Identifier must have an id specified, so it can be referenced from the package unique-identifier attribute described in Section 2.1.

The dc:Identifier element has an optional attribute, scheme. The scheme attribute names the system or authority that generated or assigned the text contained within the dc:Identifier element, for example “ISBN” or “DOI.” The values of the scheme attribute are case sensitive.

This specification does not standardize or endorse any particular publication identifier scheme. Specific use of URLs or ISBNs is not yet addressed by this specification. Identifier schemes are not currently defined by Dublin Core.

2.2.11 <dc:Source> </dc:Source>

Information regarding a prior resource from which the publication was derived; see RFC 2413 (http://www.ietf.org/rfc/rfc2413.txt).

2.2.12 <dc:Language> </dc:Language>

Identifies a language of the intellectual content of the Publication. An OEBPS Package must include at least one instance of this element type, however multiple instances are permitted. The content of this element must comply with RFC 3066 (see http://www.ietf.org/rfc/rfc3066.txt), or its successor on the IETF Standards Track. The Dublin Core permits other descriptions as well; this specification does not.

2.2.13 <dc:Relation> </dc:Relation>

An identifier of an auxiliary resource and its relationship to the publication. An enumerated list of relationship types is currently under development by the Dublin Core.

2.2.14 <dc:Coverage> </dc:Coverage>

The place and/or time that the publication's content addresses.

2.2.15 <dc:Rights> </dc:Rights>

A statement about rights, or a reference to one. In this specification, the copyright notice and any further rights description should appear directly.

This specification does not address the manner in which a Content Provider specifies to a secure distributor any licensing terms under which readership rights or copies of the content may be sold.

2.3 Manifest

The required manifest provides a list of all the files that are parts of the publication. The manifest element must contain one or more item elements. Each item describes a document, an image file, a style sheet, or other component that is considered part of the publication.

Each item element contained within a manifest element must have the attributes id, href (a URI; if relative, the URI is interpreted as relative to the package file itself), and media-type (specifying the item's MIME media type).

The order of item elements in the manifest is not significant.

For example,

<manifest>
   <item id="intro" href="introduction.html" 
      media-type="text/x-oeb1-document" />
   <item id="c1" href="chapter-1.html" 
      media-type="text/x-oeb1-document" />
   <item id="c2" href="chapter-2.html" 
      media-type="text/x-oeb1-document" />
   <item id="toc" href="contents.xml" 
      media-type="text/x-oeb1-document" />
   <item id="oview" href="arch.png" 
      media-type="image/png" />
</manifest>

The URIs in href attributes of item elements in the manifest must not use fragment identifiers.

2.3.1 Fallback items

This specification defines a set of OEBPS Core Media Types that all conforming Reading Systems must support (as required by this specification). For a publication that uses only those media types, the manifest merely lists the publication's component files directly. However, content providers may construct publications that reference items of additional media types. In order for such publications to be read by all conforming Reading Systems, content providers must provide alternative “fallback” items for each such item. For every item that is not an OEBPS Core Media Type, at least one of its associated fallback items must be of a type drawn from the set of OEBPS Core Media Types.

This specification defines three different mechanisms for specifying OEBPS Core Media Type fallbacks. First, for inline “replaced” resources referenced via the object element, this specification relies on that element's inherent replacement capabilities, described in section 3.3.6. Second, for non-inline destinations, whether referenced from a document or a package, and for inline “replaced” resources referenced via the img element (described in section 3.3.4), the fallback attribute of the item is used. Third, for inline “replaced” resources referenced via the img element, the text value of the alt attribute provides a valid fallback.

An item identifies a fallback item using its fallback attribute, which must specify the ID of the item element that identifies the fallback. Items referenced from fallback attributes may each specify a fallback attribute in turn, forming a longer “fallback path.” For example,

<manifest>
   <item id="item1"
      href="FunDoc.txt"
      media-type="text/plain"
      fallback="fall1" />
   <item id="fall1" fallback="fall2"
      href="FunDoc.html"
      media-type="text/html" />
   <item id="fall2"
      href="FunDoc.oeb"
      media-type="text/x-oeb1-document" />
   <item ...>
</manifest>

If a fallback attribute points to an item that also has a fallback attribute, a Reading System must continue down the fallback path until it reaches a reference to an item of a media type it can display. A Reading System may continue further, and may display any item from the chain. In the absence of element-specific (i.e. img and object) fallback information, every item in a publication that is not of one of the OEBPS Core Media Types must, directly or indirectly, specify a fallback path to an item of one of the OEBPS Core Media Types.

Fallback paths must terminate; circular references are not permitted. Nevertheless, Reading Systems should not fail catastrophically if they encounter such a loop.

2.4 Spine

Following the manifest, there must be one spine element, which defines a primary linear reading order of the publication. It specifies an ordered list of one or more OEBPS Documents drawn from the manifest, using itemref elements contained within the spine element.

A publication must specify exactly one spine. Reading Systems must treat the file named in the first itemref element within the spine as the first file to be rendered in the reading of the book. The successive files named in its itemref elements are those that are to be rendered using “next-page”-type functionality that may be available in the Reading System.

The spine must refer only to item elements of media type text/x-oeb1-document. Content of other media types may be referenced via OEBPS Documents, which should provide text alternates and other information to enhance accessibility as appropriate.

The spine need not include references to every one of the manifest's item elements that reference OEBPS Documents, because there are means other than the spine for accessing documents in the publication. For example, hypertext links may provide access to documents not in the spine, as may tours and guides (see below).

For example,

<manifest>
   <item id="toc"
      href="contents.html"
      media-type="text/x-oeb1-document" />
   <item id="c1"
      href="chap1.html"
      media-type="text/x-oeb1-document" />
   <item id="c2"
      href="chap2.html"
      media-type="text/x-oeb1-document" />
   <item id="c3"
      href="chap3.html"
      media-type="text/x-oeb1-document" />
   <item id="footnotes"
      href="footnotes.html"
      media-type="text/x-oeb1-document" />
   <item id="f1" href="fig1.jpg" media-type="image/jpeg" /> 
   <item id="f2" href="fig2.jpg" media-type="image/jpeg" /> 
   <item id="f3" href="fig3.jpg" media-type="image/jpeg" />
</manifest>

<spine>
   <itemref idref="toc" />
   <itemref idref="c1" />
   <itemref idref="c2" />
   <itemref idref="c3" />
</spine>

In the above example, suppose the document referenced by ID “c1” is being viewed by a reader. When the end of that document is reached, the next document in linear order would be that referenced by ID “c2”. Document “c1” might also have hypertext links to locations in another file such as the “footnotes”. Such a file must be listed in the manifest, but need not be named by any itemref of the spine. If a reader follows the hyperlink in “c1” to “footnotes”, and the end of that file is reached, then no successor in linear order is defined by this specification.

2.5 Tours

Much as a tour-guide might assemble points of interest into a set of sightseers' tours, a content provider may assemble selected parts of a publication into a set of tours to enable convenient navigation.

An OEBPS Package may, but need not, contain one tours element, which in turn contains one or more tour elements. Each tour must have a title attribute, intended for presentation to the user. Reading Systems may use tours to provide various access sequences to parts of the publication, such as selective views for various reading purposes, reader expertise levels, etc. Because Reading Systems are not required to implement tour support, content providers should also provide other means of accessing content referenced from tours.

Each tour element contains one or more site elements, each of which must have an href attribute and a title attribute. The href attribute must refer to an OEBPS Document included in the manifest, and may include a fragment identifier as defined in section 4.1 of RFC 2396 (see http://www.ietf.org/rfc/rfc2396.txt). Each site element specifies a starting point from which the reader may explore freely. Reading Systems may use the bounds of the referenced element to determine the scope of the site. If a fragment identifier is not used, the scope is considered to be the entire document. This specification does not require Reading Systems to mark or otherwise identify the entire scope of a referenced element. The order of site elements is presumed to be significant, and should be used by Reading Systems to aid navigation.

Example:

<tours>
   <tour id="tour1" title="Chicken Recipes">
      <site title="Chicken Fingers" 
             href="appetizers.html#r3" />
      <site title="Chicken a la King" 
             href="entrees.html#r5" />
   </tour>
   <tour id="tour2" title="Vegan Recipes">
      <site title="Hummus" href ="appetizer.html#r6" />
      <site title="Lentil Casserole" href="lentils.html" />
   </tour>
</tours>

2.6 Guide

Within the package there may be one guide element, containing one or more reference elements. The guide element identifies fundamental structural components of the publication, to enable Reading Systems to provide convenient access to them.

Example:

<guide>
   <reference type="toc" title="Table of Contents" 
       href="toc.html" />
   <reference type="loi" title="List Of Illustrations" 
       href="toc.html#figures" />
   <reference type="other.intro" title="Introduction" 
       href="intro.html" />
</guide>

The structural components of the books are listed in reference elements contained within the guide element. These components may refer to the table of contents, list of illustrations, foreword, bibliography, and many other standard parts of the book. Reading Systems are not required to use the guide element in any way.

Each reference must have an href attribute referring to an OEBPS Document included in the manifest, and which may include a fragment identifier as defined in section 4.1 of RFC 2396 (see http://www.ietf.org/rfc/rfc2396.txt). Reading Systems may use the bounds of the referenced element to determine the scope of the reference. If a fragment identifier is not used, the scope is considered to be the entire document. This specification does not require Reading Systems to mark or otherwise identify the entire scope of a referenced element.

The required type attribute describes the publication component referenced by the href attribute. The values for the type attributes must be selected from the list defined below when applicable. Other types may be used when none of the predefined types are applicable; their names must begin with the string “other.”. The value for the type attribute is case-sensitive.

The following list of type values is derived from the 13th edition of the Chicago Manual of Style:

cover   the book cover(s), jacket information, etc.

title-page   page with possibly title, author, publisher, and other metadata

toc   table of contents

index   back-of-book style index

glossary   glossary

acknowledgements

bibliography

colophon

copyright-page

dedication

epigraph

foreword

loi   list of illustrations

lot   list of tables

notes

preface

3 Basic OEBPS Document Vocabulary

3.1 Introduction

OEBPS 1.0 provided document authors with a convenient “Basic” document vocabulary (a set of elements and attributes, the “tagset”) that all OEB Reading Systems must recognize. This vocabulary was selectively drawn from the HTML 4.01 tagset, essentially conforming to XHTML 1.0 Transitional. A Document Type Definition (DTD) of the Basic vocabulary (the “OEBPS 1.0 Document DTD”) was provided for optional validation purposes, to insure Basic OEBPS Documents conformed to the recommended content models and the allowed attribute values of the vocabulary.

This specification similarly continues support for a “Basic” document vocabulary which all OEBPS 1.2 Reading Systems must recognize.

The Basic OEBPS 1.2 Document vocabulary is a pure subset of XHTML 1.1 from which the elements and attributes selected for inclusion are listed in the table in Section 3.2.2. Appendix B includes the Basic OEBPS 1.2 Document DTD expressing the Basic OEBPS Document vocabulary (and is in strict conformance with the XHTML 1.1 DTD with modularization removed). Appendix C includes the mnemonic character entities file associated with the Basic OEBPS 1.2 Document DTD. Appendix D describes the differences between the Basic OEBPS 1.2 and 1.0.1 Document vocabularies.

All Basic OEBPS Documents that validate to the Basic OEBPS 1.2 Document DTD will also validate to the XHTML 1.1 DTD. It is strongly recommended that all Basic OEBPS Documents be valid XML documents with respect to the Basic OEBPS Document DTD.

Except where noted in this section and elsewhere, the semantics and expected rendering behavior of the Basic OEBPS 1.2 Document vocabulary are as defined in XHTML 1.1. XHTML 1.1 relies heavily upon HTML 4.01 for semantic definitions and expected User Agent rendering behavior (http://www.w3.org/TR/html401/).

3.2 Basic OEBPS Document Vocabulary Components

3.2.1 The Common Attributes

The Basic OEBPS Document vocabulary, following XHTML 1.1, defines five Common attributes that may be applied to nearly all the elements in the Basic OEBPS Document vocabulary. These [Common] attributes consist of xml:lang and the [Core] attributes id, style, class, and title. These attributes are not individually listed in the element and attribute list in the following section 3.2.2, except to note their absence from the few exceptional elements.

These Common attributes may also be applied to non-Basic elements in Extended OEBPS Documents.

Because of their general importance, certain usage restrictions, and Reading System conformance issues, they are further described below. Except where further restricted, the data types for the attribute values conform with XHTML 1.1 (and the Basic OEBPS Document DTD in Appendix B.)

3.2.1.1 id

This attribute is used to give a unique identifier to an element. Its value must be of the XML data type ID with the token “Name” (the normative syntax of “Name” is precisely defined in section 2.3 of the XML 1.0 specification.)

Values for id must be unique across all elements in a single document. In addition, the value of id should not start with the string 'xml' (and all its case variants), since this is reserved in the XML specification for possible future standardization.

In this specification, the value of id must start with a “Letter” – it cannot start with an underscore (_) or colon (:) as otherwise allowed in XML 1.0. The character set defined by “Letter” is specified in Appendix B of the XML 1.0 specification.

For general HTML compatibility, document authors should further restrict the first character value of id to the Basic Latin letter characters (A-Za-z) and the remaining characters to (A-Za-z0-9.-_).

3.2.1.2 style (deprecated)

The core attribute style, used to apply CSS styling directly to an element, is deprecated in this specification as it is in XHTML 1.1.

It is strongly recommended the style attribute not be used in OEBPS 1.2 Documents; instead use the style element or preferably an external style sheet to specify the styling of any element.

3.2.1.3 class

This attribute allows selector-based style specifications. Its value must be a space-separated list of class names.

3.2.1.4 title

This attribute may be used to provide an “advisory title/amplification” for the element. Reading Systems may ignore its value.

3.2.1.5 xml:lang

This attribute may be inserted in documents to specify the language used in the contents and attribute values of any element in an XML document. The attribute value of xml:lang must comply with RFC 3066 (see http://www.ietf.org/rfc/rfc3066.txt), or its successor on the IETF Standards Track.

3.2.2 Elements and Attributes of the Basic OEBPS Document Vocabulary

This section lists all the elements and associated attributes included in the Basic OEBPS 1.2 document vocabulary. They are drawn from the XHTML 1.1 vocabulary specified at http://www.w3.org/TR/xhtml11/.

Refer to the Basic OEBPS Document DTD (Appendix B), the XHTML 1.1 specification, and section 3.3 for attribute value and other restrictions.

Table Notes:

1. The FIXED attribute of xmlns is currently declared for the root element <html>, with the value of http://www.w3.org/1999/xhtml. The FIXED attribute of xml:space has the value of preserve.
2. The “May Contain” category summarizes, for conformance with XHTML 1.1, the children elements and/or PCDATA (“parsed character data”) the element can (and in a few cases must) contain. The XHTML 1.1 content model is reproduced in the Basic OEBPS Document DTD (Appendix B). As mentioned in Section 3.1, it is strongly recommended that any Basic OEBPS Document that is not valid XML with respect to the Basic OEBPS Document DTD, still follow the XHTML 1.1 content model.

3.3 Certain Element and Attribute Semantic Differences From, and Restrictions Beyond, XHTML 1.1

As noted in Section 3.1, the semantics and rendering behavior of the Basic OEBPS Document 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 Basic 1.2 documents.

3.3.1 General Comments on URI References

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.

3.3.2 body element

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.

3.3.3 cite attribute

The optional attribute cite can 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.

3.3.4 img element

The inline element img should only be used to refer to images of OEBPS Core Media Types of PNG (http://www.ietf.org/rfc/rfc2083.txt) and JPG/JFIF (http://www.w3.org/Graphics/JPEG). 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-OEBPS 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 OEBPS Document.

For greater accessibility, it is strongly recommended that OEBPS Document authors include a URI reference in the optional longdesc attribute referencing a resource (such as another OEBPS 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.

3.3.5 link element

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".)

Reading Systems may ignore the media attribute, used to indicate the intended destination for style information.

3.3.6 object and param elements

The object element is the preferred method for generic object inclusion. When adding objects whose data media type is not drawn from the OEBPS 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 OEBPS content appearing immediately after the final param element that refers to the parent object. Descriptive text for the object, using inline content, an included OEBPS 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 for 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 may only appear before the renderable content of an object. Reading Systems may examine only param elements that are direct children of the object.

Example:

<object classid="java:tictactoe" codetype="application/java">
   <param name="height" value="60" />
   <param name="width"  value="60" />
   <object type="image/png" data="tictactoe.png">
      <param name="height" value="60" />
      <param name="width"  value="60" />
      Tic-Tac-Toe, a <em>dull</em> game. 
   </object>
</object>

3.3.7 script and noscript elements

Reading Systems must not, by default, render the textual content of the script element, but may choose to execute the script itself. To render the textual content of the script element, this specification recommends using the CSS display property to override the default none setting.

If noscript is included, whose purpose is to display some message should the Reading System not choose 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 cannot execute script, 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 PCDATA 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, either must be escaped, or put into a CDATA section. Reading System developers who include certain script execution capability must be aware of this potential problem.

3.3.8 type attribute of the style element

The type attribute of the style element is required (per XHTML 1.1 requirements) and must be given the value of “text/x-oeb1-css”. For browser rendering of an individual OEBPS Document as an XHTML 1.1 document, the value of the type attribute may need to be changed to “text/css” for the styling information in style to be recognized by the browser.

3.3.9 value of align attribute

The value of char for the align attribute is not included in the Basic OEB 1.2 Document Vocabulary. To achieve similar formatting, use the CSS text-align property with a <string> value.

3.4 Rendering of Documents on Reading Systems

A number of elements and attributes permit semantics that are not required of all OEBPS Reading Systems. For example, some devices may be monochrome, or provide mainly audio or tactile interfaces. In such cases this specification generally requires Reading Systems to accept all syntax (such as attribute values) permitted for the XHTML vocabulary, but does not require that they be honored. For example, a Reading System must parse and recognize the border attribute on table elements, but may choose to treat all values other than 0 the same as 1.

Note that this specification does not mandate specific rendering behavior for the Basic OEBPS Document vocabulary. Some Reading Systems may choose to express the intent of elements in presentation by closely following web-browser usage – a blank line before a paragraph, but no first-line text-indent, for example. Other Reading Systems may gear their presentation towards sustained novel-like readability: for example, no extra whitespace between paragraphs, but text-indent on the first line of each. Still other systems, such as speech generators, may present particular elements or entire documents in completely different ways.

4 OEBPS Style sheets

Like CSS style sheets, OEBPS style sheets are case-insensitive, except for parts that are not under the control of CSS. In particular, OEBPS Documents are XML documents and, as such, their element names and attribute values are case-sensitive. Therefore, element names and attribute values in OEBPS style sheets are case-sensitive. Currently, this applies only to element names, attribute names and attribute values used in selectors.

Where there are differences in the syntax specified by CSS1 and CSS2, OEBPS style sheets follow the CSS2 syntax. A list of these differences can be found in section D3 of the W3C Recommendation REC-CSS2-19980512, "Cascading Style Sheets, level 2 (CSS2) Specification" (http://www.w3.org/TR/REC-CSS2/grammar.html#tokenizer-diffs). OEBPS style sheets support the CSS construct of multiple declarations separated by semi-colons. Hence, the style sheet rules:

h1 { color: blue }
h1 { font-weight: bold }
h1 { font-size: 12pt }

are equivalent to:

h1 {   color: blue; 
   font-weight: bold; 
   font-size: 12pt }

Multiple rules with identical declaration blocks may be combined into one rule by separating the selectors with commas. Thus the rules:

h1 {text-indent: 0em}
h2 {text-indent: 0em}
h3 {text-indent: 0em}

may be combined into the equivalent form:

h1, h2, h3 {text-indent: 0em}

OEBPS style sheets support all CSS white space characters. Specifically, the characters “space” (Unicode code 32), “tab” (9), “line feed” (10), “carriage return” (13), and “form feed” (12) can occur in whitespace. Comments of the syntax defined in the CSS2 specification may be used in OEBPS-conforming CSS style sheets.

This specification supports the inline style attribute, the XHTML style element, and externally linked style sheets. This specification does not require that any handling of XML namespaces be performed by the Reading System in the processing of style sheets.

This specification assumes the use of selectors to be consistent with the definitions in the CSS 2 Specification (see http://www.w3.org/TR/REC-CSS2/selector.html for details). For example, the rules for determining which of multiple rules should be applied are determined by the rules of inheritance, cascading and selector specificity (see http://www.w3.org/TR/CSS2/cascade.html for details).

This specification does not require support for all CSS 2 selector forms; specifically, it does not require id-based selectors, or selectors that qualify element types using pseudo-classes. This specification does include pseudo elements, however, as described in this chapter.

If no style sheet is defined or no applicable style is found for a given Basic OEBPS 1.2 element, XHTML rendering is the default as defined elsewhere in this specification and the XHTML 1.1 specification.

This specification does not require that Reading Systems implement text-to-speech or other read-aloud technology. Those Reading Systems that do not implement such technology may ignore any CSS properties listed in this specification under the classification “Aural style sheets,” as well as the speak-header property listed under “Tables.”

All properties apply to elements as defined in CSS. That is, most properties can apply to all elements, while a few are limited based on the value of the display property (for example, text-align only applies when the display type is block, not inline). Reading Systems are, however, not required to support every distinction; for example they are not required to render borders or to float anything except the specific elements img, table, and object.

4.1 Selectors

Selectors specify the patterns that must be matched in the target document for determining the elements to which the style declaration(s) in the accompanying declaration block apply. If all conditions in the pattern are true for a certain element, the selector matches the element and the declarations in the declaration block are applied. This specification assumes a use of selectors that is consistent with the CSS 2 Specification and, in some cases, adds additional constraints to OEBPS style sheet selectors.

The following table lists all CSS selectors that are allowed in OEBPS style sheets. Any selectors not listed in this table are not supported by OEBPS style sheets and must be treated as syntax errors by conforming Reading Systems, even if they would otherwise be legal CSS selectors. Errors in selectors must be treated as specified in CSS 2 section 4.1.7.:

4.2 Value types

4.2.1 URI values

For those properties that take a URI value, the URI must point to a document of appropriate media type for the property in question. All such referenced documents must be contained within the package's manifest.

4.2.2 Integers and real numbers

Real numbers are denoted by <number>, integer values by <integer>. Either may have an optional sign value (one of “+” or “-“), though particular properties may restrict the ranges and sign of numeric values.

4.2.3 Length

All non-zero coordinate and size values must have specified units. All units defined by CSS 1 and 2 are supported:

4.2.4 Percentages

Where percentage units are supported, they are used as defined for each property in the CSS specifications for which they are an allowed value.

4.2.5 Color

Current browsers support a host of keyword color names. XHTML 1.1 defines 16 named colors, as well as numeric values. OEBPS style sheets may use all CSS 1 forms. However, Reading Systems are not required to distinguish all these colors for rendering (otherwise monochrome devices would necessarily be non-conforming, which is not the intent).

4.2.6 Time

Units defined by CSS 2 are supported:

4.2.7 Frequency

Units defined by CSS 2 are supported:

4.2.8 Strings

Strings must be quoted using either single or double quotes (Unicode codes 39 or 34, respectively). Nested strings must be escaped with a backslash (e.g. " a \"nested\" string") To embed a line break in a string, use the escape “\A”. The hexadecimal “A” is the line feed character in Unicode, but represents the generic notion of “newline” in CSS.

4.3 Properties

Default values for all supported CSS properties are as listed in CSS2.

The following table lists all CSS properties and values supported by this specification. Where not all values given in the CSS2 specification are listed for a given property, those values not listed are not supported by this specification. The column “Alternate display” indicates acceptable fallback display for CSS values that a Reading System cannot display as intended.

Properties that are unique to this specification have been underlined.

[1] Reading Systems may set the value of any margin property whose specified value is "auto" to 0.

[2] This is a shorthand property. The syntax for its value is as given in the CSS2 specification. Where this specification limits values or indicates alternate representations for properties abbreviated by this property, the same limits and alternate representations apply to this property.

[3] Reading Systems may map to one of the keyword values listed for this property.

[4] See section 4.2.5 on color units.

[5] CSS 2 provides a full description of the various table values and their correct renderings. Please refer to the CSS 2 Tables specification (http://www.w3.org/TR/REC-CSS2/tables.html) for a more detailed discussion of the various table values.

CSS 2 and XHTML provide similar but subtly different algorithms for rendering table data. These algorithms tend to generate the same results, but there are a few exceptions. In such cases, conforming Reading Systems must produce output consistent with the algorithm specified by CSS 2.

When using tables, authors should follow the Techniques for Web Accessibility Guidelines (http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/) for maintaining as much semantic information as possible. That document describes good practices for choosing how and when to use table tags, and when to use CSS properties. Specifically, see "Guideline 5: Create tables that transform gracefully" (http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#gl-table-markup).

[6] The content of an element assigned display: oeb-page-head should be presented only as a header, and the content of an element assigned display: oeb-page-foot should be presented only as a footer. Neither should be simply presented as if it were inline or block. Reading Systems, however, are free to present headers and footers either in special areas as usual for paper publications, or to make them available in another way. For example, a device with a small screen might instead pop them up on demand. For purposes of page layout, these display values are similar to block boxes with an absolute position (i.e. a position value of “fixed” or “absolute”). That is, they are removed from the normal flow and a new block box is created with it's own flow. Margins, padding and other block characteristics are determined as if the element had position: fixed set.

An element assigned display: oeb-page-head or display: oeb-page-foot shall not be considered in effect while any preceding content remains presented. For example, when rendered to a screen with appropriate style settings, the myhead element below would become the page header as soon as nothing preceding the containing div is displayed:

<div>
   <myhead style="display: oeb-page-head">The OEB Publication 
   Structure: Introduction</myhead>
   <h2>Introduction</h2>
   <p>…</p> 
</div>

Such a header (or footer) remains in effect until another header (or footer) is in effect instead, or until no part of its parent element remains presented (such as when the div is no longer visible in the above example), whichever occurs first.

[7] Reading System may map to “top.”

[8] Reading System may map to “bottom.”

[9] Must not be used within a style sheet whose @media value is other than “aural.”

[10] One-page Reading Systems must treat “left” and “right” as “always.”

[11] Reading Systems need not distinguish “italic” and “oblique” from each other.

[12] Number specifies the speaking rate in words per minute.

APPENDIX A: THE OEBPS PACKAGE DTD

See OEBPS Package DTD

APPENDIX B: THE BASIC OEBPS DOCUMENT DTD

See Basic OEBPS Documnet DTD

APPENDIX C: CHARACTER ENTITIES

See Character Entities

APPENDIX D: Differences Between the Basic OEBPS 1.2 and 1.0.1 Document Vocabularies

The Basic OEBPS Document vocabulary in this specification (hereafter referred to in this section as “Basic 1.2”) is similar to that for version 1.0.1 (“Basic 1.0”). The most significant difference is the addition of new elements and associated attributes (most notably improved table support), and the removal of nearly all the deprecated elements and attributes in Basic 1.0. It is noted that Basic 1.0 Document authors who avoided using any of the deprecated elements and attributes will, in general, find it easier to upgrade their documents to conform to Basic 1.2.

Following are the specific differences between Basic 1.2 and Basic 1.0.

D.1 Elements in Basic 1.0 Removed in Basic 1.2

All of these elements were deprecated in Basic 1.0, and are removed in Basic 1.2 since they are not included in XHTML 1.1. In place of these elements, use CSS.

D.2 Attributes in Basic 1.0 Removed in Basic 1.2

All of these attributes were deprecated in Basic 1.0, and are removed in Basic 1.2 since they are not included in XHTML 1.1. In place of the stylistic-oriented attributes, use CSS. For the name attribute, removed for a and map, use id instead.

D.3 Deprecated Basic 1.0 Attributes Undeprecated in Basic 1.2

D.4 Deprecated Core Attribute style

Following XHTML 1.1, the Core/Common attribute style is deprecated in Basic 1.2. It may be removed in a future version of this specification. Thus, for future upgradeability of documents, it is strongly recommended the style attribute not be used in Basic 1.2 documents; instead, use either the style element or external style sheets.

D.5 New Elements (and Included Attributes) Added in Basic 1.2

All of these new elements include support for the Common attribute set described in Section 3.2.1 (for brevity the Common attributes are not included in the above table.)

D.6 New Basic 1.2 Attributes Added to Pre-Existing Elements

D.7 Miscellaneous Differences in DTD Content Models, Elements and Attributes

Following are various differences in strict DTD content models, attribute data types, etc., between Basic 1.2 and Basic 1.0. These differences arise by Basic 1.2 being a pure subset of XHTML 1.1 as detailed in Section 3.1. Note that some of the following items apply only to Basic OEBPS Documents that are valid XML with respect to the Basic OEBPS Document DTD; however, it is strongly recommended that all Basic OEBPS 1.2 documents completely conform with the Basic OEBPS Document DTD (and thus XHTML 1.1) as mentioned in Section 3.1.

1. In Basic 1.2, the type attribute for style is REQUIRED. In Basic 1.0 it was FIXED.
2. In Basic 1.2, the content model for body is Block.mix (Block level elements plus the "level-independent" elements), while for Basic 1.0 body could also contain PCDATA and Inline elements.
3. In Basic 1.2, blockquote can contain only Block.mix. In Basic 1.0, this element could also contain PCDATA and Inline elements. In essence, blockquote is identical to body in content model and can be thought of as sort of a "document within a document".
4. In Basic 1.2, head is required, while in Basic 1.0 it was optional.
5. In Basic 1.2, the type attribute in link is IMPLIED (optional), while in Basic 1.0 it was REQUIRED. When identifying an external style sheet, type should be used to identify the MIME media type of the style sheet, such as text/x-oeb1-css.
6. In Basic 1.2, the data type for the class attribute is NMTOKENS. In Basic 1.0 it was CDATA.
7. In Basic 1.2, the data type for the attribute usemap in object is IDREF. In Basic 1.0 it was CDATA.
8. Basic 1.2 supports the value of baseline for the valign attribute (used in several table-related elements), while Basic 1.0 does not support it.
9. Note that because several new Table elements are added, the Basic 1.2 content model for table is significantly more complex than that for Basic 1.0. Refer to the Basic OEBPS Document DTD (Appendix B) for the exact content model.

APPENDIX E: CONTRIBUTORS

This specification has been developed through a cooperative effort, bringing together publishers, Reading System vendors, software developers, and experts in the relevant standards.

Version 1.2 of this specification was prepared by the Open eBook Forum Publication Structure Working Group. Active members of the working group at the time of publication of revision 1.2 were:

• Jeff Alexander, Franklin Electronic Publishers
• Garth Conboy, Gemstar eBook Group Limited (Version 1.2 Co-Editor)
• Eva Conkright, Random House
• Brady Duga, Gemstar eBook Group Limited (Version 1.2 Co-Editor)
• Jerry Dunietz, Microsoft Corporation (Working Group Vice Chair)
• George Kerscher, Daisy Consortium
• Gene Golovchinsky, FX Palo Alto Laboratory, Inc. (Development Sub-Group Co-Chair)
• Donald Goyette, McGraw-Hill
• Rebecca Guenther, Library of Congress
• Markku Hakkinen, isSound Corporation
• Benjamin Jung, deepX
• Christopher R, Maden, crism consulting
• Bob Mathews, Adobe
• Michael Moodie, National Library Service for the Blind and Physically Handicapped, Library of Congress
• Jon Noring, Windspun Inc. (Maintenance Sub-Group Chair)
• David Pawson, Royal National Institute for the Blind
• Chris Powell, University of Michigan Library
• James Pritchett, Recording for the Blind and Dyslexic
• Allen Renear, Brown University Scholarly Technology Group (Working Group Chair)
• Dorothea Salo, OverDrive, Inc. (Working Group Scribe)
• Sheela Sethuraman, CAST
• Roger Sperberg, e-bks, LLC
• Patrick Stickler, Nokia
• Mikhail Vaysbukh, Data Conversion Laboratory
• Garret Wilson, GlobalMentor, Inc. (Development Sub-Group Co-Chair)
• Harrison Yee, Apex

Contributors to the Version 1.2 effort who were no longer active working group members at the time of publication include:

• David Goldstein, Versaware Inc.
• Barbara Hammond, Nokia
• Ilan Sender, Microsoft Corporation
• Lisa Rupe, Questia Media Inc.

Version 1.0.1 of this specification was prepared by the Open eBook Forum Publication Structure Working Group. Active members of the working group at the time of publication of revision 1.0.1 were:

• Fred Beuthel, LizardTech
• Garth Conboy, Gemstar eBook Technology (Working Group Vice Chair)
• Marisa DeMeglio, isSound Corporation
• Kimmo Djupsjöbacka, Nokia
• Brady Duga, Gemstar eBook Technology
• Jerry Dunietz, Microsoft Corporation
• George Kerscher, Daisy Consortium
• David Goldstein, Versaware Technologies, Inc.
• Gene Golovchinsky, FX Palo Alto Laboratory, Inc.
• Rebecca Guenther, Library of Congress
• Markku Hakkinen, isSound Corporation
• Tony Lavender, netLibrary, Inc.
• Michael Moodie, National Library Service for the Blind and Physically Handicapped, Library of Congress
• Jon Noring, Windspun Inc.
• David Pawson, Royal National Institute for the Blind
• James Pritchett, Recording for the Blind and Dyslexic
• Allen Renear, Brown University Scholarly Technology Group (Working Group Chair)
• Lisa Rupe, Questia Media Inc.
• Dorothea Salo, Impressions Book and Journal Services (Working Group Scribe)
• Ilan Sender, Microsoft Corporation
• Roger Sperberg, e-bks, LLC
• Mikhail Vaysbukh, Data Conversion Laboratories
• Garret Wilson, GlobalMentor, Inc. (Maintenance Sub-Group Chair)
• Sarah Wood, OverDrive, Inc.

Version 1.0 of the specification was developed by the “Open eBook Authoring Group” which was composed of the following people (affiliations given are those at the time of publishing version 1.0, September 16, 1999):

Facilitator:

• Victor McCrary, National Institute of Standards and Technology,
  U.S. Department of Commerce

Contributors:

• Jeff Alger, Microsoft Corporation
• Garth Conboy, SoftBook Press
• Horace Dediu, BCL Computers
• Steve DeRose, Brown University Scholarly Technology Group
• Kimmo Djupsjöbacka, Nokia
• Brady Duga, SoftBook Press
• Jerry Dunietz, Microsoft Corporation
• David Goldstein, Versaware Inc.
• Gene Golovchinsky, FX Palo Alto Laboratory, Inc
• Markku Hakkinen, The Productivity Works
• Gunter Hille, Project Gutenberg-DE
• Kate Hughes, Microsoft Corporation
• George Kerscher, DAISY Consortium
• Steve Kotrch, Simon & Schuster
• Brian Lambert, Glassbook Inc.
• Jon Noring, Exemplary Technologies
• Aleksey Novicov, Softbook Press
• David Ornstein, NuvoMedia, Inc.
• Dhiren Patel, NuvoMedia, Inc.
• Steve Potash, OverDrive Systems
• Allen Renear, Brown University Scholarly Technology Group
• Mike Riley, R.R. Donnelley & Sons Company
• Ben Trafford, Exemplary Technologies
• John Voiklis, Red Figure, Inc.
• Garret Wilson, GlobalMentor, Inc.

Other Contributing Organizations:

• Adobe
• EAST Co., Ltd
• IBM
• Librius
• Vadem