Translation:Container – META-INF container.xml
From IDMLWiki
Contents |
1.4.6 コンテナー - META-INF/container.xml（オプション）
（これは標準です）
UCFコンテナーは、コンテナーファイルシステムのルートレベルの「META-INF」ディレクトリー内に「container.xml」ファイルを含んでいるかもしれません（MAY）。「container.xml」ファイルが存在する場合、このファイルはMIMEタイプを識別するかもしれないし（MAY）、パス情報やコンテナのルートファイル、コンテナ内の交互の翻訳などを含んでいるかもしれません（MAY）。 UCFベースのフォーマットは、「container.xml」内のルートファイルを識別するか、コンテナの処理を開始する特有の方法を指定しなければなりません（MUST）。セクション3.5.1.2に示すように、「container.xml」ファイルはコンテナ中で暗黙の関係を指定するかもしれません（MAY）。
「container.xml」ファイルを暗号化してはいけません（MUST NOT）。
「container.xml」ファイル（XML）はすべてのエレメントと属性に「urn:oasis:names:tc:opendocument:xmlns:container」名前空間を使用しています。このバージョンに準拠するすべてのコンテナは「version="1.0"」という属性を含まなければなりません（MUST）。
RELAX NG UCFスキーマでは<container>エレメントを「container.xml」のルートエレメントに記述しなければなりません（MUST）。
Rootfiles（オプション）
<rootfiles>エレメントは、少なくとも1つの<rootfile>エレメントを含まなければなりません（MUST）。
各<rootfile>エレメントは、パブリケーションに含まれたただひとつのrootfileを指定します。rootfileはしばしば他のファイル一覧（enumeration）で表されることがあります。
UCFユーザーエージェント適合では、認識されていないエレメント（とコンテンツ）や属性は、container.xmlファイルの中で無視されなければなりません（MUST）。他の名前空間から認識されていないエレメントと属性も含まれます。
container.xmlファイルの適合では、他の名前空間からエレメント（またはその子ノード）と属性のすべての取り除いた後に、ルート要素として<container>を持つRELAX NG UCFスキーマによって妥当でなければなりません（MUST）。
Relationships（オプション）
「Container.xml」は、コンテナー中のファイルの暗黙の関係を識別する情報を含んでいるかもしれません（MAY）。通常、1ファイルは、明示的に別のファイルの参照です。例えば、SVGでのページ記述はイメージに参照を付けるかもしれません。間接的にファイルに参照を付けることは便利な場合があります。例えば、1個のファイルには、2番目のファイルに関連しているメタデータを保存するかもしれません。間接的な連携を使用する時、単にメタデータリソースを作成して、オリジナルのリソースかパッケージの中のどんなリソースも変えないことによってメタデータを加えるのは可能になります。
便宜を越えて、間接的な連携はコンテナファイルに、メタデータまたは注釈のような種類のデータの追加が許されていれば、デジタル署名することができます。例えば、注釈を持たないドキュメントは署名できます。その後、署名を無効にせずに注釈を加えることができます。
UCFは、2個のコンテナァイルの関係を確立するのに総括的なメカニズムを提供します。関係は、ターゲット名のために1セットのソース名から関係タイプとマッピングを指定します。どんなファイルに関しても、関連するファイルを決定するのにこの関係を使用できます。しかしながら、UCFは関連するファイルの存在を必要としません。
<container>ルートエレメントは<relationships>子エレメントを含んでいるかもしれません（MAY）。このエレメントは、特定の関係について記述する1つ以上の<relationships>子エレメントを含んでいるかもしれません（MAY）。各<relationships>エレメントは属性を含んでいます、関係タイプ、ターゲット名をマップするパターンを指定します。タイプは適切な名前です。UCFは1つの関係タイプを定義します、「metadata.」UCFベースフォーマットは、名前空間を指定することによって他のタイプを加えることができます。ターゲットパターンの関係が解決される場合、代用される次の変数を含んでいるかもしれない文字列です：
| 変数 | 定義 | 例 |
|---|---|---|
| path | リソースのためのフルパス | /a/b/c.d |
| dir | ディレクトリ（filenameを除く） | /a/b |
| filename | ディレクトリパスを除いたpath | c.d |
| basename | 拡張子を除いたfilename | c |
| ext | filenameの拡張子 | d |
これらの変数は、名前をブレースで囲み「$」とともに開始ブレースで指定します。変数名の後の1文字目が文字でない場合、ブレースは省略されるかもしれません。ターゲットは、パターン中の通常のテキストをコピーして、変数をそれらの値に取り替えることにより解決されます。
コンテナ例のどんなファイルも、「.xmp」拡張子を持つソースファイルと同じ名前の関連メタデータファイルを持つことができます。
Manifest -- META-INF/manifest.xml（オプション）
任意である「manifest.xml」予約ファイルは「META-INF」ディレクトリー内の有効なUCFコンテナのルートレベルに現われるかもしれません（OPTIONAL）。このファイルが存在しているなら、ファイルの内容はODF1.0のマニフェストスキーマで定義されるとおりでなければなりません（MUST）。http://www.oasis-open.org/committees/download.php/12570/OpenDocument-manifest-schema-v1.0-os.rng
「manifest.xml」は暗号化してはなりません（MUST）。
Metadata -- META-INF/metadata.xml（オプション）
「metadata.xml」予約ファイルは「META-INF」ディレクトリー内の有効なUCFコンテナーの、コンテナーファイルシステムのルートレベルに現われるかもしれません。このファイルが存在しているなら、コンテナレベルメタデータにこのファイルを使用しなければなりません（MUST）。OCFのバージョン1.0では、どのようなコンテナレベルメタデータも指定されません。
「META-INF/metadata.xml」ファイルが存在しているなら、コンテンツはnamespacequalifiedエレメントを持ち（OCFの将来のバージョンとの衝突を避けるための）妥当なXMLでなければなりません（MUST）。このファイルの中でエレメントと属性に個別文法と名前空間を指定してもよいでしょう（MAY）。
UCFに基づくAdobe定義のフォーマットは、メタデータを指定するのにXMPを使用しなければなりません（MUST）。http://www.adobe.com/products/xmp/
デジタル署名 -- META-INF/signatures.xml（オプション）
任意である「signatures.xml」ファイルは「META-INF」ディレクトリのコンテナーファイルシステムのルートレベルにあり、コンテナおよびその内容のデジタル署名を持っています。このファイルのコンテンツはUCF1.0の仕様ではありません。しかしながら、UCFの今後の改正でこのファイルのためにフォーマットを定義するでしょう。ありそうな定義に関して付録Dを見てください。
暗号化 -- META-INF/encryption.xml（オプション）
任意である「encryption.xml」ファイルは「META-INF」ディレクトリのコンテナーファイルシステムのルートレベルにあり、コンテナおよびその内容のすべての暗号化情報を持っています。このファイルのコンテンツはUCF1.0の仕様ではありません。しかしながら、UCFの今後の改正でこのファイルのためにフォーマットを定義するでしょう。ありそうな定義に関して付録Eを見てください。
著作権管理 -- META-INF/rights.xml（オプション）
任意である「rights.xml」予約ファイルは「META-INF」ディレクトリ内の有効なUCFコンテナのルートレベルに現われるかもしれません（OPTIONAL）。（信頼あるパブリケーションの交換、著作権保持、仲介人およびユーザーのための）デジタル著作権管理（DRM：digital rights management）情報のために、この場所が確保されています。UCFバージョン1.0では、DRM情報は必須フォーマットではありません（REQUIRED）が、UCF仕様の将来のバージョンは、DRM情報のための特別なフォーマットを指定するかもしれません。
「META-INF/rights.xml」ファイルが存在する場合、使用するXML 名前空間を使った整形式のXMLドキュメントでなければなりません（MUST）。そして、コンテンツは特定の形式を指定してよく（MAY）、UCFの将来のバージョンとの衝突を避ける名前空間で適切なエレメントを持つ妥当なXMLであるべきです（SHOULD）。
「rights.xml」は暗号化されていてはなりません（MUST NOT）。
「rights.xml」ファイルが存在しない場合、UCFコンテナはコンテナのどの部分も著作権管理を示す情報を提供しません。
