1.0: 概説

1.1: 目的と適用範囲

電子書籍の技術が市場において普及するために、リーディングシステムは大量の様々な著作物に容易にアクセスできる必要がある。この Open Publication Structure (OPS) の仕様書は、電子出版物のコンテントを表示するための標準規格を示すものである。

本仕様の目的はコンテンツ供給者（例えば、出版社や著者などの発表するべきコンテンツの持ち主）と出版ツールの供給者に、多様なリーディングシステム上で電子コンテンツを、忠実で、アクセスしやすく、適切に表示するための最小限の共通ガイドラインを示すことである。
本仕様は、既存のコンテンツ形式の標準規格の反映を追求する。
本仕様のゴールは電子書籍の提供者（出版社、取次、著者など）が利用できるコンテンツの標準的な表記方法を定義して、コンテンツを多様なリーディングシステムに提供し、リーディングシステム間で最大限に等しい表示が保証されるようにすることである。

関連仕様である、Open Packaging Format (OPF) 仕様書では、様々な OPS 出版物同士を結びつけて、電子出版物に付加的な構造や意味を持たせるメカニズムが定義されている。具体的には、OPFは以下の働きをする。

電子出版物のあらゆるコンポーネント（マークアップファイル、画像、ナビゲーション構造など）を記述、参照する。
出版物レベルでのメタデータを提供する。
出版物が読まれる順序を指定する。
OPS の拡張が行われた場合の、フォールバック情報を提供する。
宣言型目次(NCX)を指定するためのメカニズムを提供する。

パッケージング方法の記述をコンテントの記述から切り離してモジュール化するために、OPF の仕様は OPS マークアップの仕様から分離されている。これにより、他の標準化団体によるパッケージング技術（例えば非 OPS コンテキストにおける DAISY のような）を容易に利用することができる。

三つ目の関連仕様である OEBPS Container Format (OCF) 仕様では、電子出版物のコンポーネントを一つのアーカイブにまとめて送信、配信や保管するための標準メカニズムが定義されている。

1.2: 定義

コンテンツ供給者 [Content Provider]

出版社や著者など情報の供給者で、本仕様に記述された形式で出版物を一種類以上のリーディングシステムに供給する者を指す。

廃止予定 [Deprecated]

本仕様では、許容されているが推奨（recommended）されていない機能を指す。この機能は将来の改定において削除される可能性がある。 OPS 適合リーディングシステムは廃止予定の機能をサポートしなければならない（must）。

拡張モジュール [Extended Module]

モジュール化された XML ボキャブラリ（すなわち、自身の仕様において定義された名前付きモジュールのセット）のモジュールで自身の仕様によってサポートされる必要がないもの指す。（例えば、OPS コンテキストにおける XHTML の ruby や forms モジュール）

インライン XML アイランド [Inline XML Island]

インライン XML アイランドは、OPS 出版物の XHTML 推奨ボキャブラリドキュメント内に存在する、非推奨ボキャブラリや拡張モジュールを使用した XML ドキュメントのフラグメントを指す。

NCX

宣言型目次 (the Navigation Center eXtended または NCX)。

NVDL

NVDL（Namespace-based Validation Dispatching Language）はドキュメントのスキーマ間の検証を実現する機能である。本仕様では OPS のコンテキストの中で様々なスキーマの扱い方を抽象的に定義する方法として、NVDL 言語を使用する。

OCF

OEBPS Container Format は OPS 出版物の全てのコンポーネントを単一のファイルシステムの実体に結合させるメカニズムを定義する。

OEBPS

Open eBook Publication Structure。本仕様 OPS は以前のバージョンはその関連仕様である OPF とともに、OEBPS という一つの仕様に統合されていた。本バージョンでは仕様のモジュール継承を支援するために、OEBPS は OPS と OPF に分割された。以前の統一仕様である OEBPS の最新バージョンは OEBPS 1.2 であった。

OPF

Open Packaging Format は本標準の姉妹規格にあたる。 OPF は本標準に適合する出版物の全てのコンポーネントを、メタデータ、読み順やナビゲーション情報とともに OPS 出版物としてパッケージ化するメカニズムを定義する。

OPF パッケージドキュメント [OPF Package Document]

OPS 出版物についての説明と、OPF パッケージドキュメント自身を除く全てのファイルを参照を行う XML ドキュメントを指す。 OPF パッケージドキュメントは出版物の全てのファイルを識別して、それらのファイルについての説明情報を提供する。 OPF パッケージドキュメントは OPF 仕様書（日本語訳）にて定義されている。

OPS

Open Publication Structure。本標準規格を指す。

OPS コンテントドキュメント [OPS Content Document]

本仕様に適合した XHTML、DTBook、アウトオブライン XML アイランドを指し、 OPF パッケージドキュメントの spine 要素に記述される。

OPS コアメディアタイプ [OPS Core Media Type]

全てのリーディングシステムがサポートしなければならない（must） MIME メディアタイプを指す。

OPS 出版物 [OPS Publication]

OPS コンテントドキュメント、OPF パッケージドキュメントや、構造化されたテキストと図を含む様々なメディアタイプのファイルの集合体であり、出版するための結合ユニットを構成する。

アウトオブライン XML アイランド [Out-of-Line XML Island]

アウトオブライン XML アイランドは OPS 出版物の中にある XML ドキュメントで、推奨ボキャブラリを使用して記述されていないもの、または推奨ボキャブラリを使用して記述されているが拡張モジュールを使用しているものを指す。アウトオブライン XML アイランドは全く独立した、完全で妥当な XML ドキュメントである。

推奨ボキャブラリ [Preferred Vocabulary]

XHTML モジュールおよび／または DTBook マークアップのみによって構成された XML を指す。

読者 [Reader]

出版物を読む人を指す。

リーディングデバイス [Reading Device]

出版物が表示される物理的なプラットフォーム（ハードウェアおよびソフトウェア）を指す。

リーディングシステム [Reading System]

OPS 出版物（OCF コンテナにパッケージ化されていることが望ましい）を受け取り、コンテンツの消費者が利用できるようにするための、ハードウェアおよび／またはソフトウェアの組み合わせを指す。リーディングシステムは多様なアーキテクチャを持つことができる。リーディングシステムは完全に一つのデバイスとして実装してもよい（may）し、また複数のコンピュータ間に分割して実装してもよい（may）。全てのリーディングシステムは OPS 出版物を受け取らなければならない（must）が、OPS 出版物を直接受け取るのが特にリーディングシステムのひとつのコンポーネントであるリーディングデバイスである必要はない（need not）。リーディングシステムは、圧縮、インデックス化、暗号化、権利管理、配信などの付加的な処理機能を持ってもよい（may）。

XML ドキュメント [XML Document]

XML ドキュメントとは XML 1.1 標準（http://www.w3.org/TR/xml11/）によって定義された、完全で妥当な XML ドキュメントを指す。

XML ドキュメントフラグメント [XML Document Fragment]

ドキュメントフラグメントまたは、XML ドキュメントフラグメントとも呼ばれ、 Document Object Model Level 1（http://www.w3.org/TR/REC-DOM-Level-1/）にて定義されているが、整形式であること、という追加要件がある。

XML アイランド [XML Island]

インライン XML アイランドまたはアウトオブライン XML アイランドを指す。

XML 名前空間 [XML Namespaces]

XML 名前空間 [XML namespaces]、または単に名前空間 [namespaces] とも呼ばれ、 XML Namespaces（http://www.w3.org/TR/xml-names11/）に適合していなければならない。

~~XPointer~~

