【注意】このドキュメントは、IDEFのePUBの仕様の一つであるOpen Packaging Format (OPF) 2.0 v1.0 Recommended Specification September 11, 2007の和訳です。
このドキュメントの正式版はIDEFのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。

1.0: 概要

1.1: 目的と範囲

電子書籍技術が市場において広く成功を収めるためには、読書システムは、多くの様々な著作物に容易にアクセスできる必要があります。関連するもう一つの仕様(オープン・パブリケーション・ストラクチャ(OPS)仕様)は、電子出版物のコンテンツを表現するための標準を記述しており、コンテンツの普及に対する障壁を軽減させることを目的としています。具体的には、この仕様は次のことを目的としています。

出版ツール提供者とコンテンツ提供者(例えば、出版者、著者、その他の表示するコンテンツを有している人)に対し、様々な読書システムにおける電子的コンテンツの忠実さ、精度、アクセシビリティ、および適切な表示を保証する、最小限かつ共通のガイドラインを提供すること。そして、
既存のコンテンツ形式の標準に基づくこと。そして、
電子書籍が流通網をスムーズに流れるようなコンテンツ記述の標準的な手段を定義すること。

このドキュメント(オープン・パッケージング・フォーマット(OPF)仕様)では、OPS出版物の様々な構成要素を結びつけるメカニズムを定義し、電子出版物に構造とセマンティクスを追加します。具体的には、OPFは次のとおりです。

電子出版物のすべての構成要素(マークアップ・ファイル、画像、ナビゲーション構造など)を記述し、参照付けを行う。
出版物レベルのメタデータを提供する。
出版物の読み順を指定する。
OPSでサポートされていない拡張を用いる際に使用すべきフォールバック情報を提供する。
宣言型目次(NCX)を指定するためのメカニズムを提供する。

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

3つ目の仕様(OEBPSコンテナ・フォーマット(OCF)仕様)では、電子出版物のすべての構成要素を送信、配信、保存するために一つのファイルにまとめてパッケージ化する標準メカニズムを定義しています。

1.2: 定義

コンテンツ提供者

出版者、著者、または、この仕様およびOPS仕様に記述されている形式で1つ以上の読書システムに出版物を提供するその他の情報提供者。

非推奨

この仕様では認められているが、推奨(recommended)されない機能。このような機能は、将来の改定で削除されるかもしれません。適合した読書システムは、非推奨の機能をサポートしなければなりません(must)。

拡張モジュール

モジュール化されたXML語彙のモジュール(すなわち、その仕様内に名前付きモジュールが定義されている)で、その仕様でサポートされている必要がないもの(例えば、OPSコンテキストにおけるXHTMLのrubyやformsのモジュール)。

インラインXMLアイランド

インラインXMLアイランドは、OPS出版物のXHTML優先語彙ドキュメント内に存在する非優先語彙を用いるか、拡張モジュールを用いたXMLドキュメントのフラグメントです。

NCX

宣言型目次(Navigation Center eXtended、すなわち、NCX)。

OCF

OEBPSコンテナ・フォーマット(OEBPS Container Format)は、OPS出版物のすべての構成要素を一つのファイル・システムのエンティティに結合できるメカニズムを定義します。

OEBPS

Open Publication Structure。この仕様(OPF)の以前のバージョンとその関連仕様(OPS)は、OEBPSという一つの仕様に統合されていました。当バージョンでは、仕様のモジュール採用をサポートするために、OEBPSをOPFとOPSの別々の仕様に分けました。以前の統合仕様の最終バージョンは、OEBPS 1.2でした。

OPF

オープン・パッケージング・フォーマット(Open Packaging Format) ― この標準 ― は、メタデータ、読み順、ナビゲーション情報を含む、OPS標準に準拠して出版された作品の全構成要素をOPS出版物にパッケージ化するメカニズムを定義します。

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

OPS出版物を記述し、OPFパッケージ・ドキュメント自身の一部ではないOPS出版物が使用するすべてのファイルを参照するXMLドキュメント。出版物内の他のすべてのファイルを識別し、それに関する説明情報を提供します。OPFパッケージ・ドキュメントは、この仕様で定義されており、ここで定義されているOPFパッケージ・スキーマに有効です。

OPFパッケージ・ドキュメントの「ルート・ファイル」には、.opfという拡張子を用いるべき(should)です。このXMLファイルは、XMLの一般的なエンティティのメカニズムを用いて他のXMLファイルを参照できます(may)が、そのファイルには.opfというファイル拡張子を使用してはなりません(must not)。出版物が非常に大きい場合には、この構成を用いてOPFパッケージ・ドキュメントの作成を簡素化できます。しかし、最も一般的なケースとしては、OPFパッケージ・ドキュメントは、拡張子.opfを採用した一つのXMLファイルです。

OPS

Open Publication Structure ― この標準の姉妹標準 ― は、OPSコンテンツ・ドキュメントの構築に必要なマークアップを定義します。

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

OPFパッケージ・ドキュメントのspineに正当に表示可能な、OPS仕様に準拠したXHTMLやDTBookやアウト・オブ・ラインXMLドキュメント。

OPSコア・メディア・タイプ

OPS仕様で定義されている、すべての読書システムがサポートしなければならない(must)MIMEメディア・タイプ。

OPS出版物

OPSコンテンツ・ドキュメント、OPFパッケージ・ドキュメント、そして、一般的に構造化テキストや図を含む様々なメディア・タイプのその他のファイルの集合で、出版物の結合ユニットを構成するもの。

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

アウト・オブ・ラインXMLアイランドは、OPS出版物内のXMLドキュメントで、優先語彙を用いて記述されていないもの、または優先語彙を用いて記述されているが、拡張モジュールを用いるもの。これは、完全に独立した、完全で有効なXMLドキュメントです。

優先語彙

OPSをサポートしたXHTMLマークアップ、および/または、DTBookマークアップのみで構成されるXML。

