原文:
Open Packaging Format (OPF) 2.0 v1.0
公開日:
2009-12-09
最終更新日:
2010-11-14
翻訳者:
ろす

Open Packaging Format (OPF) 2.0 v0.9871.0

2007年7月11日付勧告仕様書

目次

1.0: 概論

1.1: 目的と適用範囲

1.2: 定義

1.3: 他の仕様との関係

1.3.1: XML との関係

1.3.2: XML 名前空間との関係

1.3.3: ダブリンコアとの関係

1.3.4: Unicode との関係

1.4: 適合性

1.4.1: パッケージの適合性

1.4.1.1: パッケージの適合性

1.4.1.2: 出版物の適合性

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

1.4.3: OPF Version 2.0 の互換性

1.5: Accessibility

2.0: OPF パッケージドキュメント

2.1: パッケージアイデンティティ

2.2: 出版物メタデータ

2.2.1: <title> </title>

2.2.2: <creator> </creator>

2.2.3: <subject> </subject>

2.2.4: <description> </description>

2.2.5: <publisher> </publisher>

2.2.6: <contributor> </contributor>

2.2.7: <date> </date>

2.2.8: <type> </type>

2.2.9: <format> </format>

2.2.10: <identifier> </identifier>

2.2.11: <source> </source>

2.2.12: <language> </language>

2.2.13: <relation> </relation>

2.2.14: <coverage> </coverage>

2.2.15: <rights> </rights>

2.3: マニフェスト

2.3.1: フォールバックアイテム

2.3.1.1: OPS コアメディアタイプではないアイテム

2.3.1.2: アウトオブライン XML アイランドのアイテム

2.4: スパイン

2.4.1: 宣言型目次 − NCX

2.4.1.1: イントロダクション

2.4.1.2: キー NCX の要件

2.4.2: 出版物の構文における NCX の例外

2.4.3: スパインにおける XML アイランド

2.5: ツアー [廃止予定]

2.6: ガイド

附録 A: OPF パッケージスキーマ

附録 B: 貢献者

附録 C: 謝辞

附録 D: サポート情報とエラッタ

1.0: 概説

1.1: 目的と適用範囲

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

  • 出版ツールの供給者とコンテンツ供給者(例えば、出版社や著者などの発表するべきコンテンツの持ち主)に、多様なリーディングシステム上で電子コンテンツを、忠実で、アクセスしやすく、適切に表示するための最小限の共通ガイドラインを示すこと。
  • 既存のコンテンツ形式の標準規格を組み込むこと。
  • コンテンツを記述するための標準手段を定義し、電子書籍が流通網をスムーズに流れるようにすること。

本書である Open Packaging Format (OPF) 仕様書は 様々な OPS 出版物同士を結びつけて、電子出版物に付加的な構造や意味を持たせるメカニズムを定義する。

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

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

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

1.2: 定義

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

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

廃止予定[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)。

OCF

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

OEBPS

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

OPF

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

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

OPS 出版物についての説明と、OPF パッケージドキュメント自身を除く全てのファイルを参照を行う XML ドキュメントを指す。 OPF パッケージドキュメントは出版物の全てのファイルを識別して、それらのファイルについての説明情報を提供する。 OPF パッケージドキュメントは本仕様書において定義されており、ここで定義された OPF パッケージスキーマに対して妥当である。

OPF パッケージドキュメントの "ルートファイル" は、拡張子に .opf使用するべきである(should)。この XML ファイルは XML の一般エンティティのメカニズムを利用して、他の XML ファイルを参照してもよい(may)が、それらのファイルには .opf のファイル拡張子を使用してはならない(must not)。 このような構成は長大な出版物の OPF パッケージドキュメント を簡潔に作成するために用いられる。 しかし、最も一般的なケースでは OPF パッケージドキュメントは .opf の拡張子を持つ単一の XML ファイルである。

OPS

本標準規格の姉妹規格である Open Publication Structure は OPS コンテントドキュメントの構成に必要なマークアップを定義する。

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

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

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

OPS 仕様書において定義された、全てのリーディングシステムがサポートしなければならない(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 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/)に適合していなければならない。

