Open Packaging Conventions

Open Packaging Conventions (OPC) はマイクロソフトによるファイル格納に関する技術で、XMLと非 XML ファイルをパッケージするための規格である。Open XML Paper Specification (OpenXPS) ドキュメントやOffice Open XML (OOXML) で採用されている。

OPC形式でファイルをパッケージ化する利点は、独立したファイルをそのままの形でドキュメントに添付でき、XMLをそのまま使用するより小さいファイルを生成できることである。

OPC 仕様はOffice Open XML標準（ISO/IEC 29500:2008 およびECMA-376）のPart 2に定義されている。

ISO/IEC 29500-2:2008規格とECMA-376の第2版以降では PKWARE社.のZIP ファイルフォーマット仕様 バージョン 6.2.0 (2004)を引用規格としており、追補として規範例が付属する。注意: ECMA-376 の第1版では上記より新しいPKWareのZIPファイルフォーマット仕様 バージョン6.2.1 (2005)を参照している。この版のZIPファイル形式は国際標準に定義されていないが、コミュニティと開発者間には広く普及している。

マイクロソフトが2006年に Internet Engineering Task Forceに提出したドラフトではOPC形式のパッケージへの参照として "pack" URI スキーム (pack://) を使用するよう記述していたが、このドラフトは 2009年に失効している。この記述方法は Internet Standard の URI スキーム(STD 66,

XML Paper Specification (XPS)とOffice Open XML (OOXML) はともにZIPを利用したOpen Packaging Conventions (OPC) を使用している。XMLマークアップファイルのほかに、ZIPパッケージに含められるファイルには PNG、BMP、AVI、PDF、RTF のようなテキスト、バイナリファイルのほかに、すでにパッケージ化されたODFファイルを含むこともできる。OPC ではファイルの命名規則も定義しており、バイナリとXMLファイルがZIP書庫ファイル内の格納場所に依存しないよう間接参照方法も定義している。

OPCファイルは一般的なZIPユーティリティで開くことができる。また、OPCファイルでは、間接参照、チャンク化、および、相対間接参照がサポートされている。

OPCは、多数の新しいファイルフォーマットの基盤技術となっている:

OPCは.NET Framework 3.0でネイティブにサポートされており、System.IO.Packaging ネームスペースで利用できる。他言語のためにオープンソースのライブラリが存在する。

Windows 7より、OPCはWindows APIとしてもサポートされるようになり、COMインタフェースを通じて利用できる。Packaging API という名称で参照できる。

別の方法として、ZIPライブラリを使ってOPCファイルを作成、開くことができる。この場合ZIP内に名称規約に従ったファイルが正しく格納されている必要がある。

OPCの専門用語において、パッケージはZIPアーカイブに対応し、パーツはZIPアーカイブに格納されているファイルに対応する。パッケージ内の各パーツには、MIMEメディアタイプ形式で表現された特定の要素タイプに加えて、一意のURI準拠のパーツ名が存在する。パーツの要素タイプはパーツに格納されているデータの型を明示的に定義しており、拡張子に起因する重複や曖昧さといった扱いの難しさを削減する。

OPCパッケージにはパッケージ、パーツ、および、外部リソースの間の関連付けを定義するリレーションシップを含めることができる。

ディレクトリおよびパーツの階層構造に加えて、OPCパッケージでは、関連付け関係の有向グラフを通したコンテンツへのアクセスにリレーションシップを一般に使用する。

リレーションシップは4つの要素から構成される:

• 識別子 (ID)
• 省略可能なソース（パッケージまたはパッケージ内のパーツ）
• リレーションシップタイプ（リレーションシップのタイプを定義するURI形式表現）
• ターゲット（パッケージ内の他のパーツまたは外部リソースを指すURI）

OPCパッケージは（テキスト、画像、XML、バイナリなど）任意の形式のデータを含むパーツを格納できる。
ただし、拡張子「.rels」は「/_rels」サブフォルダ内にリレーションシップメタデータを格納するために予約されている。
サブフォルダ名「_rels」、そのようなディレクトリ内のファイル拡張子「.rels」、そして、任意のフォルダ内のファイル名「[Content_Types].xml」の3つのみがOPCパッケージに格納されるファイルで予約済みとなっている名前である。

/[Content_Types].xmlファイル

このファイルはパッケージ内のすべてのパーツのMIMEメディアタイプを定義する。「/[Content_Types].xml」ファイルは、特定のパーツに対する要素タイプのファイル拡張子の既定値とは異なるオーバーライドに加えて、ファイル拡張子に基づく既定の割り当てを定義する。例えば、これらの定義済みのMIMEタイプの1つは次のようになる:

<Default Extension="rels" ContentType="application/vnd.openxmlformats-package.relationships+xml"/>

/_rels

ルートレベルの「/_rels」フォルダにはパッケージ全体のリレーションシップが格納される。「/_rels」フォルダには通常「.rels」という名前のファイルが含まれる。「/_rels/.rels」は開始時パッケージレベルリレーションシップが格納されるファイルである。通常、OPC形式のファイルを開くと、アプリケーションは初めに「/_rels/.rels」ファイルにアクセスし、開始時パッケージレベルリレーションシップを読み込む。

[パーツ名].rels

各パーツはそれ自体のリレーションシップを持つことができる。_relsフォルダは与えられたパッケージ内の任意のパーツに対するリレーションシップを見つける場所である。特定のパーツに対するリレーションシップを見つけるには、パーツの兄弟ノードである「_rels」フォルダ内を調べる。もしパーツがリレーションシップを持っている場合、「_rels」フォルダにはパーツ名に「.rels」を加えた名前のファイルが存在する。例えば、要素タイプパーツファイルにリレーションシップがあるならば、「[Content_Types].xml.rels」という名前のファイルが「/_rels」フォルダ内に存在する。

（ルートパッケージに関連付けられたリレーションシップを含む）すべてのリレーションシップはXMLファイルとして表される。

「.rels」ファイルをテキストエディタで開くと、そのパーツからターゲットされるすべてのリレーションシップを定義する実際のXMLマークアップを見ることができる。

典型的なリレーションシップファイルは次のようなXMLコードを含む:

<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
  <Relationship Id="R0" Type="http://schemas.microsoft.com/xps/2005/06/fixedrepresentation" Target="/FixedDocumentSequence.fdseq"/>
  <Relationship Id="R1" Type="http://schemas.openxmlformats.org/package/2006/relationships/metadata/thumbnail" Target="/Documents/1/Metadata/Page1_Thumbnail.JPG"/>
</Relationships>

これはルートパッケージに対する2つの関係を定義しており、最初のものはルートパッケージとして考えることができ（ここで示したものは初期のMicrosoft XPSドキュメントであり、openxmlformatsコレクションでOpen XML Paper Specificationとして標準化される前である）、もう1つは代替形式への参照（ここではドキュメントの最初のページのサムネイル画像）に使用されている。

ファイル破損の影響を少なくできることから、ドキュメントを小さなチャンクに分割することは推奨されている。

また、これはデータアクセスの向上にもつながる。

たとえば、1つのXMLパーツ内にすべてのスタイル情報を格納し、それぞれのワークシートやテーブルをそれ自体からなるパーツに格納する。

これによって利用側アプリケーションは高速なアクセスとオブジェクト作成の削減が可能になり、複数のプロセスが同じドキュメントで作業することが簡単になる。

Open Packaging Conventionsでは、参照を持つ各ファイルは間接参照リストである_relsファイルを持つ。

これによって、いくつかの場面で一部の情報を関連するすべてのリソースとともに切り貼りすることが容易となるほか、ファイル間での名前衝突のおそれのない名前スコープの提供が可能になるなどの利点がある。

• OPC UA