この仕様書はOEBPS Container Format (OCF)を定義するものである。OCFは汎用のコンテナ技術である。この仕様書ではOEBPS出版物の場合、および付加的に(OPTIONAL)他の表示形式を持つ場合のカプセル化における汎用コンテナ技術について示す。しかしながら、本稿で示される汎用コンテナ技術は最終的に他のバンドルアプリケーションにおいても利用されると予想される。
OCFは、汎用コンテナ形式として、関連する一連のファイルを一つのファイルであるコンテナに集約する。様々なドキュメント形式やアプリケーションクラスのファイルを集約するためにOCFを利用することが可能である。一つのファイルとすることで、一連のファイルの受け渡しや管理、およびアクセスが容易となる。
OCFはZIPアーカイブ中の物理的なファイル構成(物理コンテナ)と抽象的なファイルのコレクション(抽象コンテナ)とを対応付けるためのルールを定義する。ZIPコンテナのルールはOpen Document Format (ODF) 1.0におけるZIP技術に基づいており、互換性を有している。
OCFはOEBPS出版物に対して推奨される(RECOMMENDED)単一ファイルコンテナ技術である。出版の一連の流れにおいて、OCFは次のように利用され得る(MAY)。
- 電子出版物の作成段階において、関係する作者および／もしくは組織間で作成中の出版物のやりとりに単一ファイル形式のOCFが利用される。
- 出版社あるいはコンテンツプロバイダから配布元や販売元への電子出版物の提供形式としてOCFが推奨される(RECOMMENDED)単一ファイル形式となる。
- 完成した出版物をOCFリーディングシステムやエンドユーザに提供する際、出版物に使われる各種要素を単一ファイルのコンテナ内にまとめるOCFが推奨(RECOMMENDED)形式となる。
ASCII
American Standard Code for Information Interchange。英文アルファベットを7bitで符号化したもの(ANSI X3.4-1986)。本稿において、ASCIIは印字可能文字である33(10進)から126(10進)の範囲、およびスペース文字32(10進)を指す。
OCFコンテナ [OCF CONTAINER]
本仕様書にて定義する形式に従うコンテナファイル。
OCF
本仕様書にて定義されるOEBPS Container Format。
コンテンツプロバイダ [CONTENT PROVIDER]
出版社、著者、個人およびその他情報の供給者で、本仕様書にて示されたOCFを利用して出版物を配布元、販売元、あるいは直接一つ以上のOCFリーディングシステムに提供する者を指す。
ODF
Open Document Format (http://www.oasis-open.org/committees/download.php/12572/OpenDocument-v1.0-os.pdf)。
OEBPS
Open eBook Publication Structure (http://www.idpf.org/oebps/oebps1.2/index.htm)。
OEBPSドキュメント [OEBPS DOCUMENT]
OEBPS 1.2の仕様に従うXMLマークアップドキュメント。一般的にはOEBPS出版物のテキストコンテンツを含む。
OEBPSパッケージ [OEBPS PACKAGE]
OEBPS 1.2の仕様に定義された形式でOEBPS出版物について記述したXMLファイル。出版物のすべてのファイルを識別し、説明情報を提供する。
OEBPS出版物 [OEBPS PUBLICATION]
OEBPS 1.2の仕様に定義された、OEBPSドキュメント、OEBPSパッケージファイル、構造化されたテキストと図を含む様々なメディアタイプのファイルの集合体の内、出版物の不可分な構成単位となるものを指す。
OCFリーディングシステム [OCF READING SYSTEM]
(OCFコンテナにパッケージ化された)OEBPS出版物を受け取り、コンテンツの消費者が利用できるようにするための、ハードウェアおよび／またはソフトウェアの組み合わせを指す。OCFリーディングシステムは多様なアーキテクチャを持つことができる。OCFリーディングシステムは完全に一つのデバイスとして実装してもよい(MAY)し、また複数のコンピュータ間に分割して実装してもよい(MAY)。全てのOCFリーディングシステムはOEBPS出版物を受け取らなければならない(MUST)が、OEBPS出版物を直接受け取るのが特にOCFリーディングシステムのひとつのコンポーネントであるリーディングデバイスである必要はない(need not)。リーディングシステムは、圧縮、インデックス化、暗号化、権利管理、配信などの付加的な処理機能を持ってもよい(MAY)。
MIME
RFC
字義では「Request For Comments」の意であるが、一般的にはInternet Engineering Task Force (IETF)により出版されたドキュメントを指す。 http://www.ietf.org/rfc.html 参照。
RELAX NG
XMLのスキーマ言語 (http://www.relaxng.org/)。
ルートファイル [ROOTFILE]
出版物を表示する際にトップレベルに来るファイルを指す。他のすべての要素を参照する「ルート」ファイル、もしくは表示自体をカプセル化したファイル。OEBPSのルートファイルはOEBPSパッケージファイルである。PDFの表示を含むPDFファイルもルートファイルと成り得る。
XML
ZIP
業界のデファクトスタンダードであるバンドルおよび圧縮形式 (http://www.pkware.com/business_and_developers/developer/appnote)。
本仕様では他の仕様のサブセットおよびアプリケーションが組み合わされている。これらは互いに、電子文書の構築、編成、表示および明確な変換を容易にしている。
- The XML 1.1 Extensible Markup Language specification (http://www.w3.org/TR/xml11/)
- The OEBPS 1.2 Open eBook Publication Structure specification (http://www.idpf.org/oebps/oebps1.2/index.htm)
- The XML 1.1 namespace specification (http://www.w3.org/TR/xml-names11/)
- The Unicode Standard, Version 4.0. Reading, Mass.: Addison-Wesley, 2003, 新たなバージョンの発表によって時折アップデートされる (標準規格とUnicode Character Databaseに関する最新バージョンと他のバージョンの追加情報については http://www.unicode.org/unicode/standard/versions を参照)。
- Particular MIME media types (http://www.ietf.org/rfc/rfc4288.txt および http://www.iana.org/assignments/media-types/index.html)
- Open Document Format for Office Applications (Open Document) v1.0 (http://www.oasis-open.org/committees/download.php/12572/OpenDocument-v1.0-os.pdf)
- ZIP format (http://www.pkware.com/business_and_developers/developer/appnote)
- XML-Signature Syntax and Processing (http://www.w3.org/TR/2002/REC-xmldsig-core-20020212)
- XML Encryption Syntax and Processing (http://www.w3.org/TR/2002/REC-xmlenc-core-20021210)
- Web Content Accessibility Guidelines 1.0 (http://www.w3.org/TR/WCAG10/)
このセクションではOCFの適合性について定義する。
用語「適合OCF抽象コンテナ」(Conforming OCF Abstract Container)は、本仕様書にて定義されるすべての適合基準を満たすOCF抽象コンテナ(セクション2.2参照)を表す。用語「適合OCF ZIPコンテナ」(Conforming OCF ZIP Container)は、コンテンツが適合OCF抽象コンテナから成り、関連するZIPコンテナの適合基準(セクション4参照)を満たすZIPアーカイブを表す。
この仕様書に定義された他の適合基準に加え、適合OCF抽象コンテナは以下の条件を満たさなければならない(MUST)。
用語「適合OCFリーディングシステム」(Conforming OCF Reading System)は、本仕様書により定義された必要な機能をすべてサポートしたOCFリーディングシステムを表す。
OCFリーディングシステムが本仕様書で定義された機能をすべてサポートしない場合、そのOCFリーディングシステムは適合性を主張してはならない(MUST NOT)。また、そのOCFリーディングシステムがサポートしている機能を容易に判別できるドキュメントを提供すべきである(SHOULD)。
OCFリーディングシステムはサポートしているアクセシビリティ機能を容易に判別できるドキュメントを提供すべきである(SHOULD)。このドキュメントはW3C Web Content Accessibility Guidelines (セクション1.5参照)の適切なバージョンを満たすべきである(SHOULD)。
電子書籍は、著者および出版社がその制作時にアクセシビリティを考慮し業界標準に従うことで、障害のあるユーザでも読書を
可能にし得る(MAY)。OCFを利用してパッケージ化／配布されるOEBPSは、この形式で配布される書籍を可能な限り多くのユーザが利用できることを保証するため、先にOEBPSワーキンググループにより制定されたaccessibility standards set
(http://www.idpf.org/idpf_groups/oebpswg.htm) に従うべきである(SHOULD)。これにはW3C Web Content Accessibility Guidelines 1.0 (http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/) を順守すること、また正式版がリリースされた場合にはWeb Content Accessibility Guidelines 2.0を順守すること (ドラフトは http://www.w3.org/TR/WCAG20/ にて入手できる)が項目として含まれる。OCFを利用してパッケージ化／配布されるOEBPS出版物は、コンテンツの表示のされ方に関わらず、コンテンツのアクセシビリティを確保するためのいかなる機能も妨げてはならない(MUST NOT) (例えば、特定のOCFリーディングシステムにのみ対応した形式や、コンテナ内のOEBPS自体を配布形式としてはならない)。本仕様の後続バージョンはリリース1.0にて定められた方向性の延長線上に位置するものになると考えられる。具体的には以下の項目が期待される。
- OASIS/ODFとの連携の改善。
- OEBPS仕様の後続バージョンへの対応。
- 関連する公式規格にない必須機能に関して、妥当な規格化団体の最終案と一致する形で、既存の規格の拡張として定義される。
OCF仕様の後続バージョンは以下の項目を含む可能性がある(MAY)。
- コンテナレベルのメタ情報の記述のために特定のXMLボキャブラリを借用し META-INF/metadata.xml 中で利用する。
- 特定のXMLボキャブラリを借用し META-INF/rights.xml 中で利用する。
- OEBPS仕様の後続バージョンへの対応を維持するためアップデートを必須とする。
OCFは、OEBPSに限らず他のファイル形式においても利用できるよう設計された汎用的なコンテナ技術である。特に、OCFはODFの後続バージョンがOCFを利用できるよう、ODF 1.0で利用されるコンテナ技術に対して上位互換となるように設計されている。
「抽象コンテナ」はコンテナのコンテンツのためにファイルシステムのモデルを定義するものである。ルートディレクトリがひとつだけ存在し、コンテナのすべてのコンテンツがその中に存在しなければならない(MUST)。OCFに必須の(REQUIRED)特定のファイルについては、ルートディレクトリ直下の META-INF ディレクトリに存在しなければならない(MUST)。出版物で利用されるすべての電子データはコンテナのルートディレクトリから始まるディレクトリツリーの中に属していなければならない(MUST)。
「物理コンテナ」は抽象コンテナの物理的な構造を示すものである。本仕様書では、ファイルシステムコンテナおよびZIPコンテナの二つの物理コンテナ技術に対し、どう抽象コンテナを対応付けなければならない(MUST)かを定義している。
- ファイルシステムコンテナ - 抽象コンテナを特定のプラットフォームの記憶媒体(例えばコンピュータのハードディスクやデータCD)中のファイルシステムと対応付ける場合、抽象コンテナ中の各ディレクトリやファイルがそれぞれファイルシステム中の各ディレクトリやファイルに対応する、一対一対応でなければならない(MUST)。現在一般に用いられるファイルシステムにて保存を容易にするため、ファイル名に関する制限がセクション3.3において定義される。
- ZIPコンテナ - ZIPアーカイブへの抽象コンテナの対応付けについてはセクション4で定義する。
出版物は、ファイルシステムコンテナ、ZIPコンテナのいずれを使用した場合でも同じように表示されなければならない(MUST)。どちらの場合であっても、OCFリーディングシステムは出版物の表示形式を決定するためルートファイルを開く。
(このセクションは参考情報。)
このセクションでは単一の表示形式のみのコンテナ、および複数の表示形式を持つコンテナの例を示す。厳密な説明に関してはセクション3.5.1を参照の事。
前セクションのおさらいとして、OEBPS 1.2形式のDickensの電子書籍「大いなる遺産」 ("Great Expectations") の場合を考える。この電子書籍はOEBPS 1.2パッケージファイル ("Great Expectations.opf") と、カバーページのHTMLファイル (例えば"cover.html")、各章のHTMLファイル (例えば"chapter01.html") から構成されているとする。このとき、出版物のコンテンツは次のようになる。
OEBPS 1.2出版物:
Great Expectations.opf
cover.html
chapters/
chapter01.html
chapter02.html
... 各章のHTMLファイル ...
抽象コンテナのコンテンツは、これら出版物のすべてのデータと、OCFで定義されている META-INF ディレクトリおよびその中に入ったいくつかのファイルとなる。container.xml は必ず必要となることに注意して欲しい。 META-INF ディレクトリ内の各ファイルの詳細についてはセクション3を参照のこと。
抽象コンテナ:
META-INF/
container.xml
[manifest.xml]
[metadata.xml]
[signatures.xml]
[encryption.xml]
[rights.xml]
OEBPS/
Great Expectations.opf
cover.html
chapters/
chapter01.html
chapter02.html
... 各章のHTMLファイル ...
上記の抽象コンテナをファイルシステムコンテナと対応付ける場合、ファイルシステム内のディレクトリ構造は上のOCF抽象コンテナのディレクトリ構造と完全に対応する。
ファイルシステムコンテナ:
...ファイルシステム内のディレクトリ.../
META-INF/
container.xml
[manifest.xml]
[metadata.xml]
[signatures.xml]
[encryption.xml]
[rights.xml]
OEBPS/
Great Expectations.opf
cover.html
chapters/
chapter01.html
chapter02.html
... 各章のHTMLファイル ...
上記の抽象コンテナをZIPコンテナに格納する場合は、ZIPアーカイブのコンテンツ自体は上のディレクトリ構造と対応するが、それに加えてコンテナのメディアタイプを判別しやすくするため、ZIPアーカイブの最初のファイルとして"mimetype"を含まなければならない(MUST) (セクション3.4参照)。
ZIPコンテナ:
mimetype
META-INF/
container.xml
[manifest.xml]
[metadata.xml]
[signatures.xml]
[encryption.xml]
[rights.xml]
OEBPS/
Great Expectations.opf
cover.html
chapters/
chapter01.html
chapter02.html
... 各章のHTMLファイル ...
このときの META-INF/container.xml の内容は次のようになる。
<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
<rootfiles>
<rootfile full-path="OEBPS/Great Expectations.opf"
media-type="application/oebps-package+xml" />
</rootfiles>
</container> 注意: 名前空間の値 "urn:oasis:names:tc:opendocument:xmlns:container" については、OASIS技術委員会の承認が降りるまでは暫定的なものである。 場合によっては、OCFコンテナが同じ出版物ではあるが異なる表示形式を持つことがある。例えば、閲覧にはOEBPS出版物を使う一方、印刷用にPDFを持つようなコンテナが考えられる。名前の衝突を防ぐため、各表示形式はそれぞれ個別のサブディレクトリに格納し、container.xmlでは複数の <rootfile> を定義することが推奨されている(REOCMMENDED)。
抽象コンテナ:
META-INF/
container.xml – 注: 複数の <rootfile> 要素を持つ
[manifest.xml]
[metadata.xml]
[signatures.xml]
[encryption.xml]
[rights.xml]
OEBPS/
Great Expectations.opf
cover.html
chapters/
chapter01.html
chapter02.html
... 各章のHTMLファイル ...
PDF/
Great Expectations.pdf
このときの META-INF/container.xml の内容は次のようになる。
<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
<rootfiles>
<rootfile full-path="OEBPS/Great Expectations.opf"
media-type="application/oebps-package+xml" />
<rootfile full-path="PDF/Great Expectations.pdf"
media-type="application/pdf" />
</rootfiles>
</container>
OCF「抽象コンテナ」の仮想的なファイルシステムでは、そのコンテナ内のすべてのコンテンツを含むルートディレクトリがひとつだけ存在しなければならない(MUST)。
ルートディレクトリ内の以下のファイル名は予約されている。
"mimetype"ファイルについてはセクション4で扱う。 META-INF/ ディレクトリ以下にはOCFで利用される予約ファイルが含まれる。抽象コンテナに含まれる"mimetype"はルートレベルもしくは META-INF/ ディレクトリ内に存在する必要があるが、その他の出版物に利用されるすべてのファイルはルートディレクトリ以下の任意の場所に存在してもよい(MAY)。
複数の表現方法が利用されるような場合、あるいは本仕様書の後続バージョンにおいて複数の出版物を含んだコンテナがサポートされた場合に名前の衝突が発生する可能性を小さくするため、個々の出版物はそれぞれ専用のサブディレクトリ以下に格納することが推奨される(RECOMMENDED)。
<img src="image1.jpg" alt="…" …/>
相対IRI参照について、ベースIRI (RFC 3986参照)は与えられたファイル形式についての適当な言語仕様によって決定される。例えば、CSSスタイルシートとプロパティ宣言における相対IRI参照の働きはCSS仕様によって定義される。対象の言語仕様がRFC 3987以降のRFCを参照している場合、その言語のコンテンツに対しては先のRFCが適用される。
多くの言語仕様の場合とは異なり、 META-INF/ ディレクトリ内の各ファイルのベースIRIは、デフォルトでは抽象コンテナのルートフォルダとなる。例えば、 META-INF/container.xml が以下のような内容であった場合、"OEBPS/Great Expectations.opf"は META-INF/ ディレクトリではなく抽象コンテナのルートディレクトリからの相対パスとなる。
<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
<rootfiles>
<rootfile full-path="OEBPS/Great Expectations.opf"
media-type="application/oebps-package+xml" />
</rootfiles>
</container>
「ファイル名」は、抽象コンテナ内のディレクトリもしくはディレクトリ内のファイルのいずれかの名前を示すものである。抽象コンテナ内のあるディレクトリに対し、「パス名」はフルパスに含まれるすべてのディレクトリ名を "/" でつないだ文字列となる。抽象コンテナ内のあるファイルに対する「パス名」は、すべてのディレクトリ名を "/" でつなぎ、更に "/" に続いてファイル名をつなげた文字列である。下記に示した「ファイル名」の制限は、現在一般的に用いられるオペレーティングシステムにおいて、ディレクトリ名およびファイル名を修正することなく利用できることを考慮している。本仕様書では、OCF準拠のファイル名を表すことができないOCFリーディングシステムにおいて、どのようにその非互換性を扱うかについては示さない。
「Conforming OCF Content」(適合OCFコンテンツ)は次の要求を満たす。
- ファイル名は以下に示す制限内でUTF-8にエンコードされていなければならない(MUST)
- UTF-8で表したとき、ファイル名は255 byteを超えてはならない(MUST NOT)
- UTF-8で表したとき、抽象コンテナ内のすべてのディレクトリおよびファイルのパス名は65535 byteを超えてはならない(MUST NOT)
- ファイル名には以下の文字を使用してはならない(MUST NOT) (一般的なOSでサポートされるとは限らないため)
- スラッシュ: / (ASCII 0x2F)
- ダブルクォーテーション: " (ASCII 0x22)
- アスタリスク: * (ASCII 0x2A)
- 最後の文字としてのピリオド: . (ASCII 0x3A)
- コロン : : (ASCII 0x3A)
- 小なり: < (ASCII 0x3C)
- 大なり: > (ASCII 0x3E)
- クエスチョンマーク: ? (ASCII 0x3F)
- バックスラッシュ : \ (ASCII 0x5C)
- ファイル名は大文字・小文字を区別する。
- 同一ディレクトリ内の二つのファイル名が、大文字・小文字の正規化 (http://www.unicode.org/reports/tr21/tr21-5.html) の結果同じ文字列にマップされてはならない(MUST NOT)。同じディレクトリ内の、大文字・小文字のみが異なるファイル名は許可されない。
- 同一ディレクトリ内の二つのファイル名が、アクセントの正規化の結果同じ文字列にマップされてもよい(MAY)。
ZIPツールの中には、ファイル名としてUnicodeの範囲をすべてサポートしていないもの、あるいはASCIIのみサポートしているものがあることに注意が必要である。そのような制限のあるZIPツールを利用する場合は、ファイル名をASCIIの範囲に限定してしまうことがベストかも知れない(MAY)。伸長時にファイルの名前が保持できない場合、コンテンツ内でURIによってそれらのファイルが参照されている際は名前を置き換える必要があり得る。
3.4 コンテナメディアタイプの判別
アプリケーションがファイルのメディアタイプを判別する必要がある、というケースは少なくない。通常はファイルの拡張子で判断する。アプリケーションはファイルの内部を調べること無く簡単にファイルの形式を判断できる。OCFコンテナファイルは、アプリケーションがOCFコンテナであることを判断できるように、拡張子".epub"を使用するべきである(SHOULD)。
ファイルの拡張子からメディアタイプを判別するために、一般的にそのファイルを処理するエージェントはオペレーティングシステムにファイル拡張子とメディアタイプとの関係を登録する。OCFコンテナファイルを対象とするアプリケーションは、メディアタイプ"application/epub+zip"と、対応する拡張子".epub"を登録すべきである(SHOULD)。
しかしながら実際は、ファイル拡張子による判別は全く信用できない。ゆえに、ファイル名や拡張子によらずそのファイルを判断するより強固な方法が必要となる。そのために発展した一つの手法が、ファイルの特定のオフセットに特定の情報を埋め込む決まりとする、というやり方である。ファイルを処理するエージェントは特定の位置をチェックし、ファイルがOCFコンテナであるかを判断できる。
ZIPアーカイブでこの手法を実現するには、ZIPアーカイブの最初ファイルに"mimetype"という無圧縮・非暗号化ファイルを配置する。ファイルのコンテンツはその("mimetype")ファイルのメディアタイプとなる。OCFコンテナは、ZIPアーカイブの最初のファイルとして、ASCII文字列で"application/epub+zip"と記述した"mimetype"ファイルを配置しなければならない(MUST)。この手法に関する詳細はセクション4を参照のこと。
すべての有効なOCFコンテナは、コンテナファイルシステムのルートレベルに"META-INF"というディレクトリを持たなければならない(MUST)。このディレクトリには、下記に示す、出版物に関するコンテンツ、メタ情報、デジタル署名、暗号化、著作権管理およびその他の情報を記述したファイルが含まれる。
下記に示す、"META-INF/"階層に存在する可能性のある(MAY)ファイルのセマンティック(意味)は指定されている。適合OCFリーディングシステムでは、"META-INF/"階層のその他のファイルは無視されなければならない(MUST)。
(以下、規定。)
すべての有効なOCFコンテナは、コンテナファイルシステムのルートレベルにある"META_INF"内に"container.xml"というファイルを持たなければならない(MUST)。container.xml ファイルは、出版物のOEBPS形式のルートファイル、および付加的に(OPTIONAL)コンテナに含まれる表示形式のMIMEタイプおよびパスを判別しなければならない(MUST)。
container.xmlファイルは暗号化されてはならない(MUST NOT)。
container.xmlファイルはXMLであり、その要素および属性に "
urn:oasis:names:tc:opendocument:xmlns:container" という名前空間を利用している。このバージョンに準拠するすべてのコンテナは"version="1.0""という属性を含まなければならない(MUST)。container.xmlのルート要素とならなければならない(MUST) <container> 要素を記述するRELAX NG OCFスキーマについては附録Aを参照のこと。
<rootfiles> 要素は、"application/oebps-package+xml"というメディアタイプを持つ <rootfile> 要素を少なくとも一つ含まなければならない(MUST)。メディアタイプが"application/oebps-package+xml"である <rootfile> 要素は一つとするべきである(SHOULD)。メディアタイプが"application/oebps-package+xml"の最初の <rootfile> 要素により参照されるファイルがOEBPSのルートファイルと見なされる。OEBPSのルートファイル(OEBPSパッケージファイル)は暗号化されてはならない(MUST NOT)。
各 <rootfile> 要素にて、含まれる出版物の各表示形式のルートファイルを指定する。多くの場合、ルートファイルは表示に必要なファイルの一覧を含む。OEBPSの場合であれば、ルートファイルはOEBPSパッケージファイルとなるが、そのファイルの <manifest> 要素はOEBPSの表示に使われるファイルの一覧となる。逆に、ルートファイルがただ一つのファイルとなる場合もあり得る(MAY)。
(例: 参考情報。)
次の例は、OEBPS出版物を含むOCFコンテナの場合の container.xml のサンプルである。ルートファイル(OEBPSパッケージファイル)は"OEBPS/My Crazy Life.opf"とする。
<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
<rootfiles>
<rootfile full-path="OEBPS/My Crazy Life.opf"
media-type="application/oebps-package+xml" />
</rootfiles>
</container> (例: 参考情報。)
次の例は、出版物のPDFを追加した場合のサンプルである。
<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
<rootfiles>
<rootfile full-path="OEBPS/My Crazy Life.opf"
media-type="application/oebps-package+xml" />
<rootfile full-path="PDF/My Crazy Life.pdf"
media-type="application/pdf" />
</rootfiles>
</container> (以下、規定。)
OEBPSパッケージファイルに含まれる <manifest> 要素は、OEBPSの処理において利用されるただ一つのマニフェストを指定する。ZIPアーカイブ内の補助的なマニフェスト情報、あるいは付加的な(OPTIONAL) "manifest.xml"ファイルはOEBPSの処理を目的として使われてはならない(MUST NOT)。ZIPアーカイブ内の無関係なファイル(すなわち、META-INF内のファイルや別の表示形式のファイルなど、ZIPアーカイブに含まれるファイルの内、パッケージファイルの <manifest> 要素にリストされていないもの)はOEBPS出版物の処理には使われてはならない(MUST NOT)。
フルパス属性の値は、(RFC 3986で定義される) "path-rootless"の形式だけからなる(RFC 3986で定義される) "path component"を含まなければならない (MUST)。各path componentは、それらが使われるコンテナのルートとの相対となる。
適合OCFユーザエージェント (Conforming OCF User Agent)では、認識されない要素(およびコンテンツ)や属性はcontainer.xmlファイルの中で無視されなければならない(MUST)。これには他の名前空間からの、認識されない要素や属性も含まれる。
適合するcontainer.xmlファイルは、他の名前空間からの要素(および要素の子ノード)と属性を取り除いた結果、ルート要素として <container> 要素を持つRELAX NG OCFスキーマに対してvalid(妥当)でなければならない(MUST)。
次の場合は適合する。
<?xml version="1.0"?>
<container version="1.0"
xmlns="urn:oasis:names:tc:opendocument:xmlns:container"
foo:xmlns="..."
foozle:xmlns="..." />
<foo:bar />
<rootfiles foozle:identifier="bar"]]>
...
</rootfiles>
</container>
次の場合は、 <foo> 要素がnon-namespace-qualifiedな使い方となっているため、適合しない。
<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container"]]> <foo />
<rootfiles>
...
</rootfiles>
</container>
次の場合は、 <rootfiles> 要素の "identifier" 属性がnon-namespace-qualifiedな使い方となっているため、適合しない。
<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container"]]>
<rootfiles identifier="bar"]]>
...
</rootfiles>
</container> manifest.xmlが存在する場合、このファイルは暗号化されてはならない(MUST NOT)。
有効なOCFコンテナは、ルートレベルにある"META-INF"内に"metadata.xml"というファイルを持つ場合がある。ファイルが存在する場合、コンテナレベルのメタ情報として利用されなければならない(MUST)。OCF 1.0では、そのようなコンテナレベルのメタ情報は明示されない。このファイルに関しては、将来拡張される可能性が高い(SHOULD)。
"META-INF/metadata.xml"が存在する場合、その内容はnamespace-qualifiedな要素からなるvalid(妥当)なXMLでなければならない(MUST)。これは、後続バージョンのOCFにおいて、このファイルの要素と属性について特定の文法と名前空間を指定する可能性があり(MAY)、その際の衝突を避けるためである。
metadata.xmlが存在する場合、このファイルは暗号化されてはならない(MUST NOT)。
コンテナファイルシステムのルートレベルにある"META-INF"に
付加的に(OPTIONAL)存在する場合のある"signatures.xml"は、コンテナおよびそのコンテンツのデジタル署名を持つ。このファイルは、ルート要素を <signatures> とするXMLドキュメントである。 <signatures> 要素は、"
XML-Signature Syntax and Processing" (http://www.w3.org/TR/2002/REC-xmldsig-core-20020212) に定義されている通りに、 <Signature> 型の子要素を含む。署名は出版物やその他の表示形式に対して適用することができ、その対象は全体でも一部の表示形式でもよい。XML Signatureは、XMLだけでなく、任意の種類のデータの署名を指定することができる。signatures.xmlが存在する場合、このファイルは暗号化されてはならない(MUST NOT)。
signatures.xmlが存在しない場合、OCFコンテナがコンテナレベルで署名状況の情報を提供することはない。しかしながら、付加的に含まれる表示形式でデジタル署名が存在することは可能である。
signatures.xmlのルート要素とならなければならない(MUST) <signature> 要素を記述するRELAX NG OCFスキーマについては附録Aを参照のこと。
OCFエージェントがコンテナ内にデータの署名を作成する場合、signatures.xmlファイルの <signatures> 要素の新しい子要素 <Signature> として署名を追加するべきである(SHOULD)。
signatures.xmlファイルの各 <Signature> 要素は、XML Signatureの <Manifest> 要素およびその下位要素 <Reference> を用いて、署名を適用するデータをIRIで特定する。それぞれ格納されたファイルが個別に署名される場合、もしくは一括して署名される場合がある(MAY)。各ファイルを個別に署名する場合、要素の妥当性を判断するダイジェスト値が個別に作成される。このアプローチではSignature要素が大きくなるかもしれない(MAY)。各ファイルが一括して署名される場合は、署名する一連のファイルがXML Signatureの <Manifest> 要素に列挙され、一つ以上の <Signature> 要素から参照される。
signatures.xmlファイルを除き、コンテナ内のすべてのファイル、あるいはその一部にそのまま署名することが可能である。signatures.xmlを署名するべき(SHOULD)か、また署名する場合はどのようにするべき(SHOULD)かは、署名者の目的による。
- 署名者の署名を無効にすることなくコンテナに署名を追加もしくは削除させたい場合は、signatures.xmlファイルを署名するべきではない(SHOULD NOT)。
- 署名者の署名を無効にするように署名を追加もしくは削除させたい場合は、作成される <Signature> を除く既存の署名ファイルすべてを署名できる(XML Signatureのセクション6.4.4に定義された) Enveloped Signature変換を利用できる。この変換では既存のすべての署名を署名し、次の署名がパッケージに追加された場合に無効となる。
- 署名者の署名を無効にするよう既存の署名の削除と、署名の追加を許可したい場合、既存の署名だけを署名するためにXPath変換が利用できる (これは提案に過ぎない。XPath変換についてはOCF仕様の一部ではない)。
XML Signatureは署名とセマンティック(意味)とを結びつける事はないが、例えばSingature要素に署名の説明を加えるなどの方法で、特定のエージェントがセマンティック(意味)の情報を含むことは
あるかもしれない(MAY)。XML Signatureは、(例えばSignatureProperties要素により)どのように署名に付加情報が加えられ得るかを記述する。
次のXMLは"signatures.xml"ファイルの例であり、"XML-Signature Syntax and Processing"のセクション２の例に基づいている。この例では、コンテナ内に署名を一つ含み、その署名は OEBPS/book.html と OEBPS/images/cover.jpeg の二つに適用される。
<EncryptedKey> 要素はコンテナ内で利用される各暗号化キーを表し、 <EncryptedData> 要素は暗号化された各ファイルを示す。それぞれの <EncryptedData> 要素は、XML Encryptionにて示されている通り、それぞれ一つの <EncryptedKey> 要素を参照する。
ZIPコンテナの最初のファイルは、MIMEタイプ(すなわちASCIIで"application/epub+zip"。パディングやスペース、大文字は入れないこと)が記述された、ファイル名がASCIIで'mimetype'のファイルでなければならない(MUST)。このファイルは圧縮・暗号化されてはならず(MUST NOT)、ZIPヘッダに拡張フィールドが存在してはならない(MUST NOT)。この場合、RFC 2048にあるように、ZIPコンテナは便利な"magic number"をサポートすることになる。