The XML Pointer Framework is a W3C specification that defines a method of pointing into specific locations within an XML document, thus identifying document fragments, as defined in XML Pointer Framework (http://www.w3.org/TR/xptr-framework/).

1.3: 他の仕様との関係

本仕様では他の仕様のサブセットおよびアプリケーションが組み合わされている。これらは互いに、電子文書の構築、編成、表示および明確な変換を容易にしている。

Extensible Markup Language (XML) 1.1 (Second Edition) specification (http://www.w3.org/TR/xml11/)
Namespaces in XML 1.0 (Second Edition) specification (http://www.w3.org/TR/xml-names11/)
Document Object Model (Core) Level 1 (http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html)
XML Pointer Framework (http://www.w3.org/TR/2003/REC-xptr-framework-20030325/)
XHTML™ 1.1 - Module-based XHTML - Second Edition specification (http://www.w3.org/TR/xhtml11/)
Specifications for the Digital Talking Book (DTB) (http://www.niso.org/standards/resources/Z39-86-2005.html)
Scalable Vector Graphics (SVG) 1.1 Specification (http://www.w3.org/TR/SVG11/)
Cascading Style Sheets, level 2 specification (http://www.w3.org/TR/REC-CSS2)
Unicode Standard, Version 4.0. Reading, Mass.: Addison-Wesley, 2003 新たなバージョンの発表によって時折アップデートされる。（標準規格と Unicode Character Database に関する最新バージョンと他のバージョンの追加情報については http://www.unicode.org/unicode/standard/versions を参照。）
Particular MIME media types (http://www.ietf.org/rfc/rfc4288.txt および http://www.iana.org/assignments/media-types/index.html)
Associating Style Sheets with XML Documents (http://www.w3.org/TR/xml-stylesheet)
Web Content Accessibility Guidelines 1.0 (http://www.w3.org/TR/WCAG10/)
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. (http://www.ietf.org/rfc/rfc2119.txt)
~~Synchronized Multimedia Integration Language (SMIL 2.1) (http://www.w3.org/TR/2005/REC-SMIL2-20051213/); and~~
The OPF specification (http://www.idpf.org/opf/opf2.0/download/)
Namespace-based Validation Dispatching Language (NVDL) (http://standards.iso.org/ittf/PubliclyAvailableStandards/c038615_ISO_IEC_19757-4_2006(E).zip)

1.3.1: XML との関係

OPS が XML に基づいているのは、XML ドキュメントが一般性と簡潔性を持ち、将来的な技術用途にも適合しやすいためである。また、XML はドキュメントの構文についても明確なルールを持っており、開発コストやシステム間の不一致を軽減することができる。さらに、XML は拡張性を持ち、特定のドキュメントや要素の型に縛られない。また国際化をサポートしており、ドキュメントのマークアップがドキュメント内部のパーツをより直接的に表現できることや、ドキュメントに忠実な形で自動成型できること、他なるタイプのコンピュータによって処理できることに取り組んでいる。

リーディングシステムは XML 1.1 の定義する XML プロセッサでなければはならない（must）。すべての OPS コンテントドキュメントは、個々のスキーマに従った妥当な XML ドキュメントでなければはならない（must）。

1.3.2: XML 名前空間との関係

リーディングシステムは http://www.w3.org/TR/xml-names11/ にある XML 名前空間の勧告に従って XML 名前空間を処理しなければはならない（must）。

名前空間接頭辞によって、異なる XML ボキャブラリ同士が同じ名前を利用していても区別することができる。 XML ドキュメントの中の XML 名前空間宣言は、名前空間接頭辞と一意の URI を関連付ける。この接頭辞はドキュメント内の要素名や属性名に用いられる。一方、XML ドキュメントの XML ドキュメントの名前空間宣言は、名前空間接頭辞を持たない要素に適用する URI をデフォルトの名前空間としてもよい（may）。 XML の名前空間接頭辞はコロンによって後続する要素名、属性名から区切られる。

例:

xmlns:ops="http://www.idpf.org/2007/ops"

全ての OPS コンテントドキュメントのルート要素は、ドキュメントの名前空間を明確に指定しなければならない（must）。 XHTML 推奨ボキャブラリでは、名前空間には http://www.w3.org/1999/xhtml を指定する。 DAISY の ~~Talking Book~~DTBook 推奨ボキャブラリでは、名前空間に http://www.daisy.org/z3986/2005/dtbook/ を指定する。 OPS 名前空間がドキュメントに用いられているならば、名前空間には http://www.idpf.org/2007/ops を明確に宣言しなければならない（must）。名前空間接頭辞を使用するならば、ドキュメントの著者は ops 接頭辞をその名前空間に結び付け、他の名前空間の接頭辞には ops を使用しないことを推奨する（recommended）。

例:

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ops=" http://www.idpf.org/2007/ops">

OPS は推奨ドキュメントタイプや XML アイランドを越えた、追加機能や検証要件を持つため、特定の状況では OPS に関連付けられた別の名前空間が用いられる。

1.3.3: NVDL との関係

本仕様では、様々なスキーマ間の相互作用を明確に定義する方法として NVDL 言語( http://standards.iso.org/ittf/PubliclyAvailableStandards/c038615_ISO_IEC_19757-4_2006(E).zip を参照) を利用している。 NVDL は様々な XML スキーマ言語同士の相互作用と検証を実現する。標準的な OPS の NVDL 定義については、附録 A を参照のこと。

OPS ドキュメントの検証には NVDL ツールを利用してもよい（may）が、本仕様は必ずしもそのようなツールの利用を要求するものではない（does not）。

1.3.4: XHTML および DTBook との関係

本仕様はこれまでのソフトウェアツール、過去のデータ資産、出版に関する慣習やマーケット状況が持つ重要性を認識しているため、特定の XHTML 1.1 ドキュメントタイプモジュールと DTBook を推奨ボキャブラリとして組み込んでいる。この取り組みにより、コンテンツ供給者はこれまでの XHTML や DTBook のコンテンツ、ツールおよび専門知識を活かすことができる。

リーディングシステムの（おそらく電源やディスプレイの制約を持つデバイスに取り組んでいる）開発者の実装負荷を最小化するために本仕様の推奨ボキャブラリは XHTML 1.1 の要素と属性を完全には含んでいない。加えて、XHTML 1.1 仕様から採用されたモジュールは、現在の XHTML と同じ使用法ができるものが選択されている。

XHTML 1.1 で廃止予定とされているあらゆる構成概念は、本仕様においても廃止予定であったり取り除かれていたりする。これらには多くの場合、CSS に基づいた代替方法が提供されている。スタイルシートの構成概念は、XHTML におけるものを越えた新しい表現機能にも用いられている。

1.3.5: CSS との関係

本仕様は CSS 2 に基づくスタイル言語を定義している。（CSS 2.1 の仕様は現在のところ、未だに "Working Draft" の段階であることに注意が必要である。）スタイルシートの MIME タイプであった text/x-oeb1-css は廃止予定となり、代わりに text/css が採用されている。

本仕様における CSS に基づくスタイルシートの構成概念は必須となる表現機能を定義している。リーディングシステムの開発者やデバイスの製造者の負荷を最小化するために、CSS 2 の全プロパティを完全には含んでいない。ページレイアウト、ヘッダ、フッタをサポートするために、幾つかのプロパティや値が追加されている。これらを総合して、OPS CSS 2.0 必須サブセットは構成されている。

多くの場合において、本仕様は標準的な CSS スタイルシートが要求する表示の全てを提供することを、リーディングシステムに求めない。例えば、リーディングシステムにはモノクロのディスプレイのものもありうる。しかし全てのリーディングシステムの表示をモノクロに制限することも、OPS を越える非標準的な拡張を使用して色を宣言することも、許容できるものではない。この場合、この CSS 設定は認められその意味合いを保持するが、リーディングシステムは潔く、よりシンプルな形に表示品質を落としてもよい（may）。

OPS に適合したリーディングシステムは、OPS CSS 2.0 必須サブセットのプロパティを全て表示しなければならない（must）。リーディングシステムは OPS CSS 2.0 必須サブセットを越えたプロパティをサポートしてもよい（may）が、サポートされていないプロパティは全て、潔く CSS 2.0 仕様の水準にまで表示品質を落とさなければならない（must）。

本仕様は style 属性（廃止予定ではあるが）、style 要素および外部リンクスタイルシートをサポートしている。リーディングシステムは、スタイルシートを処理している間、XML 名前空間処理を行わなければならない（must）。

スタイルシートは、幾つかの方法で OPS コンテントドキュメントに関連付けられている。

特定の XHTML 要素の style 属性による指定方法（廃止予定）
XHTML の head 要素内の style 要素による指定方法
XHTML の head 要素内の link 要素で外部スタイルシートを指定する方法
xml-stylesheet 処理命令によって外部スタイルシートを指定する方法（Section 1.3.8 を参照）

最初の三つのケースの相対的な優先度については、XHTML 1.1 と CSS2 に定義されているとおりである。処理命令によってリンクされているスタイルシートは、XHTML の link 要素であるかのように扱われるが、実際のどんな XHTML の link 要素よりも優先度が高い。適合性のセクションで定義されているように、要素の中にスタイルシートが定義されていなかったり、適用できるスタイルが見つからなかった場合には、 XHTML は本仕様で定義されているデフォルト値に従って表示される。

XHTML の link 要素や xml-stylesheet 処理命令が指定する外部スタイルシートは、CSS の他に、XSL （http://www.w3.org/TR/xsl を参照）のような他のスタイル言語を使用してもよい（may）。リーディングシステムは、ここで指定した CSS を越えたスタイル言語をサポートする必要はない。

OPS CSS 2.0 必須サブセットのみを実装したリーディングシステムは、他のスタイルシート言語を使用したスタイルシートを無視してもよい（may）。拡張スタイルシート機能をサポートしたリーディングシステムでは、他のあらゆる外部スタイルシートから選択してもよい（may）。 OPS CSS 2.0 必須サブセットを越えてサポートするあらゆるスタイル言語にはユニークな MIME メディアタイプを定義し、MIME メディアタイプを調べればその言語を用いたスタイルシートを特定できるようにすることを強く推奨する（strongly recommended）。

CSS の position プロパティの値には絶対位置（つまり absolute や fixed ）を使用しないことを、強く推奨する。

1.3.6: Unicode との関係

出版物は Unicode 標準（http://www.unicode.org/unicode/standard/versions を参照）に定義された完全 Unicode 文字セットである UTF-8 または UTF-16 のエンコードを使用してもよい（may）。 Unicode 機能の使用は国際化とドキュメントの多言語化を促進する。しかしリーディングシステムが全ての Unicode 文字のグリフを提供する必要はない（not required）。

リーディングシステムは、UTF-8 および UTF-16 の全ての文字を（XML が要求するとおりに）適切に解析しなければならない（must）。リーディングシステムには表示できない文字があってもよい（may）が、表示できない文字があることを、何らかの形で通知できなければならない（must）。リーディングシステムは Unicode 文字を、単なる 8bit 文字のように表示してはならない（must not）。例えば、有害物質の記号 (0x2623) のグリフをサポートする必要はないが、"&#"(0x0026 0x0023) の二文字であるかのように、解析、表示をしてはならない（must not）。

リーディングシステムの一貫した検索や並べ替え処理の実装を支援するためには、 Unicode Normalization Form C （NFC）（http://www.w3.org/TR/charmod-norm/ を参照）を利用する必要がある（required）。

1.3.7: MIME メディアタイプ

本仕様では、全てのリーディングシステムがサポートしなければならない（must）、出版物に内包してもよい（may） OPS コアメディアタイプのリストを定義する。出版物はこのリストにないメディアタイプのリソースを内包してもよい（may）が、そのようなリソースは本仕様書や、OPF 仕様書が定義する方法によって OPS コアメディアタイプである代替リソースを内包しなければならない（must）。

OPS コアメディアタイプ

MIME メディアタイプ	リファレンス	説明
image/gif	http://www.w3.org/Graphics/GIF/spec-gif89a.txt	ラスター画像に使用する
image/jpeg	http://www.w3.org/Graphics/JPEG/	ラスター画像に使用する
image/png	RFC 2083	ラスター画像に使用する
image/svg+xml	http://www.w3.org/TR/SVG11/	ベクター画像に使用する
application/xhtml+xml	XHTML 1.1	OPS コンテントドキュメントに使用する
application/x-dtbook+xml	http://www.niso.org/standards/resources/Z39-86-2005.html	OPS コンテントドキュメントに使用する
text/css	CSS 2.0	OPS CSS サブセットスタイルシートに使用する
application/xml	http://www.w3.org/TR/xml11/	アウトオブライン XML ドキュメントに使用する
text/x-oeb1-document	OEBPS 1.2 specification	廃止予定。基本または拡張 OEBPS 1.0.1 および 1.2 ドキュメントに使用する
text/x-oeb1-css	OEBPS 1.2 specification	廃止予定。OEBPS 1.0.1 および 1.2 CSSサブセットスタイルシートに使用する
application/x-dtbncx+xml	DTBook specification	NCX

1.3.8: XML スタイルシート処理命令

本仕様は W3C 勧告 "Associating Style Sheets with XML Documents"（http://www.w3.org/TR/xml-stylesheet）において定義された XML スタイルシート処理命令である xml-stylesheet をサポートする。この処理命令は XML ドキュメントのプロローグ部分に置かれる。link 要素の数に応じて、複数回記述することができる。

1.4: 適合性

本ドキュメントで使用されるキーワード、"～しなければならない（must）"、"～してはならない（must not）"、 "～する必要がある（required）"、"～するべきである（shall）"、"～するべきではない（shall not）"、">～するべきである（shuould）"、"推奨する（recommended）"、"～してもよい（may）"、"付加的な（optional）"は RFC 2119 において説明されているとおり解釈されなければならない（must）。

このセクションでは OPS コンテントドキュメントとリーディングシステムとの適合性について定義する。

1.4.1: OPS コンテントドキュメントの適合性

このセクションでは OPS コンテントドキュメントの適合性について定義する。

1.4.1.1: OPS コンテントドキュメント

以下の場合に限り、ドキュメントは OPS コンテントドキュメントであると見なされる。

本仕様書の定義する XHTML サブセットと、インライン XHTML アイランドやインライン SVG のような OPS 固有のコンテント拡張によって構成されているもの。または、
MIME メディアタイプ application/x-dtbook+xml を持つドキュメントで、DTB 仕様 (http://www.niso.org/standards/resources/Z39-86-2005.html) に適合しており、インライン XHTML アイランドやインライン SVG のような OPS 固有のコンテント拡張を使用してはならない（must not）もの。または、
その他の MIME メディアタイプの XML ドキュメント、すなわち、アウトオブライン XML アイランド。

1.4.1.2: XHTML コンテントドキュメントの要件

適正な XHTNL コンテントドキュメントは以下の条件を満たさなければならない（must）。

（XML 1.1 によって定義された）整形式の XML ドキュメントであること。
UTF-8 または UTF-16 にエンコードされていること。
附録 A にて提供される NVDL スキーマ相互作用に従った妥当な XML ドキュメントであること。
MIME メディアタイプが application/xhtml+xml または text/x-oeb1-document（廃止予定）のいずれかのであること。
インライン XML アイランドに含まれていない全ての XHTML の要素と属性が、本仕様書の認める XHTML サブセットから選ばれていること。

1.4.1.3: DTBook コンテントドキュメントの要件

以下の場合に限り、ドキュメントは DTBook コンテントドキュメントであると見なされる。

（XML 1.1 によって定義された）整形式の XML ドキュメントであること。
UTF-8 または UTF-16 にエンコードされていること。
DTBook DTD （http://www.daisy.org/z3986/2005/dtbook-2005-2.dtd）に従った妥当な XML ドキュメントであること。
MIME メディアタイプが application/x-dtbook+xml であること。

1.4.1.4: アウトオブライン XML コンテントドキュメントの要件

以下の場合に限り、ドキュメントはアウトオブライン XML コンテントドキュメントとして扱われる。

自身のスキーマに従った整形式の妥当な XML ドキュメントであること。
UTF-8 または UTF-16 にエンコードされていること。
MIME メディアタイプが application/xhtml+xml、text/x-oeb1-document、application/x-dtbook+xml 以外であること。

1.4.2: リーディングシステムの適合性

本仕様ではリーディングシステムの適合水準をひとつだけ定義する。リーディングシステムは以下のようにドキュメントを処理する場合に限り、適合しているとされる。

OPS コンテントドキュメントが与えられた時に、リーディングシステムは以下のことをしなければならない（must）。

XML 1.1 仕様が要求するとおりに、整形式エラーのハンドリング要求も含め、XML を正確に処理すること。
本仕様の認める全てのマークアップを認識し、本仕様や XHTML 1.1、 CSS 2、DTBook の仕様における解釈に従って処理すること。（仕様同士の解釈が衝突する場合には、本仕様の解釈を優先する。）
サポートされていないメディアタイプの img 要素や object要素は、フォールバックがない限り表示しないこと。これらのフォールバックについては img 要素に関して、Section 2.3.4 に、object 要素に関して Section 2.3.6 に明確に定義されている。
前述のセクション XML 名前空間との関係が定義する、適切な名前空間の指定があることを検証すること。

1.4.3: 将来のバージョンとの互換性

本仕様の後続世代は定められた方針に従って進むのが、本仕様の貢献者たちの意図である。具体的には、

コンテンツ形式の標準規格は W3C、IETF などの適用規格と互換性を持つこと。
本仕様の将来のバージョンは OPS 適合リーディングシステムのさらなる XML 処理能力の向上や、他の XML に関連する適用規格をサポート求めて、 XML に準拠する仕様との提携を進めてゆくことが望まれる。
本仕様の将来のバージョンは、OPS ドキュメントのハイパーリンク機能を向上させることが望まれる。
必要な機能が関連する公式の標準規格にない場合には、しかるべき標準化団体への最終提案と合致する形で、既存の標準規格の拡張として定義されるべきである。
姉妹規格である OPF との提携を継続する。
OCF content packaging standard との提携と統合を継続すること。

1.4.4: OPS バージョン 2.0 の互換性

OPS のバージョン 2.0 は以前のバージョンである OEBPS 1.2 に比べて、かなり重要な改良が行われている。 OPS バージョン 2.0 が OEBPS 1.2 に対して行った機能改良には、コンテンツをより忠実に表示するコントロールのサポート、拡張メカニズムの改良、アクセシビリティの向上、OPS に準拠した標準規格との提携強化、などが含まれる。とりわけ重要な追加項目を以下に示す。

XML 1.1 を併合したことにより、整形式の XML から妥当な XML に制約が強化された。
XML 名前空間処理が必要とされるようになった。
基本および拡張ドキュメントという概念は除かれ、XML 推奨ボキャブラリと新規の XML アイランドに準拠した拡張メカニズムに置き換えられた。
XHTML 要素セットの OPS サブセットは XHTML 1.1 に含まれる特定のモジュールへの参照に置き換えられた。
DTBook 要素セットが新たに推奨ボキャブラリとされた。
SVG のサポートが追加された。
埋め込みフォントのサポートが追加された。
OEBPS 1.2 Package はナビゲーションとアクセシビリティの改良のために拡張され、その文書は OPF 仕様として切り離された。
以前の OEBPS 固有の MIME タイプは廃止予定とされ、より広汎に使用される一般的な MIME タイプに置き換えられた。

OEBPS 1.2 から OPS 2.0 への変更は、機能を除去せずに廃止予定としたものがほとんどであるが、OEBPS 1.2 が OPS バージョン 2.0 の完全互換サブセットであるわけではない。（例えば、XML の妥当性や名前空間処理など、新たな要件が追加されている。）

1.5: 拡張性

XML アイランドは、推奨ボキャブラリにない機能や情報や構造を追加するために推奨される（recommended）メカニズムである。

アウトオブライン XML アイランドはあらゆる出版物に使用してもよい（may）。インライン XML アイランドは XHTML 推奨ボキャブラリ以外を使用して記述されたドキュメントの中では使用してはならない（must not）。

1.6: アクセシビリティ

本仕様には、障害によって読書が困難な人によるコンテンツの利用を確保する機能が盛り込まれている。本仕様は World Wide Web Consortium (W3C) により進められた XHTML 1.1 のコンテンツアクセシビリティの機能を組み込んでいる。

OPS XHTML コンテントドキュメントは W3C Web Content Accessibility Guidelines 1.0（http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/）に従って記述されるべきである（should）。また、W3C の活動が継続すれば Web Content Accessibility Guidelines 2.0（ドラフトを http://www.w3.org/TR/WCAG20/ にて入手できる。）がリリースされ、より広範なユーザ層が OPS 形式の本を利用できるようになるだろう。

さらに、W3C HTML 4.0 Guidelines for Mobile Access （http://www.w3.org/TR/NOTE-html40-mobile/）の勧告と W3C Web Accessibility Initiative's proposed User Agent Guidelines （http://www.w3.org/TR/WD-WAI-USERAGENT/）が OPS の開発者により検証、改善されることで、リーディングシステムはアクセシビリティの要件に適合するものになるだろう。

1.7: 将来の方針

本仕様は現在の取り組みを将来の改良に活用するように作られている。本仕様の後続バージョンの詳細は未定であるが、Publication Structure Working Group は漸進的な発展が起こると予想している。 OPS のバージョン 2.0 を作り上げたテーマは、標準規格の遵守、アクセシビリティのサポート、広範な XML ドキュメントボキャブラリのサポート、ナビゲーションサポートの改良、そしてコンテンツ表示の忠実性の改善である。

将来のバージョンにとって重要と考えられるテーマには、他に次のものがある。コンテンツと表現のより厳密な分離、アクセシビリティの向上、コンテンツの国際的なサポート、リーディングデバイス固有の表示のコントロールやリーディングデバイスのプロフィール、出版物同士のリンクのサポートの改良、出版物内でのマークアップのレイヤー化された管理（例えば、印付け、ハイライト、メモ）、アプリケーション固有のマークアップ（例えば、数学記号、化学記号）、読み順の多様化、動的コンテンツのサポート（例えば、マルチメディアやスクリプトの実行）、全ての関連標準規格との提携の維持。さらに、本仕様の本バージョンの後方互換性を維持することには、高い優先度で取り組み続けなければならない。将来の方針については http://www.idpf.org にも記録されている。

2.0: OPS コンテントドキュメントボキャブラリ

2.1: イントロダクション

OEBPS 1.2 とそれに先行する "基本" ドキュメントのボキャブラリは、全てのリーディングシステムがサポートしている XHTML 1.1 ドキュメントタイプから採用されていた。本仕様ではもはや独自の XHTML 1.1 のサブセットを作成することはないが、代わりに XHTML Modularization 1.1 （http://www.w3.org/TR/xhtml-modularization/）に記載されている、全ての XHTML モジュールを参照している。 XHTML に加えて、OPS は DAISY の DTBook ドキュメントタイプ（http://www.niso.org/standards/resources/Z39-86-2005.html を参照）も推奨ボキャブラリに追加している。

本セクションでリストされた XHTML モジュールと DTBook ボキャブラリは OPS 推奨ボキャブラリとして扱われる。 "基本" および "拡張" ドキュメントの概念は、今後本仕様では用いられない。 OPS 出版物は推奨ボキャブラリを使用するべきである（should）。ドキュメントや XML フラグメントに他のボキャブラリを使用する出版物は、本仕様で説明されているインラインまたはアウトオブライン XML アイランドのメカニズムを使用しなければならない（must）。ここに挙げられている以外の XHTML モジュール（拡張モジュール）は、出版物の中で使用してもよい（may）が、本仕様書の XML アイランドのセクションにおいて説明されているガイドラインに従わなければならない（must）。

DOCTYPE 宣言が参照する DTD が存在する場合には、OPS XHTML コンテントドキュメントは、自身がその XHTML DTD に対して妥当でなければ、その DTD を参照してはならない（must not）。（すなわち、インライン XML アイランドやインライン SVG はこれには含まれない。）

2.2: OPS 推奨ボキャブラリにおける XHTML モジュール

2.2.1: 必須モジュール

OPS は適合するあらゆるリーディングシステムに、本仕様書に説明がない限り、 XHTML および HTML の仕様書において説明される形で、以下のモジュールをサポートすることを求める。

XHTML 1.1 モジュール名	要素（参考）
構造	body, head, html, title
テキスト	abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p, pre, q, samp, span, strong, var
ハイパーテキスト	a
リスト	dl, dt, dd, ol, ul, li
オブジェクト	object, param
プレゼンテーション	b, big, hr, i, small, sub, sup, tt
編集	del, ins
両方向テキスト	bdo
テーブル	caption, col, colgroup, table, tbody, td, tfoot, th, thead, tr
画像	img
クライアントサイドイメージマップ	area, map
メタ情報	meta
スタイルシート	style
スタイル属性（廃止予定）	style attribute
リンク	link
ベース	base

2.3: XHTML 1.1 と異なる意味や制約を持つ要素と属性

前述のとおり、XHTML 推奨ボキャブラリ（要素、属性、属性に関連する属性値）の動作や表示は、XHTML 1.1 に厳格に従っている。しかし、次に示すような XHTML 1.1 を越えた制約も存在する。これらの制約は OPS ドキュメントの XHTML 1.1 への適合性に効果を持たない。

2.3.1: URI 参照についての概評

多くの属性は参照するリソースに、 URI 値（Uniform Resource Identifier、RFC 2396 http://www.ietf.org/rfc/rfc2396.txt を参照。）を使用している。属性によっては、 URI の参照するリソースが抽象的な実体や物理的なオブジェクトであることもある。

注記が有る場合や適合性に反する場合を除き、リーディングシステムは、URI の参照する物理リソースとして、マニフェストに記載されていないもの（つまり、出版物のコンポーネントにないもの）を使用、表示してもよい（may）し、しなくともよい（not required）。

2.3.2: body 要素

書式設定において、body 要素のデフォルト表示は、CSS プロパティの page-break-before の値に right を指定した状態（単ページのリーディングシステムで、always を指定した状態と同じ）とされているが、この設定は適切なスタイルシートの宣言によって上書きしてもよい（may）。

2.3.3: cite 属性

cite は付加的な（optional）属性で、 blockquote、q、 del や ins などの要素が URI を引用する際に使用してもよい（may）。リーディングシステムは、参照された URI リソースがマニフェストに記載されているかに関わらず、そのリソースを処理、利用しなくてもよい（not required）。

2.3.4: img 要素

インライン要素の img は、GIF （http://www.w3.org/Graphics/GIF/spec-gif89a.txt）、 PING （RFC 2083）、 JPG/JFIF （http://www.w3.org/Graphics/JPEG）、 SVG （http://www.w3.org/TR/SVG11/）の OPS コアメディアタイプを持つ画像を参照する場合にのみ使用するべきである（should）。必須（required）属性である src は画像リソースを参照するために使用するが、そのリソースはマニフェストに記載されていなければならない（must）。

必須（required）属性である alt には、画像に関する簡潔な説明テキストを入れるべきである（should）。リーディングシステムはこのテキストを、画像の代わりに、または画像と共に表示する。また、このテキストは、src 属性に OPS コアメディアタイプではないものを参照する img 要素があり、マニフェストに利用できるフォールバックが記載されていない場合のフォールバックにもなる。 alt 属性の説明テキストは、ディスプレイ解像度や視覚表示に制限があるリーディングシステムにとって有用である。 object 要素は OPS コンテントドキュメントに OPS コアメディアタイプではないものを内包するための推奨メカニズムである。

長い説明文を用いる場合には、付加（optional）属性である title を使用してもよい（may）。リーディングシステムは、title 属性を、alt 属性のテキストや画像自体の代わりに表示してもよい（may）。

アクセシビリティの向上のために、OPS コンテントドキュメントの著者は、付加属性である longdesc に画像をより詳細に説明するリソース（出版物に含まれる別の OPS ドキュメントなど）への URI 参照を含めておくことを強く推奨する（strongly recommended）。また、リーディングシステムの開発者には、longdesc 属性に記述された参照を、（アクセシビリティを考慮して）適切に認識、表示することが、強く求められる。 longdesc 属性や関連するアクセシビリティ属性の使用に関しては、 http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#gl-provide-equivalents に、より多くの情報が掲載されている。

2.3.5: link 要素

link 要素は本仕様が他のドキュメントとの多様な関係を持つことを可能にする。リーディングシステムは、href 属性とそれに関連する rel 属性（rel="stylesheet" やrel="alternate stylesheet"のように値を指定する）によって指定された外部スタイルシートを認識しなければならない（must）。

2.3.6: object 要素と param 要素

object 要素は一般的なオブジェクトを内包するための推奨メソッドである。 OPS コアメディアタイプにないメディアタイプのオブジェクトを追加する場合や、 classid 属性を利用した object を参照する場合に、 object 要素は、他の object 要素や img 要素や説明テキストなどのフォールバック情報を指定しなければならない（must）。インラインのフォールバック情報は、親 object 要素を参照する param 要素の直後に記述された OPS コンテントとして提供される。 object 要素、インラインコンテントや内包された OPS コンテントドキュメントなどのメソッドの使用ついて、説明テキストは、テキスト以外のコンテンツを利用できない人々にも利用できるように提供されるべきである（should）。

object 要素の classid 属性は、その object 要素を実装するための URI 値を示す。 OPS に適合したリーディングシステムは、外部に実装されたオブジェクトを表示できるかもしれないが、必ずしも表示しなくてもよい（not required）。 codetype 属性と type 属性の MIME メディアタイプの値は出版物のマニフェストに指定されているものと一致しなければならない（must）。

関連要素である param 要素は空要素にすることで、オブジェクトの初期値を指定することができる。この param 要素は、表示可能な object 要素のコンテントよりも前にのみ記述されなければならない。リーディングシステムは object 要素の直接の子要素である param 要素だけを検証しなければならない。

例:

<object classid="clsid:AFAFAFA-0101-1010-0101-ABABABABABA"
        codebase="http://www.example.com/SomeScriptingLanguage/">
   <param name="code" value="TicTacToe.class">
   <param name="codebase" value="html/">
   <param name="type" value="application/x-somescriptinglanguage">
   <param name="model" value="models/TicTacToe.model">
   <param name="scriptable" value="true">
   <object type="image/png" data="tictactoe.png">
           Tic-Tac-Toe, a <em>dull</em> game.
   </object>
</object>

2.3.7: script 要素と noscript 要素

リーディングシステムは script 要素のコンテントを表示してはならず（must not）、そのスクリプト自体を実行するべきではない（should）。コンテントは script 要素を実行することなく、読めなければならない。

リーディングシステムがスクリプトを実行しないことを選択した際にメッセージを表示する noscript 要素は、関連する script 要素の終了タグの後に記述されなければならない（must）。デフォルト設定ではリーディングシステムは、script 要素を、（推奨（recommended）に従って）実行しなかった場合には、noscript 要素に含まれるコンテントを表示しなければならない（must）。このデフォルト設定は CSS の display:none で上書きすることができる。ここで注意すべきことは、XHTML 1.1 に適合した noscript のコンテントモデルは Block.mix 要素（ block level 要素と "level-independent" 要素）であり、テキスト要素やインライン要素を直接格納することはできないため、例え noscript 要素がインラインに登場しても、body 要素や blockquote 要素のコンテントモデルと同じように扱われてしまうことである。

script 要素のスクリプト言語を指定する type は必須（required）属性である。

コンテントモデルが #PCDATA である script 要素の抱える潜在的な問題は、コードに "<" や "&" の文字が含まれていた場合に、XML との潜在的な衝突が発生することである。従ってこれらの文字が使われる場合には、エスケープされるか CDATA 要素のセクションに置かれなければならない（must）。スクリプト実行機能を持つリーディングシステムの開発者は、この問題を認識している必要がある。

2.3.8: style 要素の type 属性

style 要素の type 属性は（XHTML 1.1 の要件において）必須（required）であり、値には text/css または廃止予定の text/x-oeb1-css を指定しなければならない（must）。 OPS コンテントドキュメントが XHTML 1.1 ドキュメントとしてブラウザに表示される際には、廃止予定の text/x-oeb1-css は text/css に置き換えられるべきである。

2.3.9: align 属性の値

align 属性の値である char は OPS XHTML サブセットに含まれてはいない。似たようなフォーマットを実現するには、CSS の text-align プロパティの値に string を指定すればよい。

2.4: DTBook 推奨ボキャブラリ

2.4.1: イントロダクション

DTBook はかつて ANSI/NISO Z39.86-2005 標準規格と呼ばれていた DAISY/NISO 標準規格にて定義されている XML ボキャブラリである。このボキャブラリは電子書籍コンテンツのために設計されている。脚注、補足記事、注記、ページ番号など、XHTML には見られない多くの仕組を持つ。原本となる印刷された出版物における各ページの開始位置やページ番号を識別できる為、NCX ナビゲーションは印刷された出版物のとおり各ページの開始位置にアクセスできる。一般的なリーディングシステムでは、表示するスクリーンのサイズによってページは変化してしまう。しかし印刷ページの情報が保持してあれば、ユーザは印刷された本と同じ位置まで移動することができる。

コンテンツ供給者は、教育分野の出版物や複雑な構造を持つ出版物に、この XML 推奨ボキャブラリを採用することを強く推奨する（recommended）。

2004年の The Individuals with Disabilities Education Improvement Act（IDEIA）や、それに類似する国際的な法律が制定された結果、多くの出版社は既に DTBook 形式でコンテンツを保有している可能性がある。DTBook は簡単に OPS 出版物に変換することができる。 DTBook のボキャブラリが出版物に利用できるようになったことで、印刷物を読むことが困難な生徒を含むあらゆる教育市場の生徒に向けて、出版社は出版物を販売しやすくなるだろう。

DAISY/NISO 標準規格の Section 4 は DTBook DTD を定義している。これは NISO のウェブサイト http://www.niso.org/standards/resources/Z39-86-2005.html で読むことができる。

DTD の課題調査やサンプルなどの追加情報は、DAISY のウェブサイト http://www.daisy.org/z3986/ で知ることができる。

2.4.2: DTBook の構文要件

DAISY/NISO 標準規格の Section 4 で説明されているとおり、DTBook は DTBook OPS 出版物に従わなければならない（must）。そのコンテンツは本稿執筆時の最新バージョンである dtbook-2005-2.dtd に適合しなければならない（must）。すべてのバージョンの DTD は DAISY website から利用することができる。そのため、あらゆる DTD のバージョンから作られた OPS 出版物が妥当であり続けることができる。

DTBook の諸要素の意味が正しく適用されていることは重要である。これを支援するために "構造ガイドライン" のセットが作成された。諸要素の意味を正しく適用するために、DTBook に適合したドキュメントは構造ガイドラインを利用するべきである（should）。構造ガイドラインは http://www.daisy.org/z3986/structure/ で読むことができる。

2.4.2.1: DAISY/NISO 標準規格 Section 4 の例外

DTBook では要素に smilref という単一属性がある。この属性は SMIL（http://www.w3.org/TR/2005/REC-SMIL2-20050107/）コーディネイションに使用される。 OPS 出版物では DTBook ドキュメントからこの属性を除いても、妥当性検証のエラーが発生することはない。

2.5: SVG

SVG は写真からではなく、ベクターグラフィックシステムから作られる地図、図表、グラフなどの画像である。これらの画像はベクター形式であり、直線、曲線、絶対的な位置情報を持つテキストブロックなどで表現される（これに対してラスター形式はピクセルの配列によって表現される）。ラスター画像をベクター画像に置き換えることでドキュメントへのアクセスや検索が容易になる。リーディングシステムと著者がこの点に注力することでドキュメントのアクセシビリティは大きく向上する。ベクター画像を採用すれば（拡大縮小が可能であるため）ドキュメントの表示品質も向上し、ファイルサイズも縮小されることが多い。

OPS リーディングシステムは OPS コアメディアタイプとして SVG （Scalable Vector Graphics）をサポートしなければならない（must）。

2.5.1: SVG の使用についての一般的な注釈

OPS は SVG 1.1 勧告を完全にサポートしている。唯一の例外は OPS がインタラクティブなコンテントを対象としていない点である。 SVG アニメーションとスクリプティングの機能はサポートされておらず、出版物の著者はこの機能を使用してはならない（must not）。リーディングシステムもこのようなコンテントを表示するべきではない（should not）。 SVG の CSS によるスタイリングは完全にサポートされなければならない（must）。

SVG 画像の中のテキストは選択や検索ができるべきである（should）。 SVG 画像はリンク（a 要素）を持ってもよい（may）ため、ナビゲーションに利用されるかもしれない。リーディングシステムがリンクによる "tabbing" をサポートしている場合、SVG のリンクもサポートされなければならない（must）。

インライン SVG は XHTML 推奨ボキャブラリを利用するドキュメントにおいてのみサポートされている。 DTBook ドキュメントでは XHTML 推奨ボキャブラリを使用してはならない（must not）。

2.5.2: 独立した画像ファイルとしての SVG の利用

OPS において、SVG コンテントは他の画像タイプが使用できる場所であればどこにでも使用できる。これには以下の参照方法が含まれる。

XHTML の img 要素と object 要素からの参照。
DTBook の img 要素からの参照。
SVG の image 要素からの参照。
画像の URI をパラメタに指定した CSS プロパティからの参照。

移植性を最大限に確保するために、SVG 画像の大きさはトップレベルの SVG 要素において指定するべきである（should）。参照する要素はビットマップ画像と同様に、SVG 画像の大きさを拡大縮小するために上書きしてもよい（may）。

スタイリングの目的のため、個々の SVG イメージは独立したドキュメントと見なされる。参照元ドキュメントのスタイルシートは、参照先の SVG 画像や SVG 画像が継承した CSS プロパティには適用されない。共通のスタイルを実現するには、SVG と XHTML のどちらからも参照されるスタイルシートを作成するべきである（should）。これは object 要素が XHTML の要素を参照する場合にもあてはまるため、注意が必要である。

2.5.3: 同一ドキュメント内での SVG と XHTML のマークアップの混用

SVG の別の利用法に XHTML のマークアップに SVG のマークアップを埋め込む方法がある。この SVG のルート要素（svg）は、CSS レイアウトのコンテントによって置き換えられるものと見なされなければならない（must）ため、svg 要素は XHTML の img 要素が使用できる場所であればどこに使用してもよい（may）。他の SVG の要素は svg 要素の子要素としてのみ、使用してもよい（may）。 SVG の要素と XHTML の要素では名前空間が異なるため、個々の要素で名前空間接頭辞や xmlns 属性を使用するなど、適切な名前空間を割り当てる工夫が必要であることに注意が必要である。

このケースでは、たったひとつのドキュメントとドキュメント全体（カスケードと継承を含む）に適用されるスタイルシートしか存在しない。通常では、個々の要素は自身に適用できるプロパティしか利用しない。ルート svg 要素の CSS レイアウトにおける役割が、display、float、position プロパティによって決定されるのは、img 要素の場合と同様である。 SVG 画像の大きさは、ルート svg 要素の width 属性と height 属性（これらは CSS ボックスレイアウトにおいて置き換えられた要素の固有の大きさになると考えられる）によって決定され、 CSS の width、 height のプロパティに割り当てられる。 "置き換えられた要素" と "固有の大きさ" の定義については、http://www.w3.org/TR/CSS2/conform.html を参照のこと。移植可能性のために、著者は XHTML 要素のみの CSS プロパティを SVG の要素に割り当てることは避けるべきであり（should）、逆の場合もまた然りである。

2.6: XML アイランド

本セクションでは、OPS 出版物における一般的な XML コンテントを組み込むのマークアップや処理モデルについて説明する。

2.6.1: XML アイランドのイントロダクション

本セクションでは、OPS 出版物における XML マークアップの組み込み方について定義する。 OEBPS 1.2 にて定義された OEBPS など、他の XML ボキャブラリとの互換性を過去から将来に渡り、可能な限り実現することが背景にある。

これは OEBPS 1.2 が公表した将来の方針とも一致する。

本ドキュメントでは "XML アイランド" という概念を導入する。これには二つの種類が存在する。

アウトオブライン XML アイランド
インライン XML アイランド

アウトオブライン XML アイランドは推奨ボキャブラリ（すなわち DTBook または XHTML）のいずれも使用していないか、推奨ボキャブラリを使用したドキュメントの内部で拡張モジュールを使用している、あらゆる完全な XML ドキュメントを指す。

インライン XML アイランドは、推奨されていないボキャブラリを使用しているか、OPS 出版物の XHTML 推奨ボキャブラリの内部で推奨ボキャブラリの拡張モジュールを使用している XML ドキュメントのフラグメントを指す。また、インライン XML アイランドは OPS 名前空間により名前空間の制約を受けており、object 要素には内包されない。

インライン XML アイランドは DTBook 推奨ボキャブラリを使用するドキュメントの内部に使用してはならず（must not）、 XHTML ドキュメントの内部に限って使用しなければならない（must）。

2.6.1.1: 使用例

以下は OPS における XML アイランドの利用を説明する例である。

後方互換性: 拡張 OEBPS 1.2 ドキュメントを使用した無数のドキュメントが新しいリーディングシステムで利用されると考えられる。 XML アイランドはこのようなドキュメントを、 OPS マニフェストへの若干の属性の追加や、単一の名前空間宣言の追加、スタイルシートの作成など、最小限の追加項目によって利用可能にする方法を説明する。
側方互換性: リーディングシステムで読まれるであろうドキュメントで非推奨 XML ボキャブラリを使用しているものは無数にある。この課題は上記と同じ方法を利用するか、基準となるリーディングシステムで OPS 推奨ボキャブラリのフォールバックを併用した際に利用できないメソッドについてディスプレイの動作をカスタマイズすることで達成することができる。非推奨 XML ボキャブラリを使用した無数のドキュメントがリーディングシステムで利用されると考えられる。この課題は上記と同じ方法を利用するか、基準となるリーディングシステムが OPS 推奨ボキャブラリのフォールバックを併用した際に利用できないメソッドの表示動作をカスタマイズすることで達成できる。
前方互換性: これまで存在しなかったボキャブラリを検証することができる。

2.6.1.2: 表示ガイドライン

OPS リーディングシステムは正確にマークアップされた XML アイランドを表示するために以下のステップに従わなければならない（must）。

Semantic Styling: リーディングシステムは、XML アイランドのコンテントを表示する際に、 OPS の要求水準以上の処理を行ってもよい（may）。これにはリーディングシステム固有の XML アイランドボキャブラリ情報によって表示機能を拡張することも含まれる。（すなわち TEI-reader や MathML reader など）
OPS へのフォールバック: リーディングシステムが、固有の XML アイランドボキャブラリの情報を持たない場合には、何らかのフォールバック機能を使用しなければならない（must）。

これによって非推奨ボキャブラリを含むコンテントに対して、リーディングシステムは標準化された方法で OPS の要求水準を上回る処理することが可能となり、標準的なリーディングシステムでもそのコンテントを適切な方法で処理することができる。

2.6.2: アウトオブライン XML アイランド

アウトオブライン XML アイランドは、推奨ボキャブラリで記述されていないか、推奨ボキャブラリのドキュメントで拡張モジュールを使用している、完全 XML ドキュメントである。アウトオブライン XML アイランドを組み込むには出版物の様々な箇所で宣言を記述することが必要である。

2.6.2.1: ドキュメント要件

アウトオブライン XML アイランドは、（自身のスキーマに対して）妥当な XML ドキュメントであり "アウトオブライン XML アイランドコンテントドキュメントの要件" に適合していなければならない。

簡潔なアウトオブライン XML アイランドを以下に示す。

<?xml version="1.0"?>
<!DOCTYPE example SYSTEM "example.dtd">
<example>
   <title>This Is An Example</title>
   <paragraph>This is a paragraph with a <huge>big</huge> section
   of text that could be styled with OPS CSS!</paragraph>
</example>

2.6.2.2: フォールバック要件

アウトオブライン XML アイランドを組み込む際には、アウトオブライン XML アイランドのボキャブラリを処理できないリーディングシステムのためのフォールバック情報として、特定の属性と値を出版物のマニフェストに記述しておく必要がある。 OPF 仕様書を参照のこと。

2.6.2.3: リンク要件

アウトオブライン XML アイランドへのリンクは適合したリーディングシステムによって以下のように解決されなければならない（must）。

2.6.2.3.1: ドキュメントレベルでのリンク

出版物のドキュメント自体へのリンクは、フォールバックドキュメントがあれば自動的にそのフォールバックドキュメントに解決されなければならない（must）。

リンク元:

...<a href=”"chapter2.xml”">Chapter 2</a>...

推奨ドキュメント - chapter2.xml:

        <chapter>
                <title>Chapter 2</title>
                ...
        </chapter>

フォールバックドキュメント - chapter2.html:

<html>
        <head>
                <title>Chapter 2</title>
        </head>
        <body>
                ...
        </body>
</html>

マニフェストフラグメント:

<item href="chapter2.xml" id="chapter2"
      media-type="text/xml"
      required-namespace="http://www.example.com/chapter"
      fallback="chapter2fallback"/>
<item href="chapter2.html" id="chapter2fallback"
      media-type="application/xhtml+xml"/>

この例では、二通りの処理が行われうる。リーディングシステムが chapter2.xml のドキュメント形式を処理できるならば、リンクは chapter2.xml に解決される。処理できない場合にはリンクは chapter2.xml のフォールバックである chapter2.html に解決される。

2.6.2.3.2: フラグメントへのリンク

ドキュメントフラグメントを含むリンクは、同じフラグメント識別子を使用したフォールバックアイテムに解決されなければならない（must）。フォールバックにフラグメント識別子が存在しない場合には、リーディングシステムはフォールバックドキュメントの冒頭に解決しなければならない（must）。

2.6.3: インライン XML アイランド

インライン XML アイランドは OPS 出版物において非推奨ボキャブラリを使用しているか、 XHTML 推奨ボキャブラリドキュメントの内部で推奨ボキャブラリの拡張モジュールを使用している XML ドキュメントフラグメントである。

インライン XML アイランドの処理は、処理要件と表示要件があるため、アウトオブライン XML ドキュメントの処理よりも複雑である。アウトオブライン XML アイランドは完全な XML ドキュメントであり、そのフォールバックのオプションは OPF Package Document にて定義されている。インライン XML ドキュメントはプログラミングの一般的な概念である "switch" 文を模したマークアップ構造を通して処理される。

2.6.3.1: switch 要素とその内包要素

switch 要素は SVG 1.1 や SMIL 2.x で使用される概念である。しかし OPS はこれらの仕様とは異なる要件を持つ。その結果 switch の概念は OPS では異なった形で実装されている。具体的に言えば、記述する意図が明確であることが求められるのである。さらに基本的なフォールバックのメカニズムが用意されている。switch 要素とその内包要素の規範的な定義は、 OPS スキーマで見ることができる。

switch 要素とその全ての内包要素は OPS 名前空間（http://www.idpf.org/2007/ops）に属する。

2.6.3.1.1: switch 要素

switch 要素はインライン XML アイランドに含まれる。 switch 要素は 0 個以上の case 要素を持ち、ひとつのdefault 要素を持たなければならない。これらの要素名には、多くのプログラム言語の "switch" 機能に慣れ親しんだ人にて理解しやすい名称が採用されている。

switch 要素を使用したマークアップの例を以下に示す。

<ops:switch id="mathmlSwitch">

   <ops:case required-namespace="http://www.w3.org/1998/Math/MathML">
      <math xmlns="http://www.w3.org/1998/Math/MathML">
         <mrow>
            <mn>2</mn>
            <mo>&InvisibleTimes;</mo>
            <mi>x</mi>
         </mrow>
         <mrow>
            <mo>+</mo>
            <mi>y</mi>
            <mo>-</mo>
            <mi>z</mi>
         </mrow>
      </math>
   </ops:case>

   <ops:default>
      <p>2x + y - z</p>
   </ops:default>

</ops:switch>

2.6.3.1.2: case 要素

case 要素は非推奨ボキャブラリや拡張モジュールのマークアップに使用する。 switch 要素の中には 0 個以上の case 要素が存在する。 case 要素は OPS 名前空間のコンテントを含まない。これは通常 case 要素が OPS 名前空間に属さないコンテントを含むことを妨げるものではない。

OPS リーディングシステムはドキュメントを無効としてはならず（must not）、 case 要素にコンテントがなければ何も表示してはならない（must）。

2.6.3.1.2.1: required-namespace 属性

required-namespace 属性は、リーディングシステムが case 要素のコンテントを処理するためにサポートしなければならない（must） XML ボキャブラリの名前空間を指定する。リーディングシステムは、自身がサポートする required-namespace 属性の値を持つ、最初の case 要素のコンテントを処理するべきである（should）。ここで注意すべきことは、余分な OPS XML ボキャブラリを処理する必要はない（not required）ことである。リーディングシステムはそのアイランドのフォールバック（default 要素）のみを処理しなければならない（must）。

XHTML 名前空間でルート要素を持つドキュメントは、そのドキュメントが SVG 名前空間で明示的に（すなわち SVG の metadata 要素として）許可されているか、対応する required-namespace 属性の値を持つ case 要素の子要素である場合を除いては、 XHTML 名前空間にない要素を使用してはならない（must not）。

2.6.3.1.2.2: required-modules 属性

XML ボキャブラリには、適合するアプリケーションがモジュールの一部または全体をサポートしてもよい（may）特殊なモジュールがある。これらのボキャブラリは、その仕様によって定義された名前のモジュール群を持ち、そのほとんどは付加的な（optional）ものである。付加的な（optional）モジュールは、本仕様では拡張モジュールとして見なされる。

リーディングシステムは、モジュール化された XML ボキャブラリの仕様が要求する最低限のモジュールまたは拡張モジュール以外の全てのモジュールをサポートしている場合に、そのボキャブラリをサポートしていると見なされる。

推奨ボキャブラリで記述されたインライン XML アイランドには当然、拡張モジュールが使用されている。この場合、拡張モジュールを利用した非推奨ボキャブラリのアイランドが有るならば、required-modules 属性は required-namespace 属性とともに記述されなければならない（must）。 required-modules 属性の属性値には、インライン XML アイランドに使用される拡張モジュールの名前をカンマ区切りで記述しなければならない（must）。これらのモジュール名は、その XML ボキャブラリの仕様に特に指定が無い限りは大文字小文字を区別しない。モジュール名に含まれるスペースは required-modules 属性値としてリストされる際に "-" に置き換えられなければならない（must）。 OPS のコンテキストでは XHTML のために拡張モジュールに、ruby、forms、 server-side-image-map、intrinsic-events が含まれている。

ここで注意すべきことは required-modules 属性値に非拡張モジュールの名前をリストすることもできるということである。これらのモジュールは、その XML ボキャブラリがサポートされているならば、常にサポートされていると見なされる。これは明確さのためにも、将来の仕様改定によって幾つかのモジュール（例えば、OPS で現在廃止予定となっている XHTML モジュールの STYLE 属性）が付加的な（optional）ものとなった場合のためにも、有用である。

非推奨ボキャブラリを使用したインライン XML アイランドを指定する case 要素に required-modules 属性を記述することは可能であるばかりか、非推奨ボキャブラリに使用される拡張モジュールを明確化し特定する上でしばしば有用でもある。

以下は required-modules 属性を使用して OPS のサポートするモジュールにない XHTML モジュールを指定する例である。

<ops:switch id="XHTMLServerSideSwitch" xmlns:ops="http://www.idpf.org/2007/ops">
        <ops:case required-namespace="http://www.w3.org/1999/xhtml"
                required-modules="server-side-image-map">
                <a href="http://www.example.com/examplemap.map">
                <img src="example.gif" ismap="ismap"
                        title="Example Map"
                        alt="A picture of an example." />
                </a>
        </ops:case>
        <ops:default>
                <img src="example.gif" usemap="map"
                        title="Example Map"
                        alt="A picture of an example." />
                <map name="map">
                        <area href="example1.html"
                                alt="Link to the first example."
                                shape="rect" coords="0,0,118,28" />
                        <area href="example2.html"
                                alt="Link to the second example"
                                shape="rect" coords="184,0,276,28" />
                </map>
        </ops:default>
</ops:switch>

2.6.3.1.3: default 要素

default 要素は case 要素に似ている。 default 要素の目的は switch 要素を表示する際の基準（またはフォールバック）となる正しいマークアップを提供することである。 default 要素が内包するのは、親である switch 要素がドキュメントに使用される箇所で許容された XML ノードのみでなければならない（must）。より正確に言えば、全ての switch 要素をその子である default 要素のコンテントに置き換えたものが妥当なドキュメントである場合に限り、そのドキュメントは妥当であると見なされる。

2.6.3.2: インライン XML アイランドの処理

インライン XML アイランドは switch 要素とその内包要素のマークアップ定義を処理しなければならない（must）。

2.6.3.3: インライン XML アイランドの表示

2.6.3.3.1: 高度な表示動作

リーディングシステムは case 要素を記述された順序で処理しなければならず（must）、サポートする case 要素から、最初に登場するもののコンテントを表示するべきである（should）。（すなわち、リーディングシステムは required-namespace 属性の指定するボキャブラリをサポートする。）リーディングシステムは switch 要素の中の case 要素または default 要素のひとつだけを表示し、他の case、default 要素は全て無視しなければならない。

case 要素のすべてのボキャブラリをサポートするリーディングシステムは、default 要素のコンテントを表示しなければならない（must）。

2.6.3.3.2: アイランドのスタイリング

インライン XML アイランドを持つドキュメントをスタイリングでは、ドキュメントツリーにスタイルシートのカスケードや継承ルールが利用される。しかし、OPS の switch、 case および default 要素は与えられたスタイリングのプロパティを全て無視しなければならない（must）。とりわけ、これらの要素は XHTML の要素のように（CSSのボックスレイアウトのような）ボックスを作成してはならない（must not）。

2.6.3.4: リンクの判定

様々な代替インライン XML アイランドは一意の id 属性を持つ要素を内包してはならないため、インライン XML アイランドのコンテントに深くリンクすることはできない。そのため表示するために選ばれた case 要素がなければ、参照を解決することはできない。

2.6.3.4.1: switch 要素へのリンク

リーディングシステムは、リンクのターゲットとなる switch 要素が表示上の特性を持っていなくとも、そのリンクを認識、表示しなければならない（must）。

2.6.3.4.2: 不完全なリンク

インライン XML アイランドへのリンクは、XHTML 準拠のブラウザが出すような警告やエラーを表示することなく、除かれなければならない（must）。

2.6.3.5: NCX 要件

NCX からインライン XML アイランドへのリンクは、インライン NCX 以外から XML アイランドへのリンクと同様に動作しなければならない（must）。

2.7: リーディングシステムでのドキュメントの表示

多くの要素や属性は、必ずしも全てのリーディングシステムが行う必要はない（not required）動作を認めている。例えばモノクロームのデバイスや、聴覚や触覚が中心となるインターフェイスを持つデバイスもありうる。本仕様ではこのような場合に、リーディングシステムは原則として推奨ボキャブラリが認める全ての（属性値のような）構文を受け付ける必要がある（required）が、必ずしもそれらを有効にする必要はない（not required）。例えば、リーディングシステムは table 要素の border 属性を解析、認識しなければならない（must）が、0 以外の全ての値を 1 として扱ってもよい（may）。

ここで注意すべきことは、本仕様は OPS 推奨ボキャブラリの表示について特定の動作を義務付けるものではないことである。リーディングシステムにはウェブブラウザの用法によって、要素の目的を表現することを選択できるものもある。例えば、段落の前の空白行を挿入するが、段落の最初の行のインデントは行わない、というように。また別のリーディングシステムは連載小説のような読みやすさに表示を調整できる。例えば、段落間に余白を設けないが、各段落の開始行はインデントする、というように。あるいは、スピーチジェネレイターのようなリーディングシステムでは、ドキュメントの一部のまたは全体の要素を、全く違った方法で表示する。

3.0: OPS スタイルシート

OPS スタイルシートは CSS スタイルシートと同様に大文字小文字を区別しないが、CSS の制御下にないパーツはその例外である。とりわけ、OPS コンテントドキュメントは XML ドキュメントであるため、要素名や属性値では大文字小文字を区別する。従って OPS スタイルシートにおいて OPS コンテントドキュメントと同じ要素名や属性値は大文字小文字を区別する。このことは現時点ではセレクタに使用される要素名、属性名、属性値にのみ適用されている。

CSS1 と CSS2 では構文の仕様に多くの違いがあるが、OPS スタイルシートは CSS2 の構文に従っている。これらの違いについては W3C 勧告 REC-CSS2-19980512 "Cascading Style Sheets, level 2 (CSS2) Specification" の section D3 にリストされている。 OPS スタイルシートはセミコロンで区切られた多重宣言による CSS の構築をサポートしている。従って以下のスタイルシートのルールは、

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

次に示すものと同義である。

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

同じ宣言ブロックが記述された複数のルールは、セレクタをカンマで区切った一つのルールに結合することができる。つまり、以下のルールは、

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

次のように結合しても同じ意味を持つ。

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

OPS スタイルシートは CSS の全ての空白文字をサポートする。具体的には、スペース(Unicode code 32)、タブ (9)、ラインフィード (10)、キャリッジリターン (13)、フォームフィード (12) は空白文字として表れる。 CSS2 仕様での構文のコメント OPS に適合した CSS スタイルシートでも使用してよい。

本仕様では、インラインの style 属性、XHTML の style 要素、（link 要素や xml-stylesheet 処理命令を介した）外部リンクスタイルシートをサポートしている。DTBook では CSS スタイルシートは xml-stylesheet 処理命令によってインクルードされる。従って、CSS によるスタイリングは XHTML と DTBook のどちらの推奨ボキャブラリで記述したドキュメントにも適用される。

本仕様ではセレクタが CSS2 仕様書における定義（詳しくは http://www.w3.org/TR/REC-CSS2/selector.html を参照）に従って使用されることを想定する。例えば、ドキュメントのスタイルシートにある複数のルールのどれを適用するかというルールは、継承ルール、カスケーディングルールそしてセレクタの特異性（詳しくは http://www.w3.org/TR/CSS2/cascade.html を参照）によって決定される。

XHTML OPS 要素に適用するスタイルシートが定義されていないか、適用できるスタイルが存在しない場合には、 XHTML の表示は本仕様と XHTML 1.1 仕様書に定義されたデフォルトのものになる。

本仕様はリーディングシステムにテキスト音読のような音声読み上げ技術の実装を求めるものではない（not require）。読み上げ技術を持たないリーディングシステムは、本仕様が "聴覚スタイルシート" として分類した CSS プロパティや "Tables" の下にリストされた speak-header プロパティをすべて無視してもよい（may）。

CSS に定義された全てのプロパティは要素に適用される。ほとんどのプロパティは全ての要素に適用することができるが、display プロパティの値に基づくものについては制限がある。（例えば、display type が block であり inline でない場合に限り、text-align プロパティは適用される。）しかしリーディングシステムは全ての特性をサポートする必要はない（not required）。例えば border-width の値をプロパティの指定値に割り当ててもよい（may）。

3.1: セレクタ

セレクタは対象となるドキュメントの中のマッチしなければならない（must）パターンを特定して、宣言ブロックに書かれたスタイル宣言を適用する要素を決定する。ある要素に対するパターンの全ての条件が真であるならば、セレクタはその要素にマッチして宣言ブロックに書かれた宣言を適用する。本仕様は CSS2 仕様書の全てのセレクタが使用されることを想定している。リーディングシステムは全ての CSS2 のセレクタをサポートしなければならない（must）。

3.2: 値の型

3.2.1: URI 値

URI 値を持つプロパティのために、URI は適切なメディアタイプのドキュメントを示さなければならない（must）。参照されるドキュメントは OPF パッケージドキュメントのマニフェストに含まれなければならない（must）。

3.2.2: 整数と実数

実数は number によって、整数値は integer によって表される。いずれも（"+" または "-" の）付加的な（optional）符号を持つことができるが、プロパティによっては数値の範囲や符号の使用に制限がある。

3.2.3: 長さ

座標値やサイズ値がゼロでない場合には、特定の単位を持たなければならない（must）。 CSS1 および CSS2 では以下の単位をサポートしている。

px	ピクセル
ex	現在のフォントの x-height
em	現在のフォントのサイズ
pt	ポイント
in	インチ
cm	センチメートル
mm	ミリメートル
pc	パイカ

3.2.4: パーセンテージ

パーセンテージの単位をサポートしていれば、CSS 仕様書がパーセンテージを許容値としているプロパティに利用することができる

3.2.5: 色

現在のブラウザは多くの色名キーワードをサポートしている。 XHTML 1.1 では数値とともに 16 の色名が定義されている。OPS スタイルシートでは全ての CSS2 の書式を使用してもよい（may）が、表示する際にこれらの色を全て区別する必要はない（not required）。（さもなければ趣旨に反して、モノクロームのデバイスが不適合とされてしまう。）

Black
White
Aqua
Blue
Fuschia
Gray
Green
Lime
Maroon
Navy
Olive
Purple
Red
Silver
Teal
Yellow
#rrggbb	6桁の16進数
#rgb	3桁の16進数
rgb(r, g, b)	0 から 255 の範囲の整数
rgb(r%, g%, b%)	0.0% から 100.0% の範囲の浮動小数

3.2.6: 時間

CSS2 で定義されている単位をサポートする。

s	秒
ms	ミリ秒

3.2.7: 周波数

CSS2 で定義されている単位をサポートする。

Hz	ヘルツ
kHz	キロヘルツ

3.2.8: 文字列

文字列はシングルクオートまたはダブルクオート（それぞれ Unicode コード 39、 34）で囲まれなければならない（must）。ネストされた文字列はバックスラッシュでエスケープされなければならない（must）（例えば " a \"nested\" string" のように）。改行を埋め込むにはエスケープ文字に "\A" を使用する。16進数の "A" は Unicode の改行文字であるが、CSS では改行文字の総称を指す。

3.3: プロパティ

サポートされた全ての CSS プロパティのデフォルト値は CSS2 にリストされているとおりのものである。

以下は本仕様がサポートする CSS プロパティと値の一覧表である。プロパティに対して CSS2 の仕様書にある値がリストされていないものがあるが、リストされていない値について本仕様はサポートしていない。 “Alternate display”の列は、リーディングシステムが意図されたとおりの表示が出来ない場合に、フォールバックとして表示できる CSS の値を示す。

本仕様固有のプロパティはアンダーラインで示す。

CSS Structure	Alternate Display	対応する CSS2 仕様書のセクション
Media Types		7
@media		7.2.1
aural		7.3
all		7.3
Page Model		13.2
@page		13.2
:left		13.2.4
:right		13.2.4
:first		13.2.4
Box Model		8
Margins		8.3
margin-top, margin-bottom, margin-left, margin-right		8.3
<length>
<percentage>
margin [2]		8.3
auto	0 [1]
Padding		8.4
padding-top, padding-bottom, padding-left, padding-right		8.4
<length>
<percentage>
padding [2]		8.4
Borders		8.5
border-top-width, border-bottom-width, border-left-width, border-right-width		8.5.1
thin
medium
thick
<length>	thin/medium/thick [3]
border-width [2]	thin/medium/thick [3]	8.5.1
border-top-color, border-bottom-color, border-left-color, border-right-color		8.5.2
<color>	[4]
transparent
border-color [2]		8.5.2
border-top-style, border-bottom-style, border-left-style, border-right-style		8.5.3
none
hidden
dotted	solid
dashed	solid
solid
double	solid
groove	solid
ridge	solid
inset	solid
outset	solid
border-style [2]		8.5.3
border-top, border-bottom, border-left, border-right [2]		8.5.4
border [2]		8.5.4
Visual Display Model		9
display [5]		9.2.5
none
inline
block
run-in
table
inline-table
table-row-group
table-header-group
table-footer-group
table-column-group
table-row
table-column
table-cell
table-caption
inherit
oeb-page-head [6]
oeb-page-foot [6]
float		9.5.1
left
right
none
inherit
clear		9.5.2
none
left
right
both
inherit
direction		9.1
ltr
rtl
inherit
unicode-bidi		9.1
normal
embed
bidi-override
inherit
oeb-column-number [13]
auto
<integer>	1
Visual Formatting Model Details		10
width		10.2
<length>
<percentage>
auto
inherit
min-width		10.4
<length>
<percentage>
inherit
max-width		10.4
<length>
<percentage>
auto
inherit
height		10.5
<length>
<percentage>
auto
inherit
min-height		10.7
<length>
<percentage>
inherit
max-height		10.7
<length>
<percentage>
none
inherit
line-height		10.8.1
normal
<number>
<length>
<percentage>
inherit
vertical-align		10.8.1
baseline
sub
super
top
text-top	[7]
middle
bottom
text-bottom	[8]
inherit
Generated Content, Automatic Numbering, and Lists		12
content [9]		12.2
<string>
inherit
list-style-type		12.6.2
none
disc
circle
square
decimal
decimal-leading-zero
lower-roman
upper-roman
lower-greek	Decimal
upper-greek	Decimal
lower-alpha
lower-latin
upper-alpha
upper-latin
hebrew	Decimal
armenian	Decimal
georgian	Decimal
cjk-ideographic	Decimal
hiragana	Decimal
katakana	Decimal
hiragana-iroha	Decimal
katakana-iroha	Decimal
inherit
list-style-position		12.6.2
inside
outside
inherit
list-style [2]		12.6.2
Paged Media		13
page-break-before		13.3.1
auto
always
avoid
left	[10]
right	[10]
inherit
page-break-after		13.3.1
auto
always
avoid
left	[10]
right	[10]
inherit
page-break-inside		13.3.1
auto
avoid
inherit
orphans		13.3.3
<integer>
inherit
widows		13.3.3
<integer>
inherit
Colors and Backgrounds		14
color		14.1
<color>	[4]
inherit
background-color		14.2.1
<color>	[4]
transparent
inherit
Fonts		15
font-family		15.2.2
<family-name>
sans-serif
serif
monospace
inherit
font-style		15.2.3
normal
italic	[11]
oblique	[11]
inherit
font-variant		15.2.3
normal
small-caps
font-weight		15.2.3
normal
bold
100-900	[3]
inherit
font-size		15.2.4
xx-small
x-small
small
medium
large
x-large
xx-large
smaller
larger
<length>	[3]
<percentage>	[3]
inherit
font [2]		15.2.5
Text		16
text-indent		16.1
<length>
<percentage>
inherit
text-align		16.2
left
right
center
justify
inherit
text-decoration		16.3.1
none
line-through
underline
inherit
white-space		16.6
normal
pre
nowrap
inherit
Tables		17
caption-side		17.4.1
top
bottom
left
right
inherit
table-layout		17.5.2
fixed
auto
inherit
speak-header		17.7.1
once
always
inherit
Aural Style Sheets		19
volume		19.2
silent
x-soft
soft
medium
loud
x-loud
<percentage>	[3]
0−100	[3]
inherit
speak		19.3
normal
none
spell-out
inherit
pause-before		19.4
<time>
<percentage>
inherit
pause-after		19.4
<time>
<percentage>
inherit
pause [2]		19.4
cue-before		19.5
<uri>
none
inherit
cue-after		19.5
<uri>
none
inherit
cue [2]		19.5
speech-rate		19.8
x-slow
slow
medium
fast
x-fast
faster
slower
<number> [12]
inherit
voice-family		19.8
male
female
child
inherit
pitch		19.8
x-low
low
medium
high
x-high
<frequency>
inherit
stress		19.8
0-100
inherit
richness		19.8
0-100
inherit
speak-punctuation		19.9
code
none
inherit
speak-numeral		19.9
digits
continuous
inherit

[1] リーディングシステムは、margin プロパティに規定値である auto から 0 の範囲で値を指定してもよい（may）。

[2] これはプロパティの省略記法である。値を指定する構文は CSS2 仕様書に示されている。本仕様が値を制限したり、このプロパティによって省略されたプロパティの代替表現を示していれば、このプロパティに対して同様の制限や代替表現が適用される。

[3] リーディングシステムは、このプロパティにリストされたキーワード値を割り当ててもよい（may）。

[4] 色の単位については Section 3.2.5 を参照。

[5] CSS2 は様々なテーブルの値とその正しい表示について完全な解説を提供している。テーブルの値に関する詳解は CSS2 テーブルの仕様書（http://www.w3.org/TR/REC-CSS2/tables.html）を参照。

CSS2 と XHTML はテーブルデータの表示について、互いに似通っているが僅かに異なるアルゴリズムを持つ。いずれのアルゴリズムも同じ結果を返すが、幾つかの例外がある。この場合、適合リーディングシステムは CSS2 側の仕様によるアルゴリズムと一致するように結果を出力しなければならない（must）。

テーブルを使用する際、著者はウェブアクセシビリティガイドライン（http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/）の手法に従って可能な限り多くの情報を保持するべきである（shuold）。この文書には、いつどのようにしてテーブルのタグ群を選択し、いつ CSS プロパティを使うのかを学ぶことができる優れた演習が掲載されている。具体的には "Guideline 5: Create tables that transform gracefully"（http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#gl-table-markup）を参照。

[6] display:oeb-page-head を割り当てられた要素のコンテントはヘッダとしてのみ表示されるべきであり（should）、display: oeb-page-foot を割り当てられた要素のコンテントはフッタとしてのみ表示されるべきである（should）。いずれもインラインやブロックであるかのように単純に表示されるべきではない（should）。しかしリーディングシステムは通常の印刷された出版物のようにヘッダやフッタを特別な領域に表示してもよいし、別の方法で表示してもよい。例えば小さなスクリーンのデバイスでは、ヘッダやフッタを必要な時にポップアップさせるかもしれない。ページレイアウトのために、これらの display の値は絶対位置を持つブロックボックスに似ている。（具体的には、position プロパティの値が fixed や absolute である。）つまり、これらは通常のフロウから切り離され、固有のフロウを持つ新たなブロックボックスが作成されるのである。 Margins や Padding や他のブロックの特性は、その要素が position: fixed の組み合わせを持っているかのように決定される。

先行する何らかのコンテントが表示され続けている間は、display: oeb-page-head や display: oeb-page-foot を割り当てられた要素は、有効であると見なすべきではない（shall not）。例えば、適切なスタイルが設定されたスクリーンに表示する際に、以下のような myhead クラスの div 要素は、先行する div 要素が全て表示された直後にページヘッダとなる。

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

このようなヘッダ（やフッタ）は、代わりに別のヘッダ（やフッタ）が有効となるか、親要素に表示し続けるものがなくなる（上記の例で言えば、div 要素が表示されなくなった時）かのいずれかが起こらない限り有効である。

[7] リーディングシステムは top に割り当ててもよい（may）。

[8] リーディングシステムは bottom に割り当ててもよい（may）。

[9] @media の値が aural 以外であるスタイルシートの内部では使用してはならない（must not）。

[10] 単ページのリーディングシステムは left と right を always として扱わなければならない（must）。

[11] リーディングシステムは italic と oblique を互いに区別する必要はない（need not）。

[12] 一分間に読み上げる単語の数を指定する。

[13] コンテントを表示するカラムの数を指定する。全てのブロックレベルの要素に適用してもよい（may）。リーディングシステムは 1 以外の整数値をサポートしても、これらの要素に 1 を割り当ててもよい（may）。リーディングシステムはカラムのバランス化をサポートしてもよい。値に auto を指定すると、リーディングシステムが、利用できる幅やフォントサイズなどの可読性に関する基準を考慮して、コンテントを表示するのに最適なカラム数を決定することを許可する。

3.4: 埋め込みフォント

著者がテキストの体裁を制御できるようにするために、OPS は CSS2 の font-face at-rule (@font-face) をサポートしている。 CSS2 勧告の section 15.3.1 を参照のこと。サポートしなければならない（must）フォント記述子を以下に示す。

font-family
font-style
font-variant
font-weight
font-size
src

移植性のために、著者は他の記述子を使用してはならない（must not）。フォントファイルは Unicode 文字を表示するために必要な情報を全て持たなければならない（must）。フォントはテキストの意味を変えてしまうような（例えば、"A" の文字に有害物質記号を割り当てる）Unicode 文字のマッピングをしてはならない（must not）。コンテンツの作成者は特定のフォント形式がサポートされることを想定してはならない（must not）。フォントは src 識別子のファイルリストを使用することで、複数の形式を組み込むことができるが、最初にサポートする形式を使用するべきである（should）。リストは常に最低一つはオープンタイプ形式のファイルを持つべきである（should）。リーディングシステムはオープンタイプ形式をサポートすることが望ましいが、適合性の要件ではない。リーディングシステムは埋め込みフォントを全くサポートしなくてもよい（may）。コンテンツの作成者はフォールバック時のフォントを指定するために、font-family プロパティにカンマ区切りリストを使用するべきである（should）。

コンテンツ作成者はオ－プンタイプ（や他の形式の）フォントのエンコードについて、常に利用上の制約を引き受けなければならない（must）。 "埋め込み禁止" のフォントを OPS 出版物に組み込んではならない（must not）。

OPS 出版物に組み込まれたあらゆるフォントファイルは、OPF の manifest に適切なメディアタイプを持たなければならない（must）。