Office Open XML ファイルフォーマット

リレーションシップ

リレーションシップファイルの内容例は以下の通り。 (word/_rels/document.xml.rels):
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?><Relationships
 xmlns="http://schemas.microsoft.com/package/2005/06/relationships">
 <Relationship Id="rId1"
 Type="http://schemas.microsoft.com/office/2006/relationships/image"
 Target="http://en.wikipedia.org/images/wiki-en.png"
 TargetMode="External" ></Relationship>
 <Relationship Id="rId2"
 Type="http://schemas.microsoft.com/office/2006/relationships/hyperlink"
 Target="http://www.wikipedia.org"
 TargetMode="External" ></Relationship></Relationships>
上記のように、文書中で参照されている画像は
http://schemas.microsoft.com/office/2006/relationships/image 形式部分を参照すれば見つけることが出来る。使用される画像を変更するには relationship を修正すればよい。

次の例ではハイパーリンクのインラインマークアップを例示する。:
<w:hyperlink r:id="rId2" w:history="1"
 xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships"
 xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main">
この例では、 Uniform Resource Locator (URL) が "rId2"として表現されている。実際のURLはリレーションシップファイルにあり、 "rId2" アイテムの場所に記述されている。リンクされた画像、テンプレートその他のアイテムは同様に参照されている。
画像は埋め込みまたはタグによるリンクができる:
 <v:imagedata w:rel="rId1" o:title="example" ></div>
これはイメージファイルへの参照である。全ての参照はリレーションシップ経由で管理されている。例として、document.xml が画像へのリレーションシップを持つとする。この場合document.xml と同じディレクトリ階層にある _rels ディレクトリにdocument.xml.rels というファイルが存在する。このファイルにはリレーションシップ定義がコンテンツタイプ、ID、場所につき記述されている。ID はXMLドキュメントで使用されている参照IDである。タイプはメディア形式のリファレンススキーマ定義であり、場所はZIPパッケージ内またはURLで定義された外部の場所を指す。

ドキュメントプロパティ

Office Open XML は Dublin Core(ダブリン・コア) メタデータ 形式のエレメントのセットと DCMI メタデータ用語をドキュメントプロパティの記録に使用する。Dublin Core はクロスドメインの情報リソース記述法であり、ISO 15836:2003 で定義されている。
ドキュメントのプロパティ (docProps/core.xml) をDublin Coreで記述した例は以下の通り:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><cp:coreProperties xmlns:cp="http://schemas.openxmlformats.org/package/2006/metadata/core-properties"
 xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <dc:title>Office Open XML</dc:title>
 <dc:subject>File format and structure</dc:subject>
 <dc:creator>Wikipedia</dc:creator>
 <cp:keywords>Office Open XML, Metadata, Dublin Core</cp:keywords>
 <dc:description>Office Open XML uses ISO 15836:2003</dc:description>
 <cp:lastModifiedBy>Wikipedia</cp:lastModifiedBy>
 <cp:revision>1</cp:revision>
 <dcterms:created xsi:type="dcterms:W3CDTF">2008-06-19T20:00:00Z</dcterms:created>
 <dcterms:modified xsi:type="dcterms:W3CDTF">2008-06-19T20:42:00Z</dcterms:modified>
 <cp:category>Document file format</cp:category>
 <cp:contentStatus>Final</cp:contentStatus></cp:coreProperties>

設計のアプローチ

ODF に携わったPatrick Durusau によれば、OOXMLとODFのマークアップのスタイルは文書の2つの側面を示すものである。一方は"要素(エレメント)"の側面で、もう一方は"属性（アトリビュート)"の側面である。彼はOOXMLは"要素側のアプローチ"を採っていると述べ、一例として KeepNext 要素を挙げている:
<w:pPr> 
  <w:keepNext></w:keepNext> 
  … 