読者

出版物を読む人。

読書システム

OPS出版物(OCFコンテナでパッケージ化されているだろう)を受け入れ、コンテンツの消費者がそれを利用できるようにするハードウェア、および/または、ソフトウェアの組み合わせ。読書システムのアーキテクチャは、非常に多様でありえます。読書システムは、完全に1台の機器として実装可能です(may)が、数台のコンピュータに分散することもできます(may)。特に、読書システムの構成要素である読書装置は、OPS出版物を直接受け入れる必要はありません(need not)が、すべての読書システムはそれを受け入れなければなりません(must)。読書システムには、圧縮、インデックス化、暗号化、権利管理、配信などの追加処理機能を含むことができます(may)。

XMLドキュメント

XMLドキュメントは、XML 1.1(http://www.w3.org/TR/xml11/)で定義されている完全で有効なXMLドキュメントです。

XMLドキュメント・フラグメント

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

XMLアイランド

インラインXMLアイランドまたはアウト・オブ・ラインXMLアイランド。

XML名前空間

XML名前空間、または単に名前空間とも呼ばれ、XML名前空間(http://www.w3.org/TR/xml-names11/)に準拠していなければなりません。

1.3: 他の仕様との関係

この仕様は、他の仕様のサブセットとアプリケーションを組み合わせて作成しています。組み合わせることにより、電子文書の構築、編成、提供、厳密な交換が容易になります。

Extensible Markup Language (XML) 1.1 (Second Edition)仕様 (http://www.w3.org/TR/xml11/)、および
Namespaces in XML 1.0 (Second Edition) (http://www.w3.org/TR/xml-names11/)、および
The OPS 仕様 (http://www.idpf.org/ops/ops2.0/download/)、および
XHTML? 1.1 - Module-based XHTML - Second Edition仕様 (http://www.w3.org/TR/xhtml11/)、および
Specifications for the Digital Talking Book (DTB) (http://www.niso.org/standards/resources/Z39-86-2005.html)、および
Dublin Core Metadata Element Set, Version 1.1仕様 (http://dublincore.org/documents/2004/12/20/dces/)およびMARC関係子コード表 (http://www.loc.gov/marc/relators/)、および
Unicode Standard, Version 4.0. Reading, Mass.: Addison-Wesley, 2003 新バージョンの公表により時々更新される。(標準およびUnicode Character Databaseのバージョンの最新バージョンや追加情報に関しては、http://www.unicode.org/unicode/standard/versionsを参照)、および
特定のMIMEメディア・タイプ (http://www.ietf.org/rfc/rfc4288.txtとhttp://www.iana.org/assignments/media-types/index.html)、および
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).

1.3.1: XMLとの関係

XMLは一般性と簡潔さを備えており、XMLドキュメントが将来の技術や利用にうまく適合する可能性が高いという理由により、OPFは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ドキュメントの名前空間宣言は、URIをデフォルト名前空間として識別し、名前空間接頭辞がない要素に適用できます(may)。XML名前空間接頭辞は、接尾語要素や属性名とコロンで区切られています。

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

例:

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

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

ダブリン・コアのメタデータは、十分に実用的なメタデータを提供しつつも、著者や出版者の目録作成の負担を最小限にするように設計されています。この仕様では、ダブリン・コア1.1メタデータ要素セット(http://dublincore.org/documents/2004/12/20/dces/)をサポートしており、より詳細な情報が必要な領域に対応するために、少しの追加属性を補記しています。例えば、ダブリン・コアのcreatorとcontributor要素に、OPFのrole属性を追加することにより、関係子コードで表された寄与者の役割などの、出版物の寄与者に関するより詳細な仕様を定義できるようになります。

コンテンツ提供者は、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文字が単なる8ビットの文字であるかのように表示してはなりません(must not)。例えば、有害物質の記号(0x2623)を、正しいグリフの採用によってサポートする必要はありません(need not)が、そのコンポーネント・バイトが「&#」(0x0026 0x0023)の2文字であるかのように解析したり表示したりしてはなりません(must not)。

読書システムの一貫した検索やソート機能の実装をサポートするためには、Unicode正規形C(NFC)を使用する必要があります(required)(http://www.w3.org/TR/charmod-norm/を参照)。

1.4: 適合性

このドキュメントの「しなければならない」(must)、「してはならない」(must not)、「必須である／要求される」(required)、「することになる」(shall)、「することはない」(shall not)、「すべきである／する必要がある」(should)、「推奨される」(recommended)、「することができる／してもよい」(may)、および「選択できる／任意である」(optional)というキーワードは、RFC 2119で記述されているとおりに解釈されなければなりません(must)。

この項では、OPFパッケージ・ドキュメントとそれを処理する読書システムの適合性を定義しています。

1.4.1: パッケージの適合性

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

1.4.1.1: パッケージの適合性

適合した個々のOPFパッケージ・ドキュメントは、次の要件を満たさなければなりません(must)。

整形式のXMLドキュメント(XML 1.1で定義されているとおりの)であること。そして、
UTF-8またはUTF-16で符号化されていること。そして、
付録Aで定義しているOPFパッケージ・スキーマに従った有効なXMLドキュメントであること。そして、
1つ以上のXMLファイルで構成することができます(may)が、拡張子.opfを使用できる(may)ファイルは1つのみであること。

1.4.1.2: 出版物の適合性

ファイルの集合体は、次の場合にOPS出版物に適合しています。

上記のパッケージ適合性要件に従った一つのOPFパッケージ・ドキュメントを含んでいること。そして、
出版物のファイルのうちの1だけがファイル拡張子.opfを使用できる(may)こと。そのようなファイルが存在していれば、それはOPFパッケージ・ドキュメントの「ルート・ファイル」でなければならない(must)こと。そして、
OPFパッケージ・ドキュメントには、OPFパッケージ・ドキュメント自身を構成するファイルを除く、OPS出版物内の各ファイルに対応したマニフェスト・エントリーが一つだけ含まれること。そして、
出版物内の各ファイルのマニフェスト・エントリーに、ファイルのMIMEメディア・タイプを指定すること(http://www.ietf.org/rfc/rfc2046.txtを参照)。そして、
OPSコア・メディア・タイプの1つであるとマニフェスト・エントリーが見なしている各ファイルが、そのMIMEメディア・タイプの定義に準拠すること、そして
OPFパッケージ・ドキュメントのスパインに挙げられている各ファイルは、OPS仕様で定義されているOPSコンテンツ・ドキュメント要件に準拠していなければならない(must)。そして、
NCXを含まなければならない(must)。そして、
metadata要素または非推奨のdc-metadata要素が、ダブリン・コア・タグ・セットの、少なくとも1つのidentifier要素、少なくとも1つのtitle要素、少なくとも1つのlanguage要素を含んでいること。そして、
package要素のunique-identifier属性が、ダブリン・コアのunique-identifier要素に対して、正しいXMLのIDREFであること。そして、
ダブリン・コアのcreatorおよびcreator要素のOPFのrole属性で指定する拡張の値は、MARC関係子コード・リストに登録されているものか、oth.で始まらなければならない(must)。そして、
guide要素のtype属性で指定された拡張の値が、otherで始まること。そして、
package要素のversion属性の値には、2.0を指定すること。そして、
package要素の名前空間は、http://www.idpf.org/2007/opfでなければならない。

この仕様とOPS仕様は、パッケージ・ドキュメントとOPSコンテンツ・ドキュメントに対し、適合性の制約をさらに課します。

1.4.2: 読書システムの適合性

この仕様では、OPS出版物を扱う際の読書システムの適合性を定義しています。OPSコンテンツ・ドキュメントには、OPS仕様で記述されている適合性要件がさらにあります。読書システムは、次のとおりにドキュメントを処理する場合に限り、適合しています。

読書システムは、OPFパッケージ・ドキュメントを扱う場合、次のとおりでなければなりません(must)。
1. この仕様の2項で記述されているとおりに、すべての要素と属性を処理すること。そして、
2. この仕様の2項で記述されていないすべての要素と属性を無視すること。そして、
3. 上記のXML名前空間の項で定義されているとおりに、適切な名前空間仕様の存在を確認すること。
読書システムは、OPFスパインを用いたナビゲーションを提供する場合には、OPSコンテンツ・ドキュメントではないコンテンツを表示してはなりません(must not)。
読書システムは、OEBPS 1.2パッケージを扱う場合には、適合するOEBPS 1.2読書システムが処理するのと同じように処理を行わなければなりません(must)。OEBPS 1.2読書システムが処理するのと同じように処理を行わなければならない(must)のは、パッケージ内で参照されるコンテンツ・ドキュメントではなく、OEBPS 1.2パッケージのみであるということに注意。
読書システムは、OEBPS 1.2出版物を扱う場合には、適合するOEBPS 1.2読書システムが処理するのと同じように処理を行うべき(should)です。このような読書システムは、任意のレベルの読書システムの適合性として「後方互換適合性」を要求できます。

1.4.3: OPFバージョン2.0の互換性

OPFのバージョン2.0は、実質的には「新しい」仕様ではありません。しかし、バージョン2.0には、OEBPSバージョン1.2からの他の多くの変更点に加え、1つの重要な機能強化を行っています。具体的には、次の点が最も実質的な追加点です。

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の完全互換のサブセットではありません(新たな名前空間処理の要件など)。

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

この仕様に準拠している出版物は、XML OPFパッケージ・ドキュメントを1つだけ含まなければならず(must)、これによって、OPS出版物を構成するOPSコンテンツ・ドキュメント、画像、その他のオブジェクトと、それらがどのように相互に関連するかが定まります。

出版物を構成するファイル群の中から容易に識別できるように、OPFパッケージ・ドキュメントは、拡張子「.opf」で終わる名前にすべき(should)です。OPSパッケージ・ドキュメント(訳注：OPFパッケージ・ドキュメントの誤りか)のMIMEメディア・タイプは、application/oebps-package+xmlです。この仕様では、ファイルを物理的に一つにまとめて、1つの転送用データを作成する方法(zipやtarを用いるなどの)を定義していません。この機能は、OEBPSコンテナ・フォーマット(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属性の値は、2.2.10項で記述しているどのダブリン・コアidentifier要素が、パッケージの優先識別子や基本識別子を示すかを指定します。OPFパッケージ・ドキュメントの著者には、特定の1つのみのパッケージ(すなわち、パッケージ・ドキュメントのmanifestから参照されるファイルの集合)に対して一意である基本識別子を選択する責任があります。

一意性の要件があるにもかかわらず、読書システムは、同じ一意の基本識別子を持つ2つの異なるパッケージに遭遇した場合にも、著しく機能低下してはなりません(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-metadataにすべてのdc要素を含まなければならず(must)、その他のすべてのmetadata要素は、存在していれば、x-metadataに含まなければなりません(must)。dc-metadata要素が用いられてなければ、すべてのメタデータ要素は、metadata要素に直接含まなければなりません(must)。

ダブリン・コア・メタデータ・イニシアティブ(http://www.dublincore.org/)が定義しているように、必須の(required)metadataやdc-metadata(非推奨)の要素には、特定の出版物レベルのメタデータが含まれています。下の記述は、便宜のために含まれており、ダブリン・コア自身の定義の方が優先します(http://dublincore.org/documents/2004/12/20/dces/を参照)。

XHTML 1.1のmeta要素と似ているけれども出版物全般に適用可能なインスタンスである、meta要素の1つ以上の任意の(optional)インスタンスは、metadata要素または非推奨のx-metadata要素内に置くことができます(may)。これにより、コンテンツ提供者は、ダブリン・コア仕様に記述されているデータを超えて任意のメタデータを表現できます。個々のOPSコンテンツ・ドキュメントには、ドキュメント固有のメタデータ用に、meta要素を直接(XHTML 1.1のように)含むことができます(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要素など)の複数のインスタンスを、意味を変えることなく、他のメタデータ要素に点在させることができます。

ダブリン・コアの各フィールドは、コンテンツをフィールドの値として持つ要素で表現されます。ダブリン・コアのtitle、identifier、languageを、それぞれ少なくとも1つはmetadata要素に含まなければなりません(must)。OPFパッケージ・ドキュメントの他の任意の要素と同じく、ダブリン・コア要素は、id属性を指定できます(may)。パッケージのunique-identifier属性が参照するダブリン・コアのidentifierの少なくとも1つに、idを指定しなければなりません(must)。

creatorとcontributorというダブリン・コアのメタデータ・フィールドは特定の寄与者の役割(著者、編集者、イラストレーターなど)を区別しないため、この仕様では、それを目的とした任意のrole属性を追加しています。roleの議論に関しては、2.2.6項を参照してください。

ダブリン・コアのcreatorとcontributorのフィールドのマシン処理を促進するために、この仕様では、これらの要素に任意の(optional)file-as属性を追加しています。この属性は、コンテンツの正規形を指定するために用いられます。file-asの議論に関しては、2.2.2項を参照してください

この仕様では、ダブリン・コアのidentifier要素にscheme属性も追加しており、そのidentifierの値を生成または定義したシステムや典拠から識別子の値を切り離すための構造的なメカニズムを提供しています。schemeの議論に関しては、2.2.10項を参照してください。

この仕様では、ダブリン・コアのdate要素にevent属性も追加しており、様々な出版物の特定の日付(作成日、出版日、変更日など)をコンテンツ提供者が区別できるようにしています。eventの議論に関しては、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、relation、rights、sourceとsubjectです。この仕様は、これらの属性にいかなる特定の規則も課しません(ただし、下記で述べる、xml:langを用いたヒューリスティックスの例外がありえる)。

次の小項目では、個々のダブリン・コアのメタデータ要素について説明しています。

2.2.1: <title> </title>

出版物のタイトル。OPFパッケージ・ドキュメントは、この要素タイプのインスタンスを少なくとも1つは含まなければなりません(must)が、複数のインスタンスも認められています。titleのメタデータを表示するあらゆる読書システムは、最も適切なtitle要素の内容を表示するべき(should)です。最も適切なtitleの決定方法についてはこの仕様では定義しませんが、利用可能なフォント、 xml:lang属性の検討、その他のヒューリスティックスを採り入れることができます(may)。このようなアルゴリズムがない場合には、適合した読書システムは、最初のtitle要素か、すべてのtitle要素かのどちらかが適切であると考えるべき(should)です。

2.2.2: <creator> </creator>

出版物の主要な作者または著者。creator要素に記述されている人物に副次的な寄与を行った付加的な寄与者の名前は、contributor要素に記述すべき(should)です。

複数の共著者が存在する出版物は、著者を1人ずつ記述した複数のcreator要素を作成すべき(should)です。creator要素の順序は、読書システムが表示すべき(should)作者の名前の順序を定義していると推定されます。

この仕様では、creator要素の内容が、読者への表示内容と同じく、1人の名前を記述したテキストであることを推奨します。

この仕様では、roleとfile-asという2つの任意の(optional)属性をcreator要素に追加しています。roleの値は、contributor要素に対して2.2.6項で定義しているものと同じです。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要素には複数のインスタンスがサポートされており、それぞれに任意のフレーズやキーワードが含まれます。この仕様では、米国議会図書館件名標目表などの、subjectの命名スキームの標準化は試みていません。

2.2.4: <description> </description>

出版物のコンテンツの記述。

2.2.5: <publisher> </publisher>

ダブリン・コア・メタデータ要素セット(http://dublincore.org/documents/2004/12/20/dces/)で定義されている出版者。

2.2.6: <contributor> </contributor>

出版物に対し、creator要素に記述されている人物に副次的な寄与を行った関係者。

この要素のセマンティクスは、寄与の重要性を除いては、creatorのものと同じです。読書システムは、寄与者情報を併記せずに作成者情報を表示することも自由に選択できます。

この仕様では、roleとfile-asという2つの任意の(optional)属性をcontributor要素に追加しています。file-as属性は、creatorに対して定義されているものと同じで、2.2.2項で記述しています。

role属性に用いられる値の規範的なリストは、MARC関係子コード・リスト(http://www.loc.gov/marc/relators/)で定義されています。roleを指定する場合には、適用可能であれば、MARCに登録されている3文字の値を、用いなければなりません(must)。このリストは大規模なものですが、目的とするroleがこの定義済みの値でカバーされていなければ、他の値を追加することもできます。この値はoth.で始まらなければならず、otherという関係子コードの細目であるとみなされるでしょう。この仕様の他の構成子と同じく、これらの値は、大文字と小文字を区別しており、完全に小文字でコード化しなければなりません(must)。

ここでは、便宜のために、例としていくつかの関係子コード値を挙げておきます。完全なリストに関しては、上記で引用したMARCコードのリストを参照してください。

編曲者/脚色者 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の「日時の形式」と、その基となったISO 8601で定義されている形式の出版日。具体的には、時刻のない日付は、YYYY[-MM[-DD]]の形式、すなわち、必須の(required)4桁の年、任意の(optional)2桁の月、そして月がある場合には、任意の(optional)2桁の日で表されます。

date要素には、1つの任意の(optional)OPFのevent属性があります。eventに対する値は、この仕様では定義しませんが、考えられる値として、creation、publication、modificationを含むことができます(may)。

2.2.8: <type> </type>

typeには、コンテンツの一般的なカテゴリー、機能、ジャンルや集合レベルを記述する用語を含みます。推奨されるベスト・プラクティスは、統制語彙から値を選択することです。

2.2.9: <format> </format>

資源のメディア・タイプや特徴。ベスト・プラクティスは、統制語彙(例えば、MIMEメディア・タイプ)の値を用いることです。

2.2.10: <identifier> </identifier>

資源を一意に識別するために用いる文字列や数。OPFパッケージ・ドキュメントには、この要素タイプのインスタンスを少なくとも1つは含まなければなりません(must)が、複数のインスタンスを含むこともできます。

2.1項で記述したパッケージのunique-identifier属性から参照を付与できるように、少なくとも1つのidentifierにid(XMLの「ID」データ型の値)を指定しなければなりません(must)。

identifier要素には、この仕様で定義している任意の(optional)OPFのscheme属性が存在しています。scheme属性には、例えば「ISBN」や「DOI」のような、identifier要素に含まれるテキストを生成または割り当てたシステムや典拠を指定します。scheme属性の値は、特定のスキームで求められている場合のみ、大文字と小文字を区別します。

この仕様では、特定の出版識別子スキームの標準化や推薦を行いません。特定のURLやISBNの使用方法に関しては、この仕様ではまだ扱っていません。現時点では、ダブリン・コアでは、識別子スキームは定義されていません。

2.2.11: <source> </source>

出版物の元となった資源に関する情報。ダブリン・コア・メタデータ要素セット(http://dublincore.org/documents/2004/12/20/dces/)を参照してください。

2.2.12: <language> </language>

出版物の知的内容の言語を識別します。OPFパッケージ・ドキュメントは、この要素タイプのインスタンスを少なくとも1つは含まなければなりません(must)が、複数のインスタンスを含むこともできます。この要素の内容は、RFC 3066(http://www.ietf.org/rfc/rfc3066.txt)、またはその後継規格であるIETF標準手順(IETF Standards Track)に従わなければなりません(must)。ダブリン・コアでは、他の記述も認められていますが、この仕様はそうではありません。

2.2.13: <relation> </relation>

補助的な資源と、その資源と出版物との関係に関する識別子。

2.2.14: <coverage> </coverage>

出版物の内容の範囲や領域。推奨されるベスト・プラクティスは、統制語彙から値を選択することです。ダブリン・コア・メタデータ要素セット(http://dublincore.org/documents/2004/12/20/dces/)を参照してください。

2.2.15: <rights> </rights>

権利に関するステートメント、または権利への参照。この仕様では、著作権情報や詳細な権利の記述は直接表示されるべき(should)です。

この仕様では、コンテンツ提供者が安全な配布者に対してコンテンツの購読権や複製販売権などのライセンス条件を指定する方法は扱っていせん。

2.3: マニフェスト

manifestは必須(required)で、出版物を構成する全ファイルのリスト(例えば、コンテンツ・ドキュメント、スタイルシート、画像ファイル、組み込みフォント・ファイル、包含するスキーム)を提供しなければなりません(must)。manifest要素には、1つ以上の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)。

manifestには、一つの資源(href)を2回以上記述してはなりません(must not)。

コンテンツ・ドキュメントのルート要素は、manifest内の関連するitem要素のmedia-typeと一致していなければなりません(must)。

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

OPS仕様では、適合したすべての読書システムがサポートしなければならない(must)OPSコア・メディア・タイプの集合(例えば、XHTML、PNG、SVG)を定義しています。これらのメディア・タイプのみを用いた出版物では、manifestは、出版物のコンポーネント・ファイルを直接記述するだけです。しかし、コンテンツ提供者は、さらにメディア・タイプの項目を参照する出版物を作成することもできます(may)。適合したすべての読書システムでこのような出版物を読めるようにするために、コンテンツ提供者は、この各アイテムに対し、代替となる「フォールバック」アイテムを提供しなければなりません(must)。OPSコア・メディア・タイプではない全てのアイテムに関しては、関連するフォールバック・アイテムの少なくとも1つがOPSコア・メディア・タイプに含まれているタイプでなければならない(must)か、場合によっては、非優先XML語彙を含んだドキュメントにCSSスタイリングを提供できます(may)。

この仕様とOPS仕様では、合わせて、OPSコア・メディア・タイプのフォールバックを指定するための4つの異なるメカニズムを定義しています。これらは次の通りです。

この仕様は、object要素を用いて参照されるインラインの「被置き換え」資源に関しては、OPS仕様の2.3.6項で記述している要素固有の置き換え性能に依存します。
img要素で参照されるインラインの「被置き換え」資源に関しては、OPS仕様の2.3.4項で記述している、altまたはtitle属性のテキストの値が、有効なフォールバックを提供します。
インラインXMLアイランドに関しては、OPS仕様の2.6.3.1項で記述しているスイッチ・ベースのフォールバック・メカニズムが提供されています。
非インラインの参照先に関しては、ドキュメントやパッケージから参照されているか否か、インライン「被置き換え」資源に関しては、img要素を用いて参照されているか否かに関係なく、フォールバック情報を提供するために、パッケージitem要素の様々な属性を用います。これに関しては、この仕様のこの項で定義しています。

フォールバックを指定するために、出版物のNCX(下記を参照)を指定したメディア・タイプapplication/x-dtbncx+xmlを持つファイルをコア・メディア・タイプであると見なすべき(should)で、従って、このファイルにはフォールバック情報を提供してはなりません(must not)。

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

OPSコア・メディア・タイプではない資源(例えば、コアではない画像タイプ、テキスト・ファイル、PDFファイル)を指定するitemは、フォールバックを指定しなければなりません(must)。この場合、そのフォールバックは、別のitemを指すfallback属性で識別しなければなりません。アウト・オブ・ラインXMLアイランドのフォールバック要件に関しては、2.3.1.2項を参照してください。

itemは、fallback属性を用いてフォールバックitemを識別し、これには、フォールバックを識別する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に達する)まで、フォールバック・チェーンを辿り続けなければなりません(must)。読書システムは、さらに進み続けることもできる(may)し、チェーンの中の任意のitemを表示することもできます(may)。要素固有のフォールバック情報がない場合(すなわち、imgとobject)には、OPSコア・メディア・タイプがない出版物の全てのitemは、OPSコア・メディア・タイプがあるitem(または、下記で指定しているように、fallback-style属性があるitem)に対するフォールバックを直接または間接的に指定しなければなりません(must)。

フォールバック・チェーンは終了しなければなりません(must)。循環参照は認められていません。それでもなお、読書システムは、そのようなループに遭遇した場合にも、著しく機能低下すべきではありません(should not)。

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

アウト・オブ・ラインXMLアイランド(優先語彙で記述されていないXMLドキュメント)である資源を指定するitem。itemは、次の場合にアウト・オブ・ラインXMLアイランドです。

優先語彙で記述されていないXMLドキュメント(すなわち、application/xhtml+xmlやapplication/x-dtbook+xmlや非推奨のtext/x-eob1-documentではないmedia-typeを持つXMLドキュメント)である資源を指定するとき。または、
優先語彙で記述されているXMLドキュメントである資源を指定しているが、拡張モジュールを組み込んでいるとき。

アウト・オブ・ラインXMLアイランドのフォールバックの決定と処理には、より多くの情報が必要で、それによって自由度が増します。アウト・オブ・ラインXMLアイランドのitemの名前空間は、required-namespace属性で指定しなければならず(must)、そのフォールバックは、fallback属性で別のitemを指すか、アイランドを表示するために使用できるCSSスタイリングをfallback-style属性で提供するかのどちらかで識別しなければなりません(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では、拡張モジュールにはruby、forms、server-side-image-map、intrinsic-eventsが含まれます。

required-modules属性値における非拡張モジュール名の記述も認められており、このモジュールは、XML語彙がサポートされている場合には、常にサポートされていると考えられることに注意してください。これは、明確化のためにも、今後の仕様の改訂で(例えば、OPSでは現在非推奨のスタイル属性XHTMLモジュールなどの)いくつかのモジュールが任意(optional)になる可能性がある場合にも有用です。

非優先語彙のアウト・オブ・ラインXMLアイランドを指定するアイテムへのrequired-modules属性の付与は ― 明確化のため、または、非優先語彙から必要な拡張モジュールを指定するために ― 認められており、それが有用な場合があります。

最も重要なことに、アウト・オブ・ラインXMLアイランドで用いられる非優先語彙(または、Extended Modules)をネイティブに処理できる読書システムは、その総体的な認識能力を用いてドキュメントをネイティブに処理することを選択できます(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をネイティブに表示するのか、css1のスタイリングのみを用いてitem2を表示するのか、item2.5をネイティブに表示するのか(ルビとサーバ・サイド・イメージ・マップXHTML拡張モジュールが読書システムによってサポートされていると仮定して)、item3をネイティブに表示するのかを選択できます。読書システムは、item4を処理する際には、item4をネイティブに表示すること、css1のスタイリングのみを用いてitem4を表示することを選択できます。

拡張モジュールを用いない場合は、優先語彙で記述されているXMLドキュメントを参照するitem要素に、required-namespace属性を包含することは必須ではありません(not required)。拡張モジュールを用いる場合には、required-namespaceとrequired-modules属性の両方を提供しなければなりません(must)。

2.4: スパイン

manifestの後には、spine素が1つだけなければならず(must)、これには1つ以上のitemref要素が含まれます。個々のitemrefは、manifestで指定されているOPSコンテンツ・ドキュメントを参照します。itemref要素の順序は、出版物で読まれる順序で関連するOPSコンテンツ・ドキュメントを編成します。

spineの個々のitemrefは、OPSコンテンツ・ドキュメント(または、OPSコンテンツ・ドキュメントを含んでいるフォールバック・チェーンを持つドキュメント)以外のメディア・タイプを参照してはなりません(must not)。OPSコンテンツ・ドキュメントは、application/xhtml+xml、application/x-dtbook+xml、非推奨のtext/x-oeb1-document、および(必須の(required)fallbackを持つ)アウト・オブ・ラインXMLアイランドのメディア・タイプのうちの1つでなければなりません(must)。このリストに含まれていないメディア・タイプを持つドキュメント(または、このリストに含まれているメディア・タイプを持つドキュメントを含んでいないフォールバック・チェーンを持つドキュメント)がspineで参照されている場合は、読書システムは、それをspineの一部として含んではなりません(must not)。

spineに記述されているアイテムは、OPSコンテンツ・ドキュメントか、OPSコンテンツを含んでいるフォールバック・チェーンを持つアイテムかのどちらかでなければならないため、別のOPSコア・メディア・タイプに「辿り着く」spineアイテムに対するフォールバック・チェーンを持つことは可能です。例えば、spine itemrefは、PDFドキュメントを参照することができ、それがPNG画像に、そしてOPS XHTMLコンテンツ・ドキュメントにと順にフォールバックします。このフォールバック・チェーンには、OPSコンテンツ・ドキュメントが含まれている(この場合は、OPSコンテンツ・ドキュメントで終了する)ため、このアイテムがspineに出現することは妥当です。

さらに、特定のspineアイテムは(manifestにおける自身のid属性値の観点から)、spineに2回以上出現してはなりません。

spineには、この仕様で認められている参照メカニズムよって潜在的に到達可能な出版物の一部である(すなわち、マニフェストに記述されている)すべてのOPSコンテンツ・ドキュメントを含まなければなりません(must)。このような参照メカニズムは、OPSコンテンツ・ドキュメント内のハイパーテキスト・リンクとNCXやツアーやガイドによる参照を、部分的なリストとして含みます。

このような参照により、読書システムが、この仕様で求められているようなspineで記述されていないOPSコンテンツ・ドキュメントに遭遇した場合には、それをspineに追加し(読書システムの裁量により置く)、noにlinear属性の値を割り当てるべき(should)です(次を参照)。

出版物の著者は、itemrefごとに、関連するOPSコンテンツ・ドキュメントがプライマリ(linear="yes"で、これはlinearがない場合のデフォルト)なのか、補助的(linear="no")なのかを指定するために、任意のlinear属性を指定できます(may)。出版物の著者が、補助的と宣言されているOPSコンテンツ・ドキュメントに対し、ハイパーテキスト・リンクのような、ある種の内部参照が含まれていることが重要です。すべての補助的なコンテンツには、NCXへの参照を追加することを推奨します(recommended)。spine内のitemrefの少なくとも1つがプライマリであると宣言しなければなりません(must)。

OPSコンテンツ・ドキュメントがプライマリか補助的かの指定は、補助的なコンテンツをプライマリなコンテンツとは異なる形で表示することを選択する読書システムにとって有用です。例えば、読書システムは、プライマリなコンテンツを表示するメイン・ウィンドウとは別に、補助的なコンテンツをポップアップ・ウィンドウで表示することを選択するかもしれません。(補助的と見なされるコンテンツの種類に関しては、下記の例とその後の議論を参照してください。)

読書システムが、プライマリなコンテンツと補助的なコンテンツを区別することは必須ではなく(not required)、この項で示している要件と推奨では、linear属性の値にかかわらず、spineのすべてのOPSコンテンツ・ドキュメントがプライマリであると見なすことができます(may)。

linear属性は、OEBPS 1.xとの互換性も維持しており、この場合は、すべての到達可能なOEBPSがspineに記述されている必要はありません。OEBPS出版物をOPSにアップグレードするためには、OEBPS 1.xの出版物の、リストに記述されていない、到達可能なコンテンツ・ドキュメントのすべてを、linear="no"に割り当てるべき(should)です。

読書システムは、読書中に、spine内の順序付きitemref情報を用いて出版物を表示します。読書システムは、spine内の最初のプライマリOPSコンテンツ・ドキュメントが出版物の主な読み順の起点であると認識しなければなりません(must)。次に続くプライマリOPSコンテンツ・ドキュメントは、spineで記述されている順序に従って、残りの主な読み順を形成します。読書システムは、spine内の、あるプライマリOPSコンテンツ・ドキュメントから次のプライマリOPSコンテンツ・ドキュメントに移動する際に、「次ページ」というスタイル機能を使用できます(may)。

spine要素には、toc属性を含まなければならず(must)、その値は、manifestで宣言されている必須の(required)NCXドキュメントのid属性値です(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つは「回答キー」で、4つ目はある種の注記です。4つともすべてが、本の主要な流れにおいて補助的なもので、主要な流れとは別に見ることができます。

プライマリなコンテンツと補助的なコンテンツを別々に認識・表示できる読書システムは、主要な読み順がintro、c1、c2、c3という4つのプライマリなOPSコンテンツ・ドキュメントになるように設定するでしょう。このような読書システムでは、補助的なコンテンツ・ドキュメントは、起動時に(ハイパーテキスト・リンクやNCXのエントリーなどにより)、主要な読み順とは異なる何らかの方法で表示されるでしょう。出版物の著者が補助的なコンテンツ・ドキュメントに必要な参照を提供することが重要で、それがなければ、補助を意識した(auxiliary-aware)一部の読書システムは、このコンテンツに到達できないかもしれません。

linear="no"を無視し、すべてのitemrefをプライマリに設定することを選択した読書システムは、この仕様で認められているとおり、8つのすべてのOPSコンテンツ・ドキュメントを、与えられている順序で、主要な読み順に割り当るでしょう。これは、プリントアウト機能を提供する読書システムに特に有用で、この場合には、著者が決定した順序でOPSコンテンツ・ドキュメントのすべての情報が印刷されることが重要です。

読書システムは、その裁量により、両方の表示オプションをユーザに提供できます(may)。

2.4.1: 宣言型目次 ― NCX

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

この仕様では、DAISY/NISO標準、正式名称ANSI/NISO Z39.86-2005、デジタル録音図書の仕様で定義されているNCXを使用しています。NCXは、この包括的なマルチメディア標準の一部(第8項)です。DAISYコンソーシアムは、NCX DTDを管理しています。OPFで使用するために、DTDを変更する必要はありません。DAISY/NISO諮問委員会は、NCXのモジュール化や、電子書籍、マルチメディア出版物、その他の電子ドキュメントに、より沿った用語に変更することを将来的に検討するでしょう。

この仕様では、NCXを実装するために、一部の任意の(optional)要素とメタデータの項目は必要ありません。下の項では、NCXに関するDAISY/NISO標準を転載するのではなく、規範的に参照することにしました。「例外」はすべて、下記の2.4.2項で記述しています。

2.4.1.1: 序論

Navigation Control file for XMLのアプリケーション(NCX)は、出版物の階層構造を示して、ユーザがナビゲートできるようにします。NCXは、読者が直接ドキュメントの主要な構造要素のいずれか、つまり、部、章、項にジャンプできるようにするという点では目次と同じですが、出版者が元の印刷物の目次に含めることを選択する要素よりも多いドキュメントの要素を含むことが多いでしょう。これは、PCユーザに親しまれている折りたたみ式ツリーとして表示できます。ドキュメント全体を分析せずにドキュメントの主要な構造要素に迅速なアクセスを提供する必要性が開発の動機となりました。ページ、脚注、数字、表などのその他の要素を、独立した非階層的なリストに含むことができ、ユーザがそれにアクセスすることも可能です。

これらのナビゲーション機能は、それを実施したいユーザの利便性向上を目的としたものであり、負担になることを意図してはいないことを強調することが重要です。NCXのナビゲーション機能を必要としないユーザには、本の代替となるguideを提供することができます。

2.4.1.2: 重要なNCX要件

読書システムは、NCXをサポートしなければなりません(must)。

OPS出版物には、NCXを含まなければなりません(must)。

他の出版物の構成要素と同じく、NCXは、manifest内のitemとして(application/x-dtbncx+xmlのmedia-typeを持つ)含まれなければなりません(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標準の8項で定義されているNCXは、OPSアプリケーションにとって理想的ですが、ここでは、いくつかの例外について述べます。標準では、NCXから出版物へのリンクは、SMIL(http://www.w3.org/TR/2005/REC-SMIL2-20050107/)ドキュメントを指します。OPS出版物では、このリンクは情報源であるOPSコンテンツ・ドキュメントのXML要素を指すでしょう。この違いにより、この標準の8項と比べて、以下の注意すべき例外が生じます。

NCXのOPFアプリケーションでは、smilCustomTestは使用しません。
NCXのOPSアプリケーションでは、audioは使用しません。
clipBegin(%SMILtimeVal、REQUIRED)は、音声セグメントの開始位置を識別するために使用され、したがって、NCXのOPFアプリケーションでは使用されません。
clipEnd(%SMILtimeVal、REQUIRED)は、音声セグメント終了位置を識別するために使用され、したがって、NCXのOPFアプリケーションでは使用されません。
contentの記述は、navPointやnavTargetが参照するアイテムのSMILファイル内の開始位置を指します。注意: NCXのOPFアプリケーションでは、ポインタは、SMILの位置ではなく、XML要素を指します。
OPS出版物はマルチメディア・ファイルよりもかなり小さいため、DTBs Spanning Multiple Media Units(複数のメディアにまたがるDTB)は、出版物のコンテキストには関係ありません。
例では、SMILファイルへのリンクを示していますが、NCXのOPFアプリケーションでは、リンクはXML要素に対するものになるでしょう。また、例では、audioがclipBeginとclipEndを参照していますが、これは、NCXのOPFアプリケーションでは使用されません。
コンテンツが「紙のページ」を用いた表現に関連していない場合には、「dtb:totalPageCount」と「dtb:maxPageNumber」という必須のNCXメタデータのアイテムは無関係でありえます。この場合、これらの値にゼロを指定でき(may)、読書システムはこれらを無視できます(may)。
playOrder属性は、必須のままです。playOrder属性は、SMILコンテンツを配列するためには用いませんが、ドキュメントの読み順を反映した有効な値を含むべき(should)です。例えば、これは、 navMapに対応した位置を見つけるためにpageListをナビゲートする際に使用できます。

2.4.3: スパインのXMLアイランド

XMLアイランドは、スパインから参照できます(may)。読書システムがXMLアイランドを正しく表示できない場合には、オープン・パブリケーション・ストラクチャで定義されている標準のフォールバック手順を使用しなければなりません(must)。

つまり、アイランド自身を表示できない場合には、読書システムは、XMLアイランドが選択したfallbackを表示しなければなりません(must)。

2.5: ツアー[非推奨]

観光ガイドが面白い場所を組み合わせて観光ツアーを作るのと同じように、コンテンツ提供者は、出版物のパーツを選択し組み合わせてツアーにすることで、利便性の高いナビゲーションを実現できます。

OPS -->OPF?パッケージ・ドキュメントは、1つ以上のtour要素を順番に含んだ1つのtours要素を含むことができます(may)が、必須ではありません。個々のtourには、ユーザに表示するためのtitle属性がなければなりません(must)。読書システムは、様々な読書目的や読者の知識レベルなどに対応した選択ビューなどの、出版物のパーツに対する様々なアクセス順序を提供するために、toursを使用できます(may)。読書システムがツアーのサポートを実装することは必須ではない(not required)ため、コンテンツの提供者は、toursが参照するコンテンツにアクセスする他の手段も提供すべき(should)です。

個々のtour要素には、1つ以上のsite要素を含まれており、それぞれにhref属性とtitle属性がなければなりません(must)。href属性は、manifestに含まれているOPSコンテンツ・ドキュメントを参照しなければならず(must)、RFC 2396の4.1項で定義されているように、フラグメント識別子を含むことができます(may)(http://www.ietf.org/rfc/rfc2396.txtを参照)。個々のsite要素には、読者が自由に探検できる起点を指定します。読書システムは、参照されている要素の境界を利用してサイトの範囲を決定できます(may)。フラグメント識別子が用いられていなければ、ドキュメント全体が範囲であると見なされます。この仕様では、読書システムが、参照されている要素の範囲全体を記述したり、識別することは必須ではありません(not required)。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: ガイド

パッケージは、1つ以上のreference要素を含んだ1つの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)。

個々の参照には、manifestに記述されたOPSコンテンツ・ドキュメントを参照するhref属性がなければならず(must)(http://www.ietf.org/rfc/rfc2396.txtを参照)、RFC 2396の4.1項で定義されているフラグメント識別子を含むことができます(may)。読書システムは、参照の範囲を決定するために、参照されている要素の境界を使用できます(may)。フラグメント識別子が使用されていなければ、ドキュメント全体が範囲であると見なされます。この仕様では、読書システムが、参照されている要素の範囲全体を記述したり、識別することは必須ではありません(not require)。

必須の(required)type属性は、href属性が参照する出版物の構成要素を記述します。type属性の値は、下記で定義しているリストが適用できる場合には、それから選択しなければなりません(must)。この事前に定義済みのtypeがどれも適用できない場合には、他のタイプを使用できます(may)。その名前は、otherという文字列で始めなければなりません(must)。type属性の値は大文字と小文字を区別します。

下記のtype値のリストは、Chicago Manual of Styleの第13版を基にしたものです。

cover	本のカバー、ジャケットの情報など
title-page	タイトル、作者、出版者、および他のメタデータでありえるページ
toc	目次
index	巻末索引
glossary
acknowledgements
bibliography
colophon
copyright-page
dedication
epigraph
foreword
loi	図版一覧
lot	表一覧
notes
preface
text	コンテンツの「実質的な」最初のページ(例えば「第1章」)