1.3: 他の仕様との関係

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

  1. Extensible Markup Language (XML) 1.1 (Second Edition) specification (http://www.w3.org/TR/xml11/)
  2. Namespaces in XML 1.0 (Second Edition) (http://www.w3.org/TR/xml-names11/)
  3. The OPS Specification (http://www.idpf.org/ops/ops2.0/download/)(日本語訳
  4. XHTML™ 1.1 - Module-based XHTML - Second Edition specification (http://www.w3.org/TR/xhtml11/)
  5. Specifications for the Digital Talking Book (DTB) (http://www.niso.org/standards/resources/Z39-86-2005.html)
  6. Dublin Core Metadata Element Set, Version 1.1 specification (http://dublincore.org/documents/2004/12/20/dces/) および the MARC relator code list (http://www.loc.gov/marc/relators/)
  7. Unicode Standard, Version 4.0. Reading, Mass.: Addison-Wesley, 2003 新たなバージョンの発表によって時折アップデートされる。(標準規格と Unicode Character Database に関する最新バージョンと他のバージョンの追加情報については http://www.unicode.org/unicode/standard/versions を参照。)
  8. Particular MIME media types (http://www.ietf.org/rfc/rfc4288.txt およびhttp://www.iana.org/assignments/media-types/index.html)
  9. Web Content Accessibility Guidelines 1.0 (http://www.w3.org/TR/WCAG10/)
  10. RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. (http://www.ietf.org/rfc/rfc2119.txt).

1.3.1: XMLとの関係

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

  • リーディングシステムは XML 1.1 の定義する XML プロセッサでなければはならない(must)。 すべての OPF パッケージドキュメントは、OPF パッケージスキーマに従った妥当な XML ドキュメントでなければはならない(must)

1.3.2: XML 名前空間との関係

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

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

OPF パッケージドキュメントの名前空間は http://www.idpf.org/2007/opf であり、全ての OPF パッケージドキュメントのルート要素で宣言されなければならない。さらに、OPF 2.0 パッケージとして処理されるには、package 要素の version 属性値に 2.0 を指定しなければならない。version 属性を省略した package 要素は OEBPS 1.2 パッケージとして処理されなければならない(must)

例:

 <package version="2.0" xmlns="http://www.idpf.org/2007/opf">
                ...
 </package>

1.3.3: ダブリンコアとの関係

ダブリンコアのメタデータは、充分に有用なメタデータを提供しながらも、著者や出版社のカタログ作りの負担を最小化するように設計されている。本仕様は Dublin Core 1.1 メタデータの要素セット(http://dublincore.org/documents/2004/12/20/dces/)をサポートしており、より詳細で有用な情報を格納した領域を示す追加属性によって補完している。 例えば、ダブリンコアの creatorcontributor 要素に OPF は role 属性を追加することで、relator code が表す貢献者の役割などの出版物における貢献者の情報を、より詳細に記述することができる。

コンテンツ供給者は Section 2.2 において定義されたメタデータ要素の最小セットを 内包しなければならず(must)、さらには読者が関心のある出版物を発見するための付加的なメタデータも併せ持つべきである(should)

1.3.4: Unicode との関係

OPF パッケージドキュメントは 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/ を参照) を 利用する必要がある(may)

1.4: 適合性

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

このセクションでは OPF パッケージドキュメントとそれを処理するリーディングシステムとの適合性について定義する。

1.4.1: パッケージの適合性

本仕様は 個々の OPF パッケージドキュメントの適合性と、単一の OPF パッケージドキュメントを含むファイルの集合体の総称である OPS 出版物の適合性の両方について定義する。

1.4.1.1: パッケージの適合性

適合性を持つ OPF パッケージドキュメントは以下の必要条件を満たさなければならない(must)

  1. (XML 1.1 によって定義された) 整形式の XML ドキュメントであること。
  2. UTF-8 または UTF-16 にエンコードされていること。
  3. 附録 A において定義されている OPF パッケージスキーマに従った妥当な XML ドキュメントであること。
  4. 一つ以上の XML ファイルで構成されていてもよい(may)が、ファイル拡張子 .opf使用してもよい(may)ファイルはたった一つである。

1.4.1.2: 出版物の適合性

以下の場合にファイルの集合体は OPS 出版物であると見なされる。

  1. 前述したパッケージの適合性に従った単一の OPF パッケージドキュメントを持つこと。
  2. 出版物の中でファイル拡張子 .opf使用してもよい(may)ファイルは一つきりである。このファイルが存在するならば、それは OPF パッケージドキュメントの "ルートファイル" でなければならない(must)
  3. OPF パッケージドキュメントは、OPS 出版物の中で OPF パッケージドキュメント自身を構成するファイルを除いた個々のファイルが登録されたマニフェストエントリを一つだけ持つこと。
  4. 出版物の個々のファイルについてのマニフェストエントリは、それぞれのファイルの MIME メディアタイプ(http://www.ietf.org/rfc/rfc2046.txt を参照)を指定すること。
  5. マニフェストエントリに OPS コアメディアタイプのいずれかを指定した個々のファイルはそれぞれの MIME メディアタイプに適合していること。
  6. OPF パッケージドキュメントのスパインに記述された個々のファイルは OPS 仕様書の定義する OPS コンテントドキュメントの要件に適合していなければならない(must)
  7. NCX を持たなければならない(must)
  8. metadata 要素や廃止予定である dc-metadata 要素は identifier 要素と title と、タブリンコアタグセットから選ばれた language 要素を、それぞれ少なくとも一つ持つこと。
  9. package 要素の unique-identifier 属性は、ダブリンコアの identifier に正しく合致した XMLの IDREF であること。
  10. ダブリンコアで creator 要素と contributor 要素の OPF 拡張属性である role に指定されたあらゆる拡張値は、MARC Relator Code list に登録されたものであるか、oth. から始まる値でなければならない(must)
  11. guide 要素が持つ type 属性に指定されたあらゆる拡張値は、other. から始まる値であること。
  12. package 要素の version 属性の値には 2.0 を指定すること。
  13. package 要素の名前空間は http://www.idpf.org/2007/opf でなければならない。

本仕様書と OPS 仕様書は OPF パッケージドキュメントと OPS コンテントドキュメントにさらなる適合上の制約を設ける。

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

本仕様は OPS 出版物を扱うリーディングシステムの適合性を定義する。OPS コンテントドキュメントには OPS 仕様書にもさらなる適合要件が定義されている。 リーディングシステムは以下のようにドキュメントを処理する場合に限り、適合しているとされる。

  1. OPF パッケージドキュメントが与えられた時に、リーディングシステムは以下のことをしなければならない(must)
    1. 本仕様書の Section 2 に記載された全ての要素と属性を処理すること。
    2. 本仕様書の Section 2 に記載のない全ての要素と属性を無視すること。
    3. 前述のセクション XML 名前空間との関係 が定義する、適切な名前空間の指定があることを検証すること。
  2. OPF スパインによるナビゲーションがある場合には、リーディングシステムは OPS コンテントドキュメントではないコンテントを表示してはならない(must not)
  3. OEBPS 1.2 パッケージが与えられた場合には、リーディングシステムは OEBPS 1.2 に適合するリーディングシステムと同じようににこれを処理しなければならない(must)。ここで注意しなければならないことは、OEBPS 1.2 のリーディングシステムのように処理されなければならない(must)のは OEBPS 1.2 パッケージだけであって、そのパッケージ内部で参照されるコンテントドキュメントではないことである。
  4. OEBPS 1.2 出版物が与えられた場合には、リーディングシステムはOEBPS 1.2 に適合するリーディングシステムと同じようににこれを処理するべきである(should)。このようなリーディングシステムは、"後方互換適合性"として、リーディングシステムの適合性について任意の水準を要求することができる。

1.4.3: OPF Version 2.0 の互換性

OPF のバージョン 2.0 は実質的には"新規の"仕様ではない。しかしバージョン 2.0 には OEBPS バージョン 1.2 からの多くの変更点の中で、ある重要な機能拡張が加えられている。具体的には以下に示すものが、もっとも重要な追加部分である。

  • XML 1.1 が取り入れられたこと。
  • XML 名前空間処理が必要になった(required)こと。
  • 出版物のナビゲーションとアクセシビリティの向上のために、DAISY の Navigation Center eXtended (NCX) が加えられたこと。
  • ダブリンコアの XML 実装勧告に従い、ダブリンコアの要素名は小文字で表記しなければならなくなった(must)こと。
  • tours 要素が廃止予定とされたこと。

OEBPS 1.2 から OPF 2.0 への変更の多くは既存機能を撤廃するよりも廃止予定とすることでなされているが、 OEBPS 1.2 パッケージは OPF 2.0 の完全互換サブセットではない(例えば新たに、名前空間処理が必要とされたように)。

1.5: 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) are incorporated into this specification.

Publications should be authored in accordance with the W3C Web Content Accessibility Guidelines 1.0 (http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/) or, if it is released while the Working Group is active, the Web Content Accessibility Guidelines 2.0 (the current draft is available at http://www.w3.org/TR/WCAG20/) to ensure that the broadest possible set of users will have access to books delivered in 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/) ought to be reviewed and applied by OPF implementers to ensure that Reading Systems will be in conformance with accessibility requirements.

2.0: OPF パッケージドキュメント

本仕様に適合する出版物は、OPS出版物を構成するOPS コンテントドキュメント、画像やその他のオブジェクトとそれらの相互関係を XML によって記述した OPF パッケージドキュメントを一つだけ持たなければならない(must)

OPF パッケージドキュメントは、出版物を構成するファイル群の中から容易く識別できるように、ファイル名を .opf 拡張子で終えるべきである(should)。OPS パッケージドキュメント *1 の MIME メディアタイプは application/oebps-package+xml である。本仕様ではファイル群を(zip や tar などを利用して)一つの転送用データに物理的にビルドする方法を定義しない。その機能は OEBPS Container Format (OCF) の仕様にて定義されている。

本仕様は出版物に OPF パッケージスキーマを除外することも、内包することを要求するものでもない。

OPF パッケージドキュメントの主要なパーツには以下のものがある。

パッケージ名

その OPS 出版物全体の一意な識別子。

メタデータ

出版物メタデータ(タイトル、著者、出版社など)。

マニフェスト

出版物を構成するファイルのリスト(ドキュメント、画像、スタイルシートなど)。 このマニフェストは、本仕様がサポートしないファイルタイプのフォールバック宣言も持つ。

スパイン

読み順に従ってドキュメントを配置したもの。

ツアー(廃止予定)

様々な目的や専門家レベルの読者のために用意された選択的ビューのような、出版物の代替的な読み順。

ガイド

目次、序文、文献目録などのような、出版物の基盤構造的な部分への参照。

OPF パッケージドキュメントは OPF パッケージスキーマ(附録 A)に 適合した、妥当な XML ドキュメントでなければならない(must)。パッケージの簡単な概要を以下に示す。

<?xml version="1.0"?>
<package version="2.0" xmlns="http://www.idpf.org/2007/opf" unique-identifier="BookId">
        metadata
        manifest
        spine
        guide
</package>

以下のセクションでは OPF パッケージドキュメントのパーツについて説明する。

2.1: パッケージアイデンティティ

package 要素は OPF パッケージドキュメントのルート要素である。他のあらゆる要素はその下にネストされる。

package 要素は自身の unique-identifier 属性の値を指定しなければならない(must)unique-identifier 属性値は Section 2.2.10 に示すダブリンコアのどの identifier 要素が優先する識別子であるかを指定する。OPF パッケージドキュメントの著者には一つのパッケージ(すなわち、パッケージドキュメントの manifest 要素が参照するファイル群)について一意である、一次識別子を選択する責任がある。

このような一意性の要件に関わらず、リーディングシステムは、同じ一次識別子を持つ二つの異なるパッケージに出会った場合にも、 機能を大きく低下させてはならない(must not)

2.2: 出版物メタデータ

必須(required)要素である metadata 要素は出版物全体に関する情報を提供するために利用される。 このメタデータはダブリンコアの metadata 要素を直接的に、または(現在では廃止予定であるが)下位要素である dc-metadata の中に内包してもよい(may)。同様に補助的なメタデータも直接指定するか、(現在では廃止予定であるが)下位要素である x-metadata に内包することができる。

リーディングシステムは廃止予定である dc-metadata 要素と x-metadata 要素による指定を許容しなければならない(must)。新規に OPS 2.0 パッケージを作成する場合には、dc-metadata 要素と x-metadata 要素を使用するべきではない(should not)dc-metadata 要素が使用されている場合には、全ての dc 要素は dc-metadata 要素に格納され、他の metadata 要素があるならば、それらは全て x-metadata 要素に格納されなければならない(must)dc-metadata 要素が使用されていない場合には、全てのメタデータ要素は metadata 要素に直接格納されなければならない(must)

必須(required)要素である metadata 要素や、(廃止予定である) dc-metadata 要素は、The Dublin Core Metadata Initiative(http://www.dublincore.org/)が定義する、固有の出版物レベルのメタデータを持つ。以下の説明は利便性のために加えてあるが、ダブリンコア独自の定義(http://dublincore.org/documents/2004/12/20/dces/ を参照)の方が優先する。

meta 要素の一つ以上の 付加的な(optional) インスタンスは metadata 要素や廃止予定である x-metadata 要素の内部に配置してもよい(may) 。このインスタンスは XHTML 1.1 における meta 要素と似ているが出版物全体には適用されない。これによってコンテンツ供給者は、ダブリンコアの仕様を越えた任意のメタデータを表現することができる。個々の OPS コンテントドキュメントは(XHTML 1.1 のように)meta 要素をドキュメント固有のメタデータとして直接内包してもよい(may)。本仕様は OPF パッケージドキュメントを単独で、出版物レベルのダブリンコアメタデータを示すための基盤に利用する。

例:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
          xmlns:opf="http://www.idpf.org/2007/opf">
   <dc:title>Tale of Two Cities</dc:title>
   <dc:creator opf:role="aut">Charles Dickens</dc:creator>
   ...
   <meta name="price" content="USD 19.99" />
</metadata>

XML 名前空間のメカニズム(http://www.w3.org/TR/REC-xml-names11/を参照)は競合を避けて、ダブリンコアメタデータの要素を識別するために用いられる。metadata 要素や dc-metadata 要素(廃止予定)には、あらゆるダブリンコアの要素をインスタンスとして幾つでも内包することができる。ダブリンコアメタデータの要素はどのような順序で記述してもよい。 実際、同じ要素タイプを持つ複数のインスタンスを(例えばダブリンコアの複数の creator 要素のような)、意味を変えることなく他のメタデータ要素に散りばめられることは可能である。

ダブリンコアの各フィールドは、そのフィールドの値を持つ要素によって表現される。 metadata 要素はダブリンコアの title 要素、identifier 要素そして language をそれぞれ少なくとも一つずつ持たなければならない(must)。 ダブリンコアの要素は、他の OPF パッケージドキュメントの要素と同じように、特定の id 属性を持ってもよい(may)。パッケージの unique-identifier 属性が参照するダブリンコアの identifier 要素の少なくとも一つは特定の id 属性を持たなければならない(must)

ダブリンコアの creator 要素と contributor 要素のメタデータフィールドは貢献者の役割(著者、編集者やイラストレーターなど)を具体的に識別しないため、本仕様では付加的な role 属性を追加することでこれを実現している。role 属性についての詳解は Section 2.2.6 を参照。

ダブリンコアの creator 要素と contributor 要素を持つフィールドの機械化された処理を補助するために、本仕様ではこれらの要素に付加的な(optional) file-as 属性を追加している。この属性は正規化されたコンテンツのフォームを指定するために使用される。file-as 属性についての詳解は Section 2.2.2 を参照。

また本仕様ではダブリンコアの identifier 要素に scheme 属性を追加することで、 identifier 要素の値を決定するシステムや権威から、識別子の値を分離する構造的なメカニズムを提供している。 scheme 属性についての詳解は Section 2.2.10 を参照。

また本仕様ではダブリンコアの date 要素に event 属性を追加することで、 コンテンツ供給者が出版物に関する様々な日付(例えば作成日、出版日、変更日など)を識別できるようにしている。 event 属性についての詳解は Section 2.2.7 を参照。以下に例を示す。

<package version="2.0" xmlns="http://www.idpf.org/2007/opf"
         unique-identifier="BookId">
        <metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
                xmlns:opf="http://www.idpf.org/2007/opf">
           <dc:title>Alice in Wonderland</dc:title>
           <dc:language>en</dc:language>
           <dc:identifier id="BookId" opf:scheme="ISBN">
            123456789X
         </dc:identifier>
           <dc:creator opf:role="aut">Lewis Carroll</dc:creator>
</metadata>
         ...
</package>

ダブリンコアが定義するメタデータには要素の属性が無く、要素の内容を定義しているにすぎない。 上記の例では、metadata 要素について OPF 名前空間を指定することで、identifier 要素や creator 要素に使用された scheme 属性や role 属性をそれぞれ解決している。

Guidelines for implementing Dublin Core in XML(http://dublincore.org/documents/dc-xml-guidelines/)との互換性のために、本仕様ではある種のエンコードのスキームを使用したメタデータの項目に利用する xsi:type 属性や、人間が読めるテキストを使用したメタデータの項目に利用する xml:lang 属性を許容している。xsi:type 属性を許容する要素は identifier、language、date、format、type である。xml:lang 属性を許容する要素には title、contributor、coverage、creator、description、publisher、elation、rights、source、subject である。 本仕様はこれらの(後述する xml:lang 属性を利用した経験則による可能な例外を持つ)属性について、どのような特定の制約も設けてはいない。

以下のサブセクションではダブリンコアの個々のメタデータ要素について説明する。

2.2.1: <title> </title>

出版物のタイトルを表す。OPF パッケージドキュメントはこの要素タイプのインスタンスを少なくとも一つ持たなければならない(must)が、複数のインスタンスを持つことも可能である。title のメタデータを表示するあらゆるリーディングシステムは、最も適切な title 要素の内容を表示するべきである(should)。最も適切な title の決定方法について本仕様では定義しないが、フォントの利用可否や xml:lang 属性の検証などの選択法を行ってもよい(may)。このようなアルゴリズムが無い場合には、リーディングシステムは先頭の title 要素だけを、または全ての title 要素を最も適切なものとして扱うべきである(should)

2.2.2: <creator> </creator>

出版物の一次の作成者または著者を表す。creator 要素に記述された人物に対して二次的な協力をした貢献者は contributor 要素の中に記述するべきである(should)

複数の共著者を持つ出版物では、creator 要素を複数用意して著者の一人ひとりにそれぞれ割り当てるべきである(should)creator 要素の順序は、リーディングシステムが表示するべき(should)著者名の順序を決定するはずである。

本仕様では creator 要素の内容に、読者に向けて表示したい著者一人分の名前をテキストで記述することを推奨する。

本仕様では creator 要素に、role 属性と file-as 属性の二つを付加的な(optional)属性として追加している。role 属性に指定できる値は、Section 2.2.6 で定義されている contributor 要素におけるものと同じである。file-as 属性は、機械化された処理用に正規化されたコンテンツのフォームを指定するのに利用するべきである(should)。例えば以下のようなものが考えられる。

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

creator のメタデータを表示するあらゆるリーディングシステムは、最も適切な creator 要素の内容を表示するべきである(should)。最も適切な creator の決定方法について本仕様では定義しないが、フォントの利用可否や xml:lang 属性の検証などの選択法を行ってもよい(may)。このようなアルゴリズムが無い場合には、リーディングシステムは全ての creator 要素の内容を、記述された順序に従ってスペースや句読文字などで適切に区切りながら表示するべきである(should)

2.2.3: <subject> </subject>

subject 要素は複数インスタンスがサポートされており、それぞれに任意のフレーズやキーワードを持つことができる。 本仕様では the Library of Congress Subject Heading System のような subject の命名規約の標準化に取り組むことはない。

2.2.4: <description> </description>

出版物の内容についての説明文を表す。

2.2.5: <publisher> </publisher>

the Dublin Core Metadata Element Set(http://dublincore.org/documents/2004/12/20/dces/)の定義する出版社を表す。

2.2.6: <contributor> </contributor>

出版物について creator 要素に記述された人物に次ぐ貢献をした関係者を表す。

貢献の重要性を除けば、この要素の意味は creator 要素と同じである。 リーディングシステムは creator 要素の情報を表示する際に contributor 要素の情報を併せて表示してもよいし表示しなくてもよい。

今使用では contributor 要素に、role 属性と file-as 属性の二つを付加的な(optional)属性として追加している。file-as 属性の定義は creator 要素のものと同じであり、Section 2.2.2 に文書化されている。

role 属性の標準的な値のリストは the MARC relator code list(http://www.loc.gov/marc/relators/)に定義されている。 role 属性が指定された場合、MARC に登録された3文字の値が適用できるならばそれを使用しなければならない(must)。このリストの定義する値は豊富であるが、所定の値が必要な role をカバーしていないならば、新たに追加してもよい。このような値は oth. から始まる記述でなければならず、関係者コード other の細分として扱われる。本仕様における他の構成概念と同様に、これらの値は大文字と小文字を識別するので、すべての文字を小文字で記述しなければならない(must)

利便性のために関係者コードのリストを以下に例として示す。完全なリストが必要な場合には、上記に挙げた the MARC relator code list を参照すること。

Adapter [adp] 1) 異なるメディアの為に音楽作品を作り直す人物、または 2) 映画などの視聴覚メディアの為に小説や物語を書き直す人物に用いる。
Annotator [ann] 印刷された原稿に注釈を書く人物に用いる。
Arranger [arr] 編曲において音楽の内容を本質的に変わることなく残しながら、オリジナルと異なるメディアの為に音楽作品を移し変える人物に用いる。
Artist [art] オリジナルのグラフィックデザインや芸術作品を考案し、恐らくは作成も行う人物(例えば、画家)で、特定のコード(例えば [egr]、[etr] のような)が望ましくない人物に用いる。本のイラストレータには Illustrator [ill] を用いるのが望ましい。
Associated name [asn] ある物品に関連や記載のある人物や、その物品のかつての所有者(Former owner [fmo])であるか、所有者ではないがその物品の来歴に関係する者であるかを判別できない人物の名前を表記するのに用いる。
Author [aut] 知的または芸術的作品の内容について主たる責任を持つ人物または法人に用いる。この用語はこのような責任を担う複数の人物や法人に用いてもよい。
Author in quotations or text extracts [aqt] 自身の作品を、自身が直接的に寄与しなかった作品の中で大きく引用された人物に用いる。 このような引用はとりわけ展覧会のカタログや写真のコレクションなどで目にすることができる。
Author of afterword, colophon, etc. [aft] 作品の後書きや奥付などについて責任を持つが、作品の著者ではない人物または法人に用いる。
Author of introduction, etc. [aui] 作品の序論、序文、前書きや他の重要な内容について責任を持つが、作品の著者ではない人物または法人に用いる。
Bibliographic antecedent [ant] 目録レコードに記述されたある作品が基づいている作品について責任を持つ著者に用いる。 これは改作、続編、続刊、インデックスなどに用いるのが適切である。
Book producer [bkp] 本やその他の印刷メディアの製作に責任があり、特定のコード(例えば、[bkd], [egr], [tyd], [prt])を用いるのが望ましくない人物や会社に用いる。
Collaborator [clb] 他の著者の作品の詳細部分に限定的に参加したり、他の著者の作品の補足物(例えば、附録や注釈のような)を与えたりする人物や法人に用いる。
Commentator [cmm] 録音や映画やその他の視聴覚メディアの内容について、解釈や分析や考察を行う人物に用いる。 Compiler [com] は様々な人物や法人の作品から素材を選択して組み合わせ、作品や出版物を作り上げる人物に用いる。
Designer [dsr] デザインについて責任があり、特定のコード(例えば、[bkd], [tyd])を用いるのが望ましくない人物や組織に用いる。
Editor [edt] 一次的には自身のものではない作品について、文章の明瞭化、紹介文など重要な項目の追加、編集スタッフへの技術的な指示など出版にあたっての準備をする人物に用いる。
Illustrator [ill] デザインやイラストを、通常は文章に添った形で考案し、恐らくは作成も行う人物に用いる。
Lyricist [lyr] 歌の歌詞を書く人物に用いる。
Metadata contact [mdc] メタデータセット(例えば、地理空間メタデータセット)のオリジナルな記述の編纂や維持に一次的な責任を持つ人物や組織に用いる。
Musician [mus] 音楽を演奏したり、作品の音楽的な内容に貢献する人物について、その働きをより正確に特定することが、出来ないか望ましくない場合に用いる。
Narrator [nrt] 特定の行動や出来事や趨勢を関連付ける語り手に用いる。
Other [oth] 他のリストの関係者コードで MARC のコードリストに同等のものがないものや、関連付けられているコードがない用語に用いる。
Photographer [pht] 撮影された写真について責任を持つ人物や組織について、使用しているものがオリジナルか複製かに関わらず用いる。
Printer [prt] 文章を印刷する人物や組織について、タイプによるか刷版によるかに関わらず用いる。
Redactor [red] 内容について知的責任を持つことなく項目の枠組みを書いたり作成したりする人物に用いる。
Reviewer [rev] 本や映画や演目の評論について責任を持つ人物や団体に用いる。
Sponsor [spn] 契約の発行や、執筆、印刷、出版された作品の援助を行う人物や代理店に用いる。
Thesis advisor [ths] 学位候補生が執筆や発表を行う研究論文や論述の文章について監督する人物に用いる。
Transcriber [trc] 口述筆記や録音されたものを含むオリジナルの素材から筆記またはタイプされた原稿を作成する人物に用いる。
Translator [trl] 文章を一つの言語から別の言語に、または古い形式から新しい形式に翻訳する人物に用いる。

2.2.7: <date> </date>

http://www.w3.org/TR/NOTE-datetime の "Date and Time Formats" とそれが基づく ISO 8601 が定義するフォーマットに従った、出版日を表す。とりわけ、時刻を持たない日付は YYYY[-MM[-DD]] という形式、すなわち4 桁の年と付加的な(optional) 2 桁の月、そして月がある場合に付加的な(optional) 2 桁の日によって表される。

date 要素は一つの付加的な(optional) OPF の event 属性を持つ。 event に指定する属性値について本仕様では定義しないが、考えられる値としては creationpublicationmodification などを含んでもよい(may)

2.2.8: <type> </type>

type 要素の内容には、一般的なカテゴリー、機能、ジャンルや集合レベルを説明する用語を入れる。 推奨されるベストプラクティスは、管理された用語から値を選択することである。

2.2.9: <format> </format>

リソースのメディアタイプや特徴を表す。ベストプラクティスは、管理された用語(例えば、MIME メディアタイプ)から値を選択することである。

2.2.10: <identifier> </identifier>

リソースを一意に識別するための文字列や数字である。OPF パッケージドキュメントはこの要素タイプのインスタンスを少なくとも一つ持たなければならない(must)が、複数のインスタンスを持つことも可能である。

Section 2.1 が説明するパッケージの unique-identifier 属性から参照ができるように、少なくとも一つの identifier 要素には id 属性を(XML の "ID" データタイプの値で)指定しなければならない(must)

identifier 要素は、本仕様が定義する OPF の scheme 属性を付加的な(optional)属性として持つ。scheme 属性には、例えば "ISBN" や "DOI" などのような、identifier 要素が持つテキストを生成または指定するシステムや権威の名称を指定する。scheme 要素の値が大文字と小文字を識別するのは、そのような識別が必要なスキーマを利用する場合に限られる。

本仕様は特定の出版識別子のスキームを標準化や推薦するものではない。URL や ISBN の具体的な使用方法は、本仕様ではまだ示されていない。ダブリンコアは識別子のスキームを現時点では定義していない。

2.2.11: <source> </source>

出版物を生成する重要なリソースに関する情報。the Dublin Core Metadata Element Set (http://dublincore.org/documents/2004/12/20/dces/)を参照。

2.2.12: <language> </language>

出版物の知的内容を記述した言語を指定する。OPF パッケージドキュメントはこの要素タイプのインスタンスを少なくとも一つ持たなければならない(must)が、複数のインスタンスを持つことも可能である。 この要素の内容は RFC 3066(http://www.ietf.org/rfc/rfc3066.txt を参照)や、それを継承した the IETF Standards Track に従わなければならない(must)。 それ以外の記述もダブリンコアでは許容されているが、本仕様では許容しない。

2.2.13: <relation> </relation>

補助的なリソースや、そのリソースと出版物との関係を表す識別子。

2.2.14: <coverage> </coverage>

出版物の内容の範囲や領域を表す。推奨されるベストプラクティスは、管理された用語から値を選択することである。 the Dublin Core Metadata Element Set(http://dublincore.org/documents/2004/12/20/dces/)を参照。

2.2.15: <rights> </rights>

諸権利に関する表明や、ある権利への参照を表す。本仕様では著作権表示やさらなる諸権利についての説明は直接的に示されるべきである(should)

本仕様ではコンテンツ供給者が、購読権や販売用コンテンツの複製などのライセンス用語を、安全な販売業者に向けて指定する方法を定義していない。

2.3: マニフェスト

manifest 要素は必須(required)要素であり、出版物を構成するファイルのリスト(例えば、コンテントドキュメント、スタイルシート、画像ファイル、埋め込みフォントファイル、内包するスキーマ)を持たなければならない(must)manifest 要素は item 要素を一つ以上持たなければならない(must)item 要素には、ドキュメント、画像ファイル、スタイルシートや他のコンポーネントなど、出版物を構成するパーツをそれぞれ記述する。manifest 要素は OPF パッケージドキュメントの構成ファイルを参照する item 要素を持ってはならない(must not)

manifest 要素に内包される個々の item 要素は id 属性、href 属性(URI。相対的な URI であれば、その参照を持つ OPF パケージドキュメントファイルに対して相対的に解釈される。)、media-type属性(アイテムの MIME メディアタイプを指定する。)を持たなければならない。

マニフェストにおける item 要素の順序は重要ではない。

例:

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

manifest 要素内における item 要素の href 属性の URI にはフラグメント識別子を使用してはならない(must not)

単一のリソース(href 属性)は manifest 要素の中で二度以上記述してはならない(must not)

コンテントドキュメントのルート要素は manifest 要素内の item 要素の media-type 属性に一致しなければならない(must)

2.3.1: フォールバックアイテム

OPS 仕様書はそれに適合したあらゆるリーディングシステムがサポートしなければならない(must) OPS コアメディアタイプのセット(例えば、XHTML、PNG、SVG)を定義している。これらのメディアタイプのみを使用する出版物では、 manifest 要素にその出版物の構成ファイルを直接記述するだけでよい。しかしコンテンツ供給者は、追加されたメディアタイプのアイテムを参照する出版物を作成してもよい(may)。OPS に適合したあらゆるリーディングシステムでこのような出版物を読めるようにするために、コンテンツ供給者はこのようなアイテムについて代替となる "フォールバック" アイテムを用意しなければならない(must)。OPS コアメディアタイプではない全てのアイテムについて、そのフォールバックアイテムの少なくとも一つは、OPS コアメディアタイプを採用したものでなければならない(must)か、場合によっては非推奨 XML ボキャブラリを持つドキュメント用に CSS のスタイリングを用意してもよい(may)

本仕様書と OPS 仕様書は共同して OPS コアメディアタイプのフォールバックを指定する四つのメカニズムを定義している。それらのメカニズムを以下に示す。

  1. object 要素を介して参照されるインラインの "被置換" リソースについては、本仕様は OPS 仕様書の Section 2.3.6日本語訳)に述べる要素固有の置換能力に依拠している。
  2. img 要素を介して参照されるインラインの "被置換" リソースについては、OPS 仕様書の Section 2.3.4日本語訳)に述べる alt 属性や title 属性のテキスト値が適切なフォールバックを提供する。
  3. インライン XML アイランドについては、OPS 仕様書 Section 2.6.3.1日本語訳)に述べる switch-based 型のフォールバックメカニズムを利用する。
  4. ドキュメントやパッケージからのインラインではない参照先や、img 要素を介して参照されるインラインの "被置換" リソースについては、パッケージの item 要素の様々な属性がフォールバック情報に利用されている。これについては本仕様書の本セクションで述べる。

フォールバックを指定するために、出版物の NCX(後述)を示す application/x-dtbncx+xml のメディアタイプを持つファイルはコアメディアタイプとして扱われるべき(should)であり、このファイルについてはフォールバック情報を持たせてはならない(must not)

2.3.1.1: OPS コアメディアタイプではないアイテム

OPS コアメディアタイプではないリソース(例えば、コアではないイメージタイプ、テキストファイル、PDF ファイル)を指定する item 要素は規定のフォールバックを持たなければならない(must)。この場合には、そのフォールバックは別のitem 要素を指す fallback 属性によって識別されなければならない。アウトオブライン XML アイランドのフォールバック要件については Section 2.3.1.2 を参照。

ある item 要素がフォールバックとなる item 要素を識別するのに利用する fallback 属性には、フォールバックを識別する item 要素の ID 属性を指定しなければならない(must)fallback 属性によって参照されるアイテムは、複数レベルのフォールバックチェーンを形成して、それぞれのfallback 属性を順々に指定してもよい(may)。以下に例を示す。

<manifest>
        <item id="item1"
                href="FunDoc.txt"
                media-type="text/plain"
                fallback="fall1" />
        <item id="fall1" fallback="fall2"
                href="FunDoc.pdf"
                media-type="application/pdf" />
        <item id="fall2"
                href="FunDoc.html"
                media-type="application/xhtml+xml" />
        <item ...>
</manifest>

ある fallback 属性が示す item 要素にも fallback 属性があった場合、リーディングシステムは表示可能な item 要素が見つかるまで(または後述のな fallback-style 属性を持つ item 要素が見つかるまで)フォールバックチェーンを辿り続ける。リーディングシステムはフォールバックチェーンをさらに辿ってもよい(may)し、チェーンに含まれるどの item 要素を表示してもよい。要素固有の(例えば、img 要素や object 要素)フォールバック情報が見つからない場合には、出版物において OPS コアメディアタイプを持たない全ての item 要素は、OPS コアメディアタイプを持つ item 要素(または後述の fallback-style 属性を持つ item 要素)へのフォールバックを、直接的または間接的に指定しなければならない(must)

フォールバックチェーンは、終結しなければならず(must)、循環参照は認められない。しかし、リーディングシステムは循環参照が見つかった場合にも、機能を大きく低下させてはならない。

2.3.1.2: アウトオブライン XML アイランドのアイテム

アウトオブライン XML アイランド(推奨ボキャブラリで記述されていない XML ドキュメント)であるリソースを指定している item 要素を指す。item 要素は以下の場合にアウトオブライン XML アイランドとされる。

  1. 推奨ボキャブラリによって記述されていない XML ドキュメント(例えば、media-type 属性が、application/xhtml+xmlapplication/x-dtbook+xml や廃止予定である text/x-eob1-document ではない XML ドキュメント)をリソースに指定するもの。
  2. 推奨ボキャブラリで記述されており、拡張モジュールを内包する XML ドキュメントをリソースに指定するもの。

フォールバックの決定やアウトオブライン XML アイランドの処理の自由度を向上させるには、より多くの情報が必要となる。 アウトオブライン XML アイランドの item 要素の名前空間は required-namespace 属性で指定しなければならず(must)、そのフォールバックには他の item 要素を示す fallback 属性か、fallback-style 属性にってアイランドを表示する CSS スタイリングを用意しなければならない(must)

fallback 属性が指定された場合、リーディングシステムは、前述した非 OPS コアメディアタイプのアイテムと同じように処理をおこなう。

fallback-style 属性が指定された場合、リーディングシステムは、アイランドに好ましいスタイルシートへの href 属性を含む item 要素の id 属性への参照を含まなければならない(must) fallback-style の属性値によって指定されたスタイルシートを使用することで、アウトオブライン XML アイランドを(たとえ、そのアイランドのボキャブラリや拡張モジュールをネイティブに処理することができないとしても)処理することを選択してもよい(may)

fallback 属性と fallback-style 属性の両方を指定してもよい(may)が、この場合リーディングシステムはフォールバックチェーンに従うことと、与えられた CSS スタイルシートでアウトオブライン XML アイランドを処理することのいずれを選んでもよい(may)

推奨ボキャブラリで記述されたアウトオブライン XML アイランドは定義により、拡張モジュールを内包する。この場合、拡張モジュールを利用する非推奨ボキャブラリのアイランドがあるならば、required-modules 属性は required-namespace 属性とともに記述されなければならない(must)

required-modules の属性値には、アウトオブライン XML アイランド内で使用する拡張モジュールの名前をカンマ区切りリストで記述しなければならない(must)。これらのモジュールの名前については、他の XML ボキャブラリの仕様に明確に定義されていない限りは大文字小文字を識別しない。モジュール名に含まれるスペースは、required-modules の属性値のリストに記述する際に、"-" に置き換えられなければならない(must)。OPS コンテキストにおける XHTML の 拡張モジュールはrubyformsserver-side-image-mapintrinsic-events などの属性値を持つ。

ここで注意すべきことは、required-modules の属性値に非拡張モジュールの名前を記述することも可能であり、これらのモジュールはその XML ボキャブラリがサポートされているならば、常にサポートされていると見做されることである。これは明快さのために有用であるほか、今後の仕様の改訂によって(例えば、OPS において現在廃止予定となっている Style Attribute XHTML モジュールのような)幾つかのモジュールが付加的な(optional)ものとされる可能性がある場合にも有用である。

非推奨ボキャブラリのアウトオブライン XML アイランドを指定するアイテムに required-modules 属性を与えることは可能であるばかりか、明快さのためや、非推奨ボキャブラリが必要とする拡張モジュールを特定するためにも有用である。

さらに重要なことは、アウトオブライン XML アイランドで使用される非推奨ボキャブラリ(や拡張モジュール)をネイティブに処理できるリーディングシステムは、その総体把握力を利用してドキュメントをネイティブに処理することを選択してもよい(may)ということである。けれども、このようなネイティブの処理能力を持たないリーディングシステムのために、フォールバック情報は用意されなければならない(must)

例:

<manifest>
        <item id="item1"
              href="Doc1.hpy"
              media-type="text/happy+xml"
              required-namespace="http://happy.com/ns/happy1/"
              fallback="item2" />
        <item id="item2"
              href="Doc1.less-hpy"
              media-type="text/less-happy+xml"
              required-namespace="http://happy.com/ns/happy2/"
              fallback="item2.5"
              fallback-style="css1" />
        <item id="item2.5"
              href="Doc1.htm"
              media-type="application/xhtml+xml"
              required-namespace="http://www.w3.org/1999/xhtml"
                required-modules="ruby, server-side-image-map"
              fallback="item3" />
        <item id="item3"
              href="Doc1.dtb"
              media-type="application/x-dtbook+xml" />
        <item id="item4"
              href="Doc2.hpy"
              media-type="text/happy+xml"
              required-namespace="http://happy.com/ns/happy1/"
              fallback-style="css1" />
        <item id="css1"
              href="happy.css"
              media-type="text/css" />
</manifest>

上記の例では属性値 item1 を処理する際に、リーディングシステムは item1 をネイティブに表示すること、item2 をネイティブに表示すること、item2 を属性値 css1 によるスタイリングのみを使用して表示すること、item2.5 を(Ruby と Server Side Image Map XHTML の拡張モジュールをリーディングシステムがサポートしていると仮定して)ネイティブに表示すること、item3 をネイティブに表示することを選択することができる。属性値 item4 を処理する際には、リーディングシステムは item4 をネイティブに表示することと、属性値 css1 によるスタイリングのみ使用して表示することを選択することができる。

拡張モジュールを使用していない限り、推奨ボキャブラリで記述された XML ドキュメントを参照する item 要素において、required-namespace 属性を持つことは必須ではない(not required)。拡張モジュールを使用している場合には、required-namespace 属性と required-modules 属性の両方を持たなければならない(must)

2.4: スパイン

Following the manifest, there must be one spine element, which defines the primary linear reading order of the publication. It specifies an ordered list of one or more OPS Content 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 publication. The successive files named in successive itemref elements are those that are to be rendered using "next-page" style functionality that could be available in the Reading System.

The spine must refer only to item elements with media types of application/xhtml+xml, application/x-dtbook+xml, the deprecated text/x-eob1-document, or an Out-Of-Line XML Island (with required fallback). Content with other media types may be referenced via OPS Content 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 OPS Content 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="application/html+xml" />
        <item id="c1"
                href="chap1.html"
                media-type="application/html+xml" />
        <item id="c2"
                href="chap2.dtb"
                media-type="application/x-dtbook+xml" />
        <item id="c3"
                href="chap3.html"
                media-type="application/html+xml" />
        <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" />
        <item id="ncx" href="toc.ncx" media-type="application/x-dtbncx+xml" />
</manifest>
<spine toc="ncx">
        <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 the document is reached, the next document in linear order would be the document referenced by id c2.

The NCX section below specifies the requirements for the navigation control file and the spine toc attribute.

Content is considered reachable if it is referenced directly or indirectly through hyperlinks or navigation structure (NCX). Referencing content through img or object elements does not make an item reachable. All content reachable in the publication must be referenced with itemref elements.

Each item must only be referenced by a single element (itemref). Content referenced by an itemref element that omits the optional linear attribute (or provides the linear attribute with a value of yes) is called primary content. Content referenced by an itemref element that includes the optional linear attribute with a value of no is referred to as auxiliary content.

Reading Systems must display all primary (and optionally auxiliary) content items in a way that allows linear (forward and backward) navigation through all the items in the order in which they are listed in the spine. The decision on whether to include auxiliary content in the linear navigation order should be based on the Reading System design and device capabilities. This specification neither encourages nor discourages such inclusion. Reading Systems must display in some fashion all auxiliary content items if such items can be reached through hyperlinks, even if the auxiliary content items are not included in the linear navigation order.

For example:


<spine toc="ncx">
   <itemref idref="intro" />
   <itemref idref="chapter1" />
   <itemref idref="chapter1_answerkey" linear="no" />
   <itemref idref="chapter2" />
   <itemref idref="chapter2_answerkey" linear="no" />
   <itemref idref="conclusion" />
   <itemref idref="about_this_book" linear="no" />
</spine>

Note that this design (the addition of the linear attribute) is backward compatible with OEBPS 1.2, assuming that the OEBPS 1.2 Reading System ignores unknown attributes.

以下の manifest 要素は 一つ以上の itemref 要素を内包した spine 要素を一つだけ持たなければならない(must)manifest 要素に続いて、一つ以上の itemref 要素を内包した spine 要素が一つだけなければならない(must)個々の itemref 要素は manifest 要素が指定した OPS コンテントドキュメントを参照する。itemref 要素の記述順序は、関連付けられた OPS コンテントドキュメントの出版物における読み順を体系付ける。

spine 要素における個々の itemref 要素は OPS コンテントドキュメント(や OPS コンテントドキュメントを含んだフォールバックチェーンを持つドキュメント)以外のメディアタイプを参照してはならない(must not)。OPS コンテントドキュメントは次のメディアタイプのものでなければならない(must)application/xhtml+xmlapplication/x-dtbook+xml、廃止予定となっている text/x-oeb1-document、そして(必須属性である fallback を持った)アウトオブライン XML アイランド。これらに含まれないメディアタイプのドキュメントが spine 要素で参照された場合には、リーディングシステムはそれを spine 要素の構成物に含めてはならない(must not)

spine 要素に記述されたアイテムは OPS コンテントドキュメントか OPS コンテントドキュメントを含んだフォールバックチェーンを持つアイテムでなければならないため、spine 要素のアイテムのフォールバックが別の OPS コアメディアタイプに "フェイルオーバ" することは可能である。例えば、spine 要素の itemref 要素は、PNG 画像、 OPS の XHTML コンテントドキュメントの順にフォールバックする PDF ドキュメントを参照することが出来る。このフォールバックチェーンは OPS コンテントドキュメントを含む(この場合は、OPS コンテントドキュメントで終結する)ため、この spine 要素のアイテムは妥当なものである。

加えて、特定の spine 要素のアイテムは(manifest 要素内での、自身の id 属性値の観点から ) spine 要素の中で二回以上登場してはならない。

出版物を構成するあらゆる OPS コンテントドキュメント(つまり、マニフェストにリストされているもの)は、本仕様では潜在的にあらゆるメカニズムによる参照も許容されており、それらは spine 要素に 内包されていなければならない(must)。このような参照メカニズムは、 部分リスト、OPS コンテントドキュメント内のハイパーリンク、NCXやツアーやガイドによる参照として組み込まれている。

このような参照によって、リーディングシステムは本仕様が要求するような spine 要素にリストされていない OPS コンテントドキュメントに遭遇するかもしれないが、リーディングシステムはそのドキュメントに linear 属性の値に no (後述)を割り当てて spine 要素(リーディンシステムの説明を配置する箇所)に 追加するべきである(should)

個々の itemref 要素に、出版物の著者は付加的な属性である linear 属性によって、関連付けられた OPS コンテントドキュメントがプライマリ(linear="yes"linear 属性がない場合のデフォルト値)であるのか、それともオグジュアリ(linear="no")であるのかを指定してもよい(may)。 出版物の著者が、オグジュアリと宣言されたあらゆる OPS コンテントドキュメントにハイパーリンクのような内部参照を加えておくことは重要である。すべてのオグジュアリであるコンテントへの参照を NCX に追加することが推奨される(recommended)spine 要素内にある itemref 要素の少なくとも一つはプライマリとして宣言されなければならない(must)

OPS コンテントドキュメントがプライマリであるかオグジュアリであるかの指定は、オグジュアリであるコンテントをプライマリとは違った形で表示するリーディングシステムにとって有用である。例えば、リーディングシステムは、プライマリのコンテントを表示するメインウィンドウとは別に、ポップアップウィンドウにオグジュアリのコンテントを表示することが考えられる。(オグジュアリとみなされるコンテントのタイプについては、後述の例と詳解を参照。)

リーディングシステムが、プライマリとオグジュアリのコンテントを識別することは必須ではない(not required)ため、本セクションで示す要件や勧告では、linear 属性の値に関わらず、spine 要素の中のすべての OPS コンテントドキュメントをプライマリと見做してもよい(may)

linear 属性も OEBPS 1.x との互換性を保持しているが、OEBPS 1.x ではすべての到達可能な OEBPS コンテントドキュメントが spine 要素の中にリストされるわけではなかった。OEBPS 出版物を OPS 出版物にアップグレードするには、OEBPS 1.x 出版物の到達可能なコンテントドキュメントに linear="no"割り当てるべきである(should)

リーディングシステムは spine 要素内の順序付けられた itemref 要素の情報を、出版物を表示するために利用する。リーディングシステムは spine 要素の中から、最初のプライマリな OPS コンテントドキュメントを出版物の主要な読み順の開始部分として識別しなければならない(must)。後続のプライマリ OPS コンテントドキュメントは、spine 要素内での順序に従って、出版物の残りの読み順を形成する。リーディングシステムは spine 要素のあるのプライマリ OPS コンテントドキュメントから次の OPS コンテントドキュメントに移動する際に、"next-page" スタイル機能を使用してもよい(may)

spine 要素は、manifest 要素で宣言された必須である(required)NCX ドキュメントのid 属性値を値に指定した toc 属性を持たなければならない(must)。(Section 2.4.1 を参照。)

spine 要素と付加的な linear 属性を説明する例:

<manifest>
     <item id="intro"
           href="intro.html"
           media-type="application/xhtml+xml" />
     <item id="c1"
           href="chap1.html"
           media-type="application/xhtml+xml" />
     <item id="c1-answerkey"
           href="chap1-answerkey.html"
           media-type="application/xhtml+xml" />
     <item id="c2"
           href="chap2.dtb"
           media-type="application/x-dtbook+xml" />
     <item id="c2-answerkey"
           href="chap2-answerkey.html"
           media-type="application/xhtml+xml" />
     <item id="c3"
           href="chap3.html"
           media-type="application/xhtml+xml" />
     <item id="c3-answerkey"
           href="chap3-answerkey.html"
           media-type="application/xhtml+xml" />
     <item id="note"
           href="note.html"
           media-type="application/xhtml+xml" />
     <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" />
     <item id="ncx"
           href="toc.ncx"
           media-type="application/x-dtbncx+xml" />
</manifest>
<spine toc="ncx">
     <itemref idref="intro" />
     <itemref idref="c1" />
     <itemref idref="c1-answerkey" linear="no" />
     <itemref idref="c2" />
     <itemref idref="c2-answerkey" linear="no" />
     <itemref idref="c3" />
     <itemref idref="c3-answerkey" linear="no" />
     <itemref idref="note" linear="no" />
</spine>

上記の例では、出版物の著者は spine 要素にリストされた8つの OPS コンテントドキュメントのうち4つに、コンテントドキュメントがオグジュアリであることを示す linear="no" を設定している。4つのうち3つは "answer key" であり、4番目はある種の注記である。これら4つすべてが本の主要なフロウに対してオグジュアリなものであり、主要なフロウから分離されて読まれてもよい。

プライマリな内容とオグジュアリな内容を区別して表示できるリーディングシステムは、introc1c2c3 の4つのプライマリな OPS コンテントドキュメントに読み順を設定することができる。 このようなリーディングシステムによってオグジュアリなコンテントドキュメントは、(ハイパーテキストリンクや NCX のエントリなどを通じた)アクティベーションが行われた上で、主要な読み順とは違った形で表示される。出版物の著者がオグジュアリなコンテントドキュメントに必要な参照を用意することは重要であり、さもなければオグジュアリを識別するリーディングシステムはそのコンテントに到達することができないかもしれない。

属性 linear="no" を無視してすべての itemref 要素をプライマリに設定するリーディングシステムを本仕様は許容するが、このようなリーディングシステムはすべての OPS コンテントドキュメントに、記述されたとおりの順番で読み順を割り当てる。これは印刷機能を持つリーディングシステムにとって、OPS コンテントドキュメントのすべての情報を著者の意図した順序で印刷する際に、とりわけ有用である。

リーディングシステムは自らの判断で、プライマリとオグジュアリ両方の表示オプションをユーザに提供してもよい。

2.4.1: 宣言型目次 − NCX

ナビゲーションを平易にしてアクセシビリティを向上させるために、OPF パッケージドキュメントは "Navigation Center eXtended" すなわち NCX をサポートしている。 これは、DAISY コンソーシアムによって標準化された概念とその実装である。

本仕様は、DAISY/NISO 標準規格、正式名称 ANSI/NISO Z39.86-2005, Specifications for the Digital Talking Book の定義する NCX を使用する。NCX はこの包括的マルチメディア標準規格の一部(Section 8)である。 DAISY コンソーシアムは NCX DTD をメンテナンスする。OPF で NCX を使用するのに DTD を改変する必要はない。 DAISY/NISO 諮問委員会は NCX のモジュール化や、 電子書籍やマルチメディア出版物や他の電子文書の利用に合致するように用語を変更することを、将来的には検討している。

本仕様の NCX の実装では、幾つかの付加的な(optional)要素とメタデータアイテムは実装を要求されない。 本仕様での NCX の実装では、必要ない付加的な(optional)要素とメタデータアイテムがある。 以下のセクションでは NCX に関する DAISY/NISO 標準規格の説明を転記することをやめて、参照にとどめるようにした。 "例外" についてはすべて、以下の Section 2.4.2 で説明する。

2.4.1.1: イントロダクション

Navigation Control file for XML applications (NCX) は、ユーザをナビゲートするための出版物の階層構造を示す。 NCX は、部、章やセクションなどドキュメントの主要な構成要素に読者を移動させるための目次に似ているが、出版社がオリジナルの紙のドキュメントの目次に選ぶ要素よりも、多くの要素をしばしば持つことがある。NCX は PC ユーザに親しまれている折りたたみツリーの形式で表すことができる。NCX はドキュメント全体を分析することなくドキュメントの主要な構成要素への迅速なアクセスを提供するために開発された。ページ、脚注、数字、表などの要素もまた、独立した非階層的なリストに記述することができ、ユーザはそれらにアクセスすることができる、

これらのナビゲーション機能の意図は、それを必要とするユーザの利便性を向上させることであって、それを必要としないユーザに負荷を与えることではない、と強調することは重要である。NCXのナビゲーション機能を必要としないそれらのユーザのために、代替となる guide 要素を本に提供してもよい。

2.4.1.2: キー NCX の要件

リーディングシステムは NCX をサポートしなければならない(must)

Publications containing only XHTML OPS Content Documents should include an NCX (this "should" could transition to a "must" in future versions of this specification).

OPS 出版物は NCX を持たなければならない(must)

他のすべての出版物のコンポーネントと同様に、NCX も manifest 要素内の item 要素として(media-typeapplication/x-dtbncx+xml を指定して)内包されなければならない(must)。NCX が参照する item 要素はいかなるフォールバック情報(required-namespace属性、fallback 属性や fallback-style 属性)も持ってはならない(must not)

出版物が NCX を持っているならば、NCX を説明する item 要素は spine 要素の toc 属性に参照されなければならない(must)

NCX ファイルは ncx-2005-1.dtd に適合した妥当な XML ドキュメントでなければならず(must)http://www.niso.org/standards/resources/Z39-86-2005.html に定義された追加基準要件に従う。 ncx 要素の version 属性と xmlns 属性は、上記の DTD の値を用いてドキュメント内に明確に指定されなければならない(must)

2.4.2: 出版物の構文における NCX の例外

ANSI/NISO Z39.86-2005 標準規格の Section 8 に定義された NCX は OPS アプリケーションにおいてもほぼ同様であるが、幾つかの例外がある。 標準では NCX から出版物へのリンクは SMIL ドキュメント(http://www.w3.org/TR/2005/REC-SMIL2-20050107/)を示す。OPS 出版物では、このリンクはソースである OPS コンテントドキュメントの XML 要素を示す。標準規格の Section 8 との、このような違いによって、以下の注意すべき例外が生まれる。

  • NCX の OPF アプリケーションでは smilCustomTest 要素は使用しない。
  • NCX の OPS アプリケーションでは audio 要素は使用しない。
  • clipBegin 属性(%SMILtimeValREQUIRED )は オーディオセグメントの開始位置を識別するが、NCX の OPF アプリケーションでは使用しない。
  • clipEnd 属性(%SMILtimeValREQUIRED )は オーディオセグメントの終了位置を識別するが、NCX の OPF アプリケーションでは使用しない。
  • content 属性は SMIL ファイルに navPoint 要素や navTarget 要素の参照するアイテムの開始位置を示すポインタである。NCX の OPF アプリケーションでは、ポインタは SMIL の位置ではなく XML 要素を示す。
  • OPS 出版物はマルチメディアファイルよりもはるかに小さいため DTBs Spanning Multiple Media Unit は出版物のコンテキストと関連性を持たない。
  • 例では SMIL ファイルへのリンクを示しているが、NCX の OPF アプリケーションではリンクは XML 要素に向かうものになる。また、この例ではclipBegin 属性や clipEnd 属性が参照する audio 要素があるが、これらは NCX の OPF アプリケーションでは使用されない。
  • NCX メタデータの必須アイテムである "dtb:totalPageCount" と "dtb:maxPageNumber" は、コンテントが "paper page" の表示に結び付かない場合には、関連性を持たなくてもよい。この場合には、これらの値にゼロを指定してもよく(may)、リーディングシステムはこれらを 無視してもよい(may)
  • playOrder 属性は必須のままである。playOrder 属性は SMIL コンテントのシーケンスに使用されていなくとも、ドキュメントの読み順に従った適切な値を持つべきである(should)。これは例えば、pageList 要素に navMap 要素の中で対応した位置を見つけるのをナビゲートする時に使用される。

2.4.3: スパインにおける XML アイランド

スパインは XML アイランド日本語訳)を参照してもよい(may)。リーディングシステムが XML アイランドを正しく表示できない場合には、Open Publication Structure日本語訳)が定義する標準フォールバック手法を使用しなければならない(must)

つまり、表示できないアイランドがあれば、リーディングシステムはそのアイランドのための fallback 要素を選択して表示しなければならない(must)

2.5: ツアー [廃止予定]

観光ガイドが興味深い場所を組み合わせて観光ツアーを作るように、コンテンツ供給者は出版物のパーツを組み合わせて利便性の高いナビゲーションを作成することができる。

OPS パッケージドキュメント *2 は、一つ以上の tour 要素を順番に内包した tours 要素を一つ 持ってもよい(may)が持たなくてもよい。個々の tour 要素はユーザに表示するための title 属性を持たなければならない(must)。リーディングシステムは、様々な目的や専門家レベルの読者などのために選択的ビューのような、出版物の各パーツへの多様なアクセス順序を提供するために、tours 要素を使用してもよい(may)。何故ならばリーディングシステムがツアーのサポートを実装することは必須ではない(not required)ので、コンテンツ供給者は tours 要素から参照されるコンテントへのアクセス方法を他にも用意するべきである(should)

個々の tour 要素は一つ以上の site 要素を内包し、site 要素はそれぞれ href 属性と title 属性を持たなければならない(must)href 属性は manifest 要素を持つ OPS コンテントドキュメントを参照しなければならず(must)、RFC 2396(http://www.ietf.org/rfc/rfc2396.txt を参照)の section 4.1 にて定義されたフラグメント識別子を持ってもよい(may)。 個々の site 要素は読者が自由に探索を開始できる開始地点を指定する。リーディングシステムはサイトのスコープを決定するのに、参照された要素の境界を使用してもよい(may)。フラグメント識別子が使用されていない場合には、スコープはドキュメント全体であると見做される。リーディングシステムが、参照された要素のスコープ全体を記述したり他に指定したりすることは、本仕様では必須ではない(not require)site 要素の順序は重要なもの見做され、リーディングシステムのナビゲーションを補助するために 使用されるべきである(should)

例:

<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: ガイド

パッケージは一つ以上の reference 要素を内包した guide 要素を一つ持ってもよい(may)guide 要素は出版物の基盤構造的なコンポーネントを指定して、それらに対する利便性の高いアクセスをリーディングシステムに提供する。

例:

<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>

本の構造的なコンポーネントは guide 要素に内包された reference 要素にリストされる。 これらのコンポーネントは目次、イラストのリスト、序文、文献目録などの多くの本の標準的なパーツを参照することができる。リーディングシステムが何らかの形で guide 要素を使用することは必須ではない(not required)

個々の reference 要素は manifest 要素を持つ OPS コンテントドキュメントを参照する href 属性を持たなければならず(must)、RFC 2396(http://www.ietf.org/rfc/rfc2396.txt を参照)の section 4.1 にて定義されたフラグメント識別子を持ってもよい(may)。リーディングシステムはサイトのスコープを決定するのに、参照された要素の境界を使用してもよい(may)。フラグメント識別子が使用されていない場合には、スコープはドキュメント全体であると見做される。リーディングシステムが、参照された要素のスコープ全体を記述したり他に指定したりすることは、本仕様では必須ではない(not require)

必須(required)属性である type 属性は type 属性から参照される出版物のコンポーネントを説明する。type 属性の値には、以下のリストで定義された値が適用できるならば、そこから選択されなければならない(must)type 属性の値としてあらかじめ定義された値に適用できるものがない場合には、他の値を使用してもよい(may)。 この場合には、属性値の名前は other. の文字列から始まるものでなければならない(must)type 属性の値は大文字小文字を区別する。

以下のリストは the Chicago Manual of Style の第13版から採られた type の属性値である。

cover 本のカバー、表紙の情報など
title-page タイトル、著者、出版社などのメタデータを掲載している可能性のあるページ
toc 目次
index 巻末索引
glossary
acknowledgements
bibliography
colophon
copyright-page
dedication
epigraph
foreword
loi イラストのリスト
lot 表のリスト
notes
preface
text コンテントの "実際の" 最初のページ(例えば "第一章")

附録

附録 A: OPF パッケージスキーマ

 

<?xml version="1.0"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0" ns="http://www.idpf.org/2007/opf"
         datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">

<!--
Title:
    Relax NG Schema for the Open Packaging
     Format (OPF) version 2.0

Version:
    2.0

Revision:
    20070222

Authors:
    This Version 2.0 :
         Peter Sorotokin <psorotok@adobe.com>
-->

<start>
  <ref name="OPF20.package-element"/>
</start>

<define name="OPF20.optional-id-attribute">
  <optional>
    <attribute name="id">
      <data type="ID"/>
    </attribute>
  </optional>
</define>

<define name="OPF20.optional-xml-lang-attribute">
  <optional>
    <attribute name="lang" ns="http://www.w3.org/XML/1998/namespace">
      <text/>
    </attribute>
  </optional>
</define>

<define name="OPF20.optional-file-as-attribute">
  <optional>
    <attribute name="file-as" ns="http://www.idpf.org/2007/opf">
      <text/>
    </attribute>
  </optional>
</define>

<define name="OPF20.optional-role-attribute">
  <optional>
    <attribute name="role" ns="http://www.idpf.org/2007/opf">
      <text/>
    </attribute>
  </optional>
</define>

<define name="OPF20.optional-scheme-attribute">
  <optional>
    <attribute name="scheme" ns="http://www.idpf.org/2007/opf">
      <text/>
    </attribute>
  </optional>
</define>

<define name="OPF20.optional-event-attribute">
  <optional>
    <attribute name="event" ns="http://www.idpf.org/2007/opf">
      <text/>
    </attribute>
  </optional>
</define>

<define name="OPF20.optional-xsi-type">
  <optional>
    <attribute name="type" ns="http://www.w3.org/2001/XMLSchema-instance">
      <text/>
    </attribute>
  </optional>
</define>

<define name="OPF20.package-element">
  <element name="package">
    <attribute name="version">
      <value>2.0</value>
    </attribute>
    <attribute name="unique-identifier">
      <data type="IDREF"/>
    </attribute>
    <ref name="OPF20.optional-id-attribute"/>
    <ref name="OPF20.package-content"/>
  </element>
</define>

<define name="OPF20.package-content">
  <ref name="OPF20.metadata-element"/>
  <ref name="OPF20.manifest-element"/>
  <ref name="OPF20.spine-element"/>
  <optional>
    <ref name="OPF20.tours-element"/>
  </optional>
  <optional>
    <ref name="OPF20.guide-element"/>
  </optional>
</define>

<define name="OPF20.metadata-element">
  <element name="metadata">
    <ref name="OPF20.optional-id-attribute"/>
    <ref name="OPF20.metadata-content"/>
  </element>
</define>

<define name="OPF20.metadata-content">
  <choice>
    <interleave>
      <ref name="OPF20.dc-metadata-element"/>
      <optional>
        <ref name="OPF20.x-metadata-element"/>
      </optional>
    </interleave>
    <interleave>
      <oneOrMore>
        <ref name="DC.title-element"/>
      </oneOrMore>
      <oneOrMore>
        <ref name="DC.language-element"/>
      </oneOrMore>
      <oneOrMore>
        <ref name="DC.identifier-element"/>
      </oneOrMore>
      <zeroOrMore>
        <ref name="DC.optional-metadata-element"/>
      </zeroOrMore>
      <zeroOrMore>
        <ref name="OPF20.meta-element"/>
      </zeroOrMore>
      <zeroOrMore>
        <ref name="OPF20.any-other-element"/>
      </zeroOrMore>
    </interleave>
  </choice>
</define>

<define name="OPF20.dc-metadata-element">
  <element name="dc-metadata">
    <ref name="OPF20.optional-id-attribute"/>
    <ref name="OPF20.dc-metadata-content"/>
  </element>
</define>

<define name="OPF20.dc-metadata-content">
  <interleave>
    <oneOrMore>
      <ref name="DC.title-element"/>
    </oneOrMore>
    <oneOrMore>
      <ref name="DC.language-element"/>
    </oneOrMore>
    <oneOrMore>
      <ref name="DC.identifier-element"/>
    </oneOrMore>
    <zeroOrMore>
      <ref name="DC.optional-metadata-element"/>
    </zeroOrMore>
  </interleave>
</define>

<define name="DC.identifier-element" ns="http://purl.org/dc/elements/1.1/">
  <element name="identifier">
    <optional>
    <attribute name="id">
      <data type="ID"/>
    </attribute>
    </optional>
    <ref name="OPF20.optional-xsi-type"/>
    <ref name="OPF20.optional-scheme-attribute"/>
    <ref name="DC.metadata-common-content"/>
  </element>
</define>

<define name="DC.title-element" ns="http://purl.org/dc/elements/1.1/">
  <element name="title">
    <ref name="OPF20.optional-id-attribute"/>
    <ref name="OPF20.optional-xml-lang-attribute"/>
    <ref name="DC.metadata-common-content"/>
  </element>
</define>

<define name="DC.language-element" ns="http://purl.org/dc/elements/1.1/">
  <element name="language">
    <ref name="OPF20.optional-id-attribute"/>
    <ref name="OPF20.optional-xsi-type"/>
    <ref name="DC.metadata-common-content"/>
  </element>
</define>

<define name="DC.optional-metadata-element" ns="http://purl.org/dc/elements/1.1/">
  <choice>
    <element name="contributor">
      <ref name="OPF20.optional-id-attribute"/>
      <ref name="OPF20.optional-xml-lang-attribute"/>
      <ref name="OPF20.optional-file-as-attribute"/>
      <ref name="OPF20.optional-role-attribute"/>
      <ref name="DC.metadata-common-content"/>
    </element>
    <element name="coverage">
      <ref name="OPF20.optional-id-attribute"/>
      <ref name="OPF20.optional-xml-lang-attribute"/>
      <ref name="DC.metadata-common-content"/>
    </element>
    <element name="creator">
      <ref name="OPF20.optional-id-attribute"/>
      <ref name="OPF20.optional-xml-lang-attribute"/>
      <ref name="OPF20.optional-file-as-attribute"/>
      <ref name="OPF20.optional-role-attribute"/>
      <ref name="DC.metadata-common-content"/>
    </element>
    <element name="date">
      <ref name="OPF20.optional-id-attribute"/>
      <ref name="OPF20.optional-xsi-type"/>
      <ref name="OPF20.optional-event-attribute"/>
      <ref name="DC.metadata-common-content"/>
    </element>
    <element name="description">
      <ref name="OPF20.optional-id-attribute"/>
      <ref name="OPF20.optional-xml-lang-attribute"/>
      <ref name="DC.metadata-common-content"/>
    </element>
    <element name="format">
      <ref name="OPF20.optional-id-attribute"/>
      <ref name="OPF20.optional-xsi-type"/>
      <ref name="DC.metadata-common-content"/>
    </element>
    <element name="publisher">
      <ref name="OPF20.optional-id-attribute"/>
      <ref name="OPF20.optional-xml-lang-attribute"/>
      <ref name="DC.metadata-common-content"/>
    </element>
    <element name="relation">
      <ref name="OPF20.optional-id-attribute"/>
      <ref name="OPF20.optional-xml-lang-attribute"/>
      <ref name="DC.metadata-common-content"/>
    </element>
    <element name="rights">
      <ref name="OPF20.optional-id-attribute"/>
      <ref name="OPF20.optional-xml-lang-attribute"/>
      <ref name="DC.metadata-common-content"/>
    </element>
    <element name="source">
      <ref name="OPF20.optional-id-attribute"/>
      <ref name="OPF20.optional-xml-lang-attribute"/>
      <ref name="DC.metadata-common-content"/>
    </element>
    <element name="subject">
      <ref name="OPF20.optional-id-attribute"/>
      <ref name="OPF20.optional-xml-lang-attribute"/>
      <ref name="DC.metadata-common-content"/>
    </element>
    <element name="type">
      <ref name="OPF20.optional-id-attribute"/>
      <ref name="OPF20.optional-xsi-type"/>
      <ref name="DC.metadata-common-content"/>
    </element>
  </choice>
</define>

<define name="DC.metadata-common-content">
  <text/>
</define>

<define name="OPF20.x-metadata-element">
  <element name="x-metadata">
    <ref name="OPF20.optional-id-attribute"/>
    <ref name="OPF20.x-metadata-content"/>
  </element>
</define>

<define name="OPF20.x-metadata-content">
  <interleave>
    <zeroOrMore>
      <ref name="OPF20.meta-element"/>
    </zeroOrMore>
    <zeroOrMore>
      <ref name="OPF20.any-other-element"/>
    </zeroOrMore>
  </interleave>
</define>

<define name="OPF20.meta-element">
  <element name="meta">
    <ref name="OPF20.optional-id-attribute"/>
    <ref name="OPF20.optional-xml-lang-attribute"/>
    <attribute name="name">
      <text/>
    </attribute>
    <attribute name="content">
      <text/>
    </attribute>
    <optional>
      <attribute name="schemascheme">
        <text/>
      </attribute>
    </optional>
    <ref name="OPF20.meta-content"/>
  </element>
</define>

<define name="OPF20.meta-content">
  <empty/>
</define>

<define name="OPF20.manifest-element">
  <element name="manifest">
    <ref name="OPF20.optional-id-attribute"/>
    <ref name="OPF20.manifest-content"/>
  </element>
</define>

<define name="OPF20.manifest-content">
  <oneOrMore>
    <ref name="OPF20.item-element"/>
  </oneOrMore>
</define>

<define name="OPF20.item-element">
  <element name="item">
    <attribute name="id">
      <data type="ID"/>
    </attribute>
    <attribute name="href">
      <text/>
    </attribute>
    <attribute name="media-type">
      <text/>
    </attribute>
    <optional>
      <attribute name="fallback">
        <data type="IDREF"/>
      </attribute>
    </optional>
    <optional>
      <attribute name="fallback-style">
        <data type="IDREF"/>
      </attribute>
    </optional>
    <optional>
      <attribute name="required-namespace">
        <text/>
      </attribute>
      <optional>
        <attribute name="required-modules">
          <text/>
        </attribute>
      </optional>
    </optional>
    <ref name="OPF20.item-content"/>
  </element>
</define>

<define name="OPF20.item-content">
  <empty/>
</define>

<define name="OPF20.spine-element">
  <element name="spine">
    <ref name="OPF20.optional-id-attribute"/>
    <optional>
      <attribute name="toc">
        <data type="IDREF"/>
      </attribute>
    </optional>
        <ref name="OPF20.spine-content"/>
  </element>
</define>

<define name="OPF20.spine-content">
  <oneOrMore>
        <ref name="OPF20.itemref-element"/>
  </oneOrMore>
</define>

<define name="OPF20.itemref-element">
  <element name="itemref">
    <ref name="OPF20.optional-id-attribute"/>
    <attribute name="idref">
      <data type="IDREF"/>
    </attribute>
    <optional>
      <attribute name="linear">
        <choice>
          <value>yes</value>
          <value>no</value>
        </choice>
      </attribute>
    </optional>
    <ref name="OPF20.itemref-content"/>
  </element>
</define>

<define name="OPF20.itemref-content">
  <empty/>
</define>

<define name="OPF20.tours-element">
  <element name="tours">
    <ref name="OPF20.optional-id-attribute"/>
    <ref name="OPF20.tours-content"/>
  </element>
</define>

<define name="OPF20.tours-content">
  <oneOrMore>
    <ref name="OPF20.tour-element"/>
  </oneOrMore>
</define>

<define name="OPF20.tour-element">
  <element name="tour">
    <ref name="OPF20.optional-id-attribute"/>
    <attribute name="title">
      <text/>
    </attribute>
    <ref name="OPF20.tour-content"/>
  </element>
</define>

<define name="OPF20.tour-content">
  <oneOrMore>
        <ref name="OPF20.site-element"/>
  </oneOrMore>
</define>

<define name="OPF20.site-element">
  <element name="site">
    <ref name="OPF20.optional-id-attribute"/>
    <attribute name="title">
      <text/>
    </attribute>
    <attribute name="href">
      <text/>
    </attribute>
    <ref name="OPF20.site-content"/>
  </element>
</define>

<define name="OPF20.site-content">
  <empty/>
</define>

<define name="OPF20.guide-element">
  <element name="guide">
    <ref name="OPF20.optional-id-attribute"/>
    <ref name="OPF20.guide-content"/>
  </element>
</define>

<define name="OPF20.guide-content">
  <zeroOrMore>
    <ref name="OPF20.reference-element"/>
  </zeroOrMore>
</define>

<define name="OPF20.reference-element">
  <element name="reference">
    <ref name="OPF20.optional-id-attribute"/>
    <attribute name="type">
      <text/>
    </attribute>
    <optional>
    <attribute name="title">
      <text/>
    </attribute>
    </optional>
    <attribute name="href">
      <text/>
    </attribute>
    <ref name="OPF20.reference-content"/>
  </element>
</define>

<define name="OPF20.reference-content">
  <empty/>
</define>

<define name="OPF20.any-other-element">
  <element>
    <anyName>
      <except>
        <nsName ns="http://www.idpf.org/2007/opf"/>
        <nsName ns="http://purl.org/dc/elements/1.1/"/>
      </except>
    </anyName>
    <zeroOrMore>
      <choice>
        <attribute>
          <anyName/>
        </attribute>
        <text/>
        <ref name="OPF20.any-other-element"/>
      </choice>
    </zeroOrMore>
  </element>
</define>

</grammar>

附録 B: 貢献者

本仕様書は出版社、リーディングシステムのベンダー、ソフトウェア開発者、関連する標準規格の専門家たちの協力によって生み出された。

本仕様書のバージョン 2.0 は the International Digital Publishing Forum (IDPF) Open eBook Publication Structure (OEBPS) ワーキンググループによって作成された。 改定バージョンである 2.0 が発表された時点でのワーキンググループのメンバーは以下のとおりである。

この取り組みの元になった OPS 仕様書の前バージョンは OEBPS 1.2 である。OEBPS 1.2 は the Open eBook Forum Publication Structure ワーキンググループによって作成された。OEBPS 1.2 が作成された期間におけるワーキンググループの活動メンバーは以下のとおりである。

附録 C: 謝辞

ワーキンググループは以下の個人の貢献に特に感謝の念を表す。OPS と OPF RelaxNG スキーマの作成、OPS の NVDL 定義の作成とさまざまな技術的手腕について Peter Sorotokin に。XML アイランドの考案と起草、また技術面全般への参与、本仕様書を作成するにあたり使用した XML テンプレートについて Ben Trafford に。OPF NCX のセクションの起草、一貫したアクセシビリティの指導、幅広い技術的なアドバイスについて George Kerscher に。指導による貢献、仕様書の編集や歴史ある OEBPS 1.2 との継続性への取り組みについて Brady DugaJon Noring に。ワーキンググループでのリーダーシップと動機付け、仕様書の起草と技術的な貢献について Garth Conboy に。

附録 D: サポート情報とエラッタ

サンプルファイル、仕様の実装など、全ての IDPF の仕様書に関する追加情報については、 http://www.idpf.org/forums にある公開フォーラムを訪れて頂きたい。出版物から仕様による不具合が発見された場合には、その不具合についてフォーラムに投稿して頂きたい。担当のワーキンググループが不具合を確認して、必要なものについては未解決な仕様の修正項目に加えることだろう。修正項目は本仕様の次のバージョンに盛り込まれるはずである。


修正履歴
2010-09-07

2.4: スパインの最初のセンテンスに誤訳があったため訂正。
誤:以下の manifest 要素は 一つ以上の itemref 要素を内包した spine 要素を一つだけ持たなければならない(must)。
正:manifest 要素に続いて、一つ以上の itemref 要素を内包した spine 要素が一つだけなければならない(must)。
ご指摘頂いた中井央氏に感謝致します。

2010-11-14

2.4.1: 宣言型目次 − NCXの第三パラグラフの訳文を改善。
前:本仕様での NCX の実装では、必要ない付加的な(optional)要素とメタデータアイテムがある。
後:本仕様の NCX の実装では、幾つかの付加的な(optional)要素とメタデータアイテムは実装を要求されない。
ご指摘頂いた小林徳磁氏に感謝致します。

訳者注
*1, *2
原文は "OPS Package Document"。OPF パッケージドキュメント(OPF Package Document)の誤りか。