</w:pPr>
これと対照的に ODF では同じ意味を記述するのに属性fo:keep-nextを使っている。
Office Open XML の XML スキーマ は、文書の読み込み時間と解釈のスピードに重点を置いたものである。 2007年当時のアプリケーションを使ったテストでは、XMLベースのドキュメントはバイナリ形式のものより読み込み速度が遅かった。 パフォーマンスを向上させるため、Office Open XML では要素名を非常に短い物としており、スプレッドシートでは日付をインデックス番号(1899-1904)で表記している。. 画一的かつ包括的であるために、Office Open XML は一般的にデータとメタデータについて (element names ending in Pr for properties) 属性を複数付けるより子エレメントを増やす方式によりプロパティの階層構造化を可能にしている。 Office Open XML does not use mixed content but uses elements to put a series of text runs (element name r) into paragraphs (element name p). 結果として、HTMLがフラットで人間がテキストエディターで編集しやすいのに比べて、簡潔で何層にも入れ子されたものとなっている。
要素と属性のネーミングは批判を集めた部分である。OOXML(ECMA-376)では色とテキストの寄せ方向の文法はドキュメントがテキストかスプレッドシートかプレゼンテーションかによって3種類の異なった記法になっている。Rob Weir (IBM 社員、 OASIS OpenDocument Format 技術委員会副議長) は "このような恐怖は技術的に正当化できるのか?"と問うている。彼は対照例として OpenDocumentを挙げ、 "ODF では W3C の XSL-FO 用語を文書の整形に用いており、用語の統一に役立てている"と述べている。
他に、デザインがあまりにマイクロソフトのアプリケーションに密着しすぎているというという議論もある。ISOにおける国際標準化が進行中であった2007年8月、 Linux Foundation はブログでISOの各国代表組織に対して"コメント付きのノーを"と呼びかけた。記事では"OOXML はベンダーのバイナリフォーマットを直接書き出しただけの物で、既存の国際標準(例: 暗号化アルゴリズム、VML等)の再利用を避けているとしている。
OOXML標準化に先だって議論されるべき点が何百とあり、プラットフォーム特有機能と結びついたバイナリコードを存続させ、MS-Officeのバグ、知的財産、プロプライエタリーや機密に準拠したタグ、クリアになっていない知的財産を標準に取込み撒き散らす行為だと述べている。(日経参考記事)
JTC 1 に投稿されたバージョンの仕様書は 6546 ページの長さにわたり、このような長さである必要性、正当性にも疑問が呈された。 Google は "ODF 標準ならば、同じゴールでありながら 867 ページでしかない"と声明を出した。

WordprocessingML (WML)

ワードプロセッサ文書はWordprocessingML と呼ばれるXMLボキャブラリを使用する。 wml.xsd でスキーマが定義されており、このボキャブラリは仕様書パート1の 11 章に定義されている

SpreadsheetML (SML)

ワードプロセッサ文書はWordprocessingML と呼ばれるXMLボキャブラリを使用する。 sml.xsd でスキーマが定義されており、このボキャブラリは仕様書パート1の 12 章に定義されている。
各ワークシートはルートエレメント名 <worksheet>...</worksheet> を頂点とするXMLで記述され、名前空間はhttp://schemas.openxmlformats.org/spreadsheetml/2006/main で定義される。
SpreadsheetML での日付と時刻の表現形式は批判を呼んだ。ECMA-376 1st edition では ISO 8601:2004 "Representation of Dates and Times"に準拠しておらず、 Lotus 1-2-3  に存在する 1900 年を閏年として扱うバグをそのまま実装するよう求めていたためである。ECMA-376 準拠の製品ではスプレッドシート関数の WEEKDAY() を使うよう求められ、これは特定の年期間の曜日、日数の計算を誤らせる。 ECMA-376 2nd edition (ISO/IEC 29500) ではISO 8601:2004 "Representation of Dates and Times"の表現方式がLotus 1-2-3のバグ互換方式に加えて使用を認められた。

Office MathML (OMML)

Office Math Markup Language is a mathematical markup language which can be embedded in WordprocessingML, with intrinsic support for including word processing markup like revision markings, footnotes, comments, images and elaborate formatting and styles.
The OMML format is different from the World Wide Web Consortium (W3C) MathML recommendation that does not support those office features, but is partially compatible through XSL Transformations; tools are provided with office suite and are automatically used via clipboard transformations.

The following Office MathML example defines the fraction: 
<m:oMathPara><!-- mathematical block container used as a paragraph -->
  <m:oMath><!-- mathematical inline formula -->
    <m:f><!-- a fraction -->
      <m:num><m:r><m:t>π</m:t></m:r></m:num><!-- numerator containing a single run of text -->
      <m:den><m:r><m:t>2</m:t></m:r></m:den><!-- denominator containing a single run of text -->
    </m:f>
  </m:oMath></m:oMathPara>
Some have queried the need for Office MathML (OMML) instead advocating the use of MathML, a W3C recommendation for the "inclusion of mathematical expressions in Web pages" and "machine to machine communication". Murray Sargent has answered some of these issues in a blog post, which details some of the philosophical differences between the two formats.

DrawingML

DrawingML は Office Open XML documents内で使用される vector graphics markup language である。主な特色はテキスト要素やベクター図形要素、グラフィカルな表やチャートのグラフィック描画である。
DrawingML の表は Office Open XML にある3つの表の記述モデルの一つであり、(残る2つは WordprocessingML と SpreadsheetML) エフェクト表現に最適化されており、主な用途はプレゼンテーション用途のPresentationML マークアップでの使用である。
DrawingML は画像エフェクト（影、反射など）を備えており、これはDrawingML内の各種画像エレメントに適用することができる。
DrawingML では3D(立体)エフェクトも可能で、 for instance to show the different graphical elements through a flexible camera viewpoint.
Office Open XML パッケージ内で複数のテーマパーツを定義することもできる。テーマはOffice Open XML パッケージ全体に適用される。
DrawingML はほかの ベクター図形 画像フォーマットであるSVG 等とは関連がない。 これらはコンバートすれば DrawingML Office Open XML document内にネイティブに埋め込むことができる。SVGのサブセットである OpenDocument フォーマットはベクター画像を個々にファイルに保存しており、アプローチが異なる。
DrawingML 画像の寸法は English Metric Units (EMUs) という単位で表現される。これは英国法とメートル法で一致する数値表現が必要であったためで、1centimeter の1/360,000 にあたり、1inchの1/914,400 であり, 1pointの1/12,700 である。この単位を採用したためにドキュメント内のほとんどの寸法を整数(integer)で正確に表現することができる。浮動小数点で表記すれば要素が増えるにつれて誤差が積み上がることが避けられない。Floating point cannot accurately represent a fraction that is not a sum of powers of two and the error is magnified when the fractions are added together many times, resulting in misalignment. As an inch is exactly 2.54 centimeters, or 127/50, 1/127 inch is an integer multiple of a power-of-ten fraction of the meter (2×10⁻⁴ m). To accurately represent (with an integer) 1 μm = 10⁻⁶ m, a divisor of 100 is further needed. To accurately represent the point unit, a divisor of 72 is needed, which also allows divisions by 2, 3, 4, 6, 8, 9, 12, 18, 24, and 36 to be accurate. Multiplying these together gives 127×72×100 = 914,400 units per inch; this also allows exact representations of multiples of 1/100 & 1/32 inch. プログラマーでありISO, W3C, IETFにおいて標準化活動を行う Rick Jelliffe によれば、EMUs はこのデザイン分野上の問題に対する合理的な解決策であるとされる。
DrawingML (and the transitional-use-only VML) が W3C の推奨であるSVGを採用していないことに対する非難も存在する。 VML はW3Cの推奨にならなかったためである。

非XML コンテンツ

OOXML 文書は、XMLコンテンツに加えて別のリソース（画像、ビデオ等）を含むのが通常である。
文書フォーマットにこの種のリソースを加える際のチョイスについても批判があった。ECMA-376 1st edition では"添付オブジェクトの代替イメージのリクエストタイプ"と"クリップボード形式"について WMF(Windows メタファイル) または EMF(拡張メタファイル) を指定していた。どちらもハードコードされWindowsに強く依存した部分でありマイクロソフトの知的所有権に支配される。批判勢力は代わりにプラットフォームに中立的な ISO/IEC 8632 "Computer Graphics Metafile"の採用を求めた。

Compatibility settings

一部バージョンのOffice Open XML には "compatibility settings"という仕様が含まれる。  ECMA-376 1st Editionの Part 4 ("Markup Language Reference") に含まれていたが、標準化プロセスを経てISO/IEC 29500:2008 の新規パート ("Transitional Migration Features") となった。(Part 4とも呼ばれる) 
この設定項目には以下のような要素名 ( autoSpaceLikeWord95, footnoteLayoutLikeWW8, lineWrapLikeWord6, mwSmallCaps, shapeLayoutLikeWW8, suppressTopSpacingWP, truncateFontHeightsLikeWP6, uiCompat97To2003, useWord2002TableStyleRules, useWord97LineBreakRules, wpJustification and wpSpaceWidth 等) が含まれており、DIS 29500 標準化段階で論争となった。 結果として、 ISO/IEC 29500 に新しい文言が追加された。
Free Software Magazine は記事でこれらの設定用マークアップについて批判した。Office Open XML uses は互換設定を直接要素名に使っており、その設定にはレパートリーがないーすなわち互換性設定が増える度に要素名が新規定義されねばならず、これでは相互運用性に全く寄与しないという。

拡張性

この標準は2種類の拡張の仕組みを持ち、 Part 3 (ISO/IEC 29500-3:2008)の「Markup Compatibility and Extensibility (MCE) 」とPart 1の18.2.10 のExtension Lists に定義されている。