Translation:Specification contents/ja

From IDMLWiki

Contents 1 1　要約 2 2　イントロダクション 3 3　用語 4 4　INXとIDML、InDesign Scripting 4.1 Script (JavaScript): 4.2 IDML: 4.3 4.1　ダイナミックオブジェクトモデル 4.4 4.2　IDMLとサードパーティ（データ）の関係 5 5　IDMLの用途 6 6　IDMLの目標 7 7　IDMLデザインアプローチ 7.1 7.1　効率化のための個別な議題 7.2 7.2　InDesignとの互換性を最大化 7.3 7.3　XML Elementsからの独立 7.4 7.4　エレメントより属性を使用すべし 7.5 7.5　自己をドキュメント化（Self-Documenting） 7.6 7.6　InDesignデータ構造のリテラル表現ではない 7.7 7.7　パフォーマンス 7.8 7.8　旧バージョンのためのサポート 8 8　IDMLのドキュメント構造 8.1 8.1　IDMLパッケージファイル機構 8.1.1 8.1.1　MIMETYPE 8.1.2 8.1.2　designmap.xml 8.1.3 8.1.3　Master SpreadsフォルダとMasterSpreads.xml 8.1.4 8.1.4　Resourcesフォルダ 8.1.4.1 Graphic.xml 8.1.4.2 Fonts.xml 8.1.4.3 Styles.xml 8.1.4.4 Preferences.xml 8.1.5 8.1.5　Spreadsフォルダ 8.1.6 8.1.6　Storiesフォルダ 8.1.7 8.1.7　XMLフォルダ 8.1.7.1 BackingStory.xml 8.1.7.2 Tags.xml 8.1.7.3 Mapping.xml 8.1.8 8.1.8　META-INFフォルダ 8.2 8.2　IDMLコンポーネントの名前 8.2.1 8.2.1　デフォルト名 8.2.2 8.2.2　ユーザー定義名 8.2.3 8.2.3　インポート時にコンポーネント名をリセットする 8.2.4 8.2.4　スクリプティングインターフェイス 8.2.5 8.2.5　C++API 9 9　IDMLの文法 9.1 9.1　XMLコンベンションとスタイル 9.1.1 9.1.1　IDML中の名前 9.1.2 9.1.2　空要素の使用 9.2 9.2　IDMLスキーマの生成 9.3 9.3 IDMLのデータ型 9.3.1 9.3.1　スカラーデータ型 vs. 複合データ型 9.3.2 9.3.2　Enumeration 9.3.2.1 スキーマ例1　ColumnGuideColorとMarginGuideColorエレメント 9.3.2.2 IDML例1　プロパティは属性かエレメントの値に依存 9.3.3 9.3.3　キー文字列 9.3.4 9.3.4　単位 9.4 9.4　オブジェクトの表現 9.4.1 IDML例2　オブジェクトのシリアライズ 9.5 9.5　プロパティの表現 9.5.1 9.5.1　属性としてのプロパティ表現 9.5.2 9.5.2　エレメントとしてのプロパティ表現 9.5.2.1 表2　エレメントのプロパティ 9.5.2.2 RecordType 9.5.2.2.1 IDML例3　RecordTypeのシリアライズ 9.5.2.3 Geometry 9.5.2.3.1 IDML例4　Geometryシリアライズ 9.5.2.4 VariableType 9.5.2.5 Complex Structures 9.5.3 9.5.3　プロパティエレメントの属性タイプを使う 9.5.4 9.5.4　オブジェクト参照フォーマット 9.5.5 9.5.5　ファイル相互参照例 9.5.5.1 図2　相互参照：<Document>からスプレッドファイル 9.5.5.2 図3　相互参照：<TextFrame>から<Story> 9.5.5.3 図4　相互参照：<ParagraphStyleRange>から<ParagraphStyle> 9.5.5.4 図5　相互参照：外部ファイルへの参照 9.5.5.5 図6　相互参照：ハイパーリンクソースとハイパーリンク場所

1　要約

IDMLはInDesignドキュメント（やコンポーネント）のXML表現です。このドキュメントは、IDMLファイルの構造やIDMLの妥当性のためのXMLスキーマ、IDMLファイルのサンプルなどを提供します。

2　イントロダクション

IDMLはInDesignドキュメントを完全に説明できるXMLベースの形式であり、Adobe InDesign CS4ドキュメントのための置き換え形式です。IDMLはInDesignアプリケーションを使わないで、テキスト、グラフィックフレーム、ストーリーなどのInDesignレイアウトの生成と編集方法を提供します。何を使って？　XMLを使って。

INXがそうであるように、IDMLはInDesignドキュメントのDocument Object Model（DOM）に基づいています（このDOMはスクリプト用のDOMをベースにしています）。InDesign CS2で導入されたINXは「InDesign互換」を表わし、前のバージョンでドキュメントを保存するために使用します。INXはInDesign CS4以前のInDesignドキュメントの後方互換性のために使用され続けるでしょう。IDMLは、InDesign CS4および将来のバージョンの間の後方互換性のために使用されるでしょう。

INXフォーマットはInDesignが単独で生成し読み込まれることを想定していたので、INXフォーマットを（自力で）書くか再編集することはたいへん困難でした。IDMLはINXをより判読可能にし、かつXMLツールを使用して、InDesignドキュメントを変更し組み立てるを容易にしたいと願うサードパーティやシステムインテグレーターの要望を実現します。IDMLを使用すれば、便利で柔軟性があり、パフォーマンスが高まるのを悟るでしょう。

IDMLはInDesignが他のさまざまな目的に形式を使用するので、INXにも似ています。ライブラリ項目やInDesignスニペット、InCopyアセットやストーリなどのように。

IDMLがXMLフォーマットであれば、IDMLドキュメントの中では必ずしもInDesignのXMLを利用する必要がないことに注目してください。InDesignでのXML実装と性能などの制限から逃れるため、InDesign外ですべてのXML処理を行うのがよいと思います（実際、多くのユーザーもそれを望むはずです）。

3　用語

InDesignでIDMLファイルを開くと、ドキュメント中のXML要素はオブジェクトに変換されます（それは通常のInDesignオブジェクトもスクリプティングオブジェクトモデル中のオブジェクトもです）。このために、この解説書中である用語を使用する場合、わたしたちは注意深く識別する必要があります。例えば「オブジェクト」という時、XMLエレメントのことを指しているのか、IDMLファイルが開かれた後のXML要素にマッピングされたInDesignオブジェクトなのかどちらでしょう？　同様の疑問はXMLの属性やエレメントのプロパティにも当てはまります。

この本の中で「XMLエレメント」と言う時、通常はIDML内の項目を指します。同様に「XML属性」と言う時、通常はXMLの属性値を指します。単なる「オブジェクト」や「プロパティ」といった用語を使う時、通常はInDesignドキュメントに含まれるそれらの実体を指します。

4　INXとIDML、InDesign Scripting

INX（IDMLの前身）は、InDesignのドキュメントを旧バージョン用に保存し使用するために導入されました。（今回、IDMLを導入するにあたって）複雑でエラーが起こりやすいバイナリーファイル用プラグインを書くのではなく、私たちはInDesignのスクリプト用の特徴を使用しようと決めました。INXやIDMLにエクスポートすると、InDesignはスクリプティングDOMからオブジェクトとその属性をXMLファイルへシリアライズします。INXやIDMLをInDesignが開く時、レイアウトを構築し、各種設定をセットし、テキストを入力し、フォーマットを適用し、ドキュメントを作成します。

今後もIDMLは大きく成長するでしょう。スクリプティングDOMを用いることで、InDesignのオブジェクトモデルは大きな利益を享受できます。

• オブジェクトモデルの低いレベルから、ハイレベルなディテールと変更を切り離します。
• よくできたドキュメントと理解しやすく拡張しやすいアーキテクチャ、サードパーティ（プラグインが作成した）データを追加しやすいファイルフォーマット。また、スクリプティングDOMの中でオブジェクト名が一意のオブジェクトと属性を示すように、既存のポリシーとと手順があります。
• オブジェクトとプロパティのパラメータ、その誤り訂正などの重要なレベル。
• アイテムを加えるか、削除するか、修正するために十分に定義された高いレベルでのバージョン支援メカニズム。

IDMLは以下の部分でスクリプティングDOMと異なっています:

• スクリプト用のイベント（メソッド）はIDMLドキュメントに含まれていません。
• IDMLは、いくつかのエレメントと属性があるオーダーに現れるのを必要としますが、ランダムアクセスとしてスクリプト用のDOMを見なすことができます。
• IDMLに含まれているいくつかのオブジェクトとプロパティはスクリプト（AppleScript, JavaScript, VBScript）などから利用できません。逆もまた同じ。
• いくつかの場合、デフォルトと同じであるプロパティ値はIDMLに書かれません。

以下の例はスクリプティングとIDMLとの浅からぬ関係を示しています:

Script (JavaScript):

IDML:

4.1　ダイナミックオブジェクトモデル

InDesignのスクリプト用のオブジェクトモデルがダイナミックにプラグインのセットと連動するのは重要です。InDesignスクリプティングをサポートするプラグインを追加したら、オブジェクト、プロパティ、一覧、およびメソッドはスクリプト用のオブジェクトモデルに現れるでしょう。そして、新しいオブジェクトとプロパティはエクスポートしたIDMLにも現れるかもしれません。さらにプラグインを追加したり、削除したり、無効化すれば、スクリプト用のオブジェクトモデルもまた変化して、その結果IDMLファイルに書かれたXML要素も変化できます。

4.2　IDMLとサードパーティ（データ）の関係

IDMLは追加されたプラグインのスクリプティングオブジェクトやそのプロパティをサポートします。IDMLはInDesignスクリプティングオブジェクトモデルの上に造られるので、プラグインが持つどんな特徴をもIDMLパッケージに含めることができるのです。

IDMLはサードパーティプラグイン情報を記録しません。そのため、サードパーティプラグインが書き加えたデータの再現性を保証しません。サードパーティプラグインがスクリプティングを実装しないか、不完全な場合、IDMLのエクスポート時にデータは含まれないでしょう。

IDMLファイルが現在インストールされていないプラグインを求めると、プラグイン固有のデータを無視し、IDMLの再書き出し時にもそれを含まないでしょう。この振る舞いが、通常のInDesignドキュメントを開いた時にサードパーティプラグインが無い場合の振る舞い（詳細はInDesignヘルプなどのドキュメントを参照してください）とは異なるのを注意してください。

IDMLはXML形式ですから、IDMLパッケージの中に任意のXML要素を追加できます。しかし、InDesignがIDMLファイルを開くとき、IDMLスキーマが存在しなければそれは無視されるでしょう（もちろん再びIDMLパッケージに書き出される時も含まれません）。

5　IDMLの用途

IDMLはXML技術と相互連携してInDesignのレイアウト方法を提供します。IDML形式でドキュメントを作成し、操作し、InDesign（インタプリタ）で解釈します。

IDMLは自動組版の要となるよう設計されました。IDMLを使用すれば、こんなことができるようになりますよ：

• データベースなどのデータソースから（プログラミングを用いて）IDMLを生成、編集できます。
• IDMLドキュメントの部分を再利用するか、ドキュメントを（あなたの）開発環境で使用できるコンポーネントに細かく分けてください。
• XSLTを使って、ドキュメントエレメントを変換してください。
• XPathかXQueryを使って、InDesignドキュメントのデータを見つけてください。
• 作成内容の管理や2つのデザインバージョンを比較するために、ソースコントロールを使用してください。

InDesign、InCopy、InDesign ServerなどのInDesignファミリーから使えるようにIDMLは企図されています。ですから、外部のアプリケーションとの協調は想定していませんし、（MarsやXSL-FO、SVGなどの）フォーマットの互換性などを考慮もしていません。しかし、XSLTをIDML構造に適用してIDMLをこれらの形式に変えるのは可能です。けれどそれはちょっとこの本に収まりそうにありません。

6　IDMLの目標

IDMLの主要な設計目標は以下のとおりです:

• 完全性: InDesignドキュメント上に作成できるどんなオブジェクト、プロパティ、または設定等もIDMLで表すことができます。IDMLファイルの書き出しと読み込みの互換性は完全だと思います。
• 読みやすさ: IDMLフォーマットは、人間ににとって判読可能であり、ページレイアウトに関する基礎知識をもっているユーザにたやすく理解されるべきです。InDesign要素（例えばスプレッドやテキストフレーム、ストーリー、カラーなど）の表現は、XML構造の中のドキュメントの見た目と同じ位置に見つけられます。例えば、グループの中のテキストフレームはグループ要素の中にあります、そしてそれはスプレッド要素の中です。
• プログラムのアセンブリと分解の容易さにおいて、IDMLはXMLが読み書きできるどんなプログラムやツールによっても制御できるように設計されています。（INXにくらべて）IDMLファイルは、InDesignオブジェクトモデルと同じ適用範囲を維持していれば、（外部ツールを使っていても）処理しやすいです。
• 丈夫さ: IDMLを読み解釈するためのInDesignメカニズムは、誤りに対して強く、致命的な結果を排除するでしょう。顧客と開発者が編集されたファイルにおける潜在的誤りを発見できるように、IDMLのためのRelax NGスキーマ定義が提供されるでしょう。妥当なファイルでさえ未知のオブジェクトを含められるので、エラーはデバッグのためにインタプリタプロセスの間にレポートされます。
• 後方互換性: ユーザは、バージョンXのために生成されたIDMLファイルを、バージョンX-1で開くことができるでしょう（X-1がIDMLをサポートするなら）。InDesign CS4はIDMLをサポートする最初のバージョンです。InDesign CS4は、InDesign CS3との互換性のためにINXフォーマットをサポートするでしょう。
• パフォーマンス: IDMLはInDesign CS4のINXと同等かそれ以上の性能を目指します。
• INXの改良: IDMLはINXより以下の利点があります（これは完全なリストではありません）：
  • フォーマットの詳細を公開します。
  • InDesignのインポート・エクスポート時に、リレーション、プロセッシング、制限などのあいまいなエレメントと属性を排除します。
  • 妥当性の検証にXMLスキーマ（Relax NG）を提供します。
  • テキストオブジェクト配置時に、テキスト内容を処理しません。

7　IDMLデザインアプローチ

IDMLのデザインゴールを認識するために、私たちは一連の設計理念を採用しました。私たちはここでその設計理念について議論するつもりです。

7.1　効率化のための個別な議題

InDesignのワークフローは分割されることがあります（多くの部品に分けて、作業を平行に進めるために）。例えば雑誌のワークフローでは、章、記事、見開き単位で、グラフィックアーティストかレイアウトスタッフに任されます。それぞれのストーリーは異なるライターや編集者に任されます。同じことが、IDMLドキュメントを組み立てる過程でも起こります。ストーリーはRSSフィードからテキストを移行するかもしれません。グラフィックスの情報はスプレッドシートのデータから生成されるかもしれません。

さらに、InDesignドキュメントには構成から出版に至るまで標準化されている多くのエンティティを含んでいます。例えばドキュメントの設定やスタイル類、フォント、カラーなどはすべての生産過程で共通かもしれません。これらの設定を個別のXMLファイルに保存して、IDMLパッケージに追加できます。

すべてのIDML部品をZIPアーカイブとしてまとめて、ひとつのInDesignドキュメントを表現します。このコンテナの中の「マスター」ファイルは、コンテナに含まれるコンポーネントファイルの関係を定義します。

7.2　InDesignとの互換性を最大化

IDMLはInDesignドキュメントのスクリプティングDOMビューを反映します。それはInDesignバイナリーファイルとの互換性・一貫性を最大にして、できるだけ正確にInDesignドキュメントを表すように設計されました。

IDMLファイルはドキュメントのプレビューやヒストリーを保有しません。IDMLの意図はXMLのドキュメントの外観と中身を表すことです。

InDesignバイナリ（ドキュメント）とIDMLの間で交互に変換できることが必要です。ほとんどの場合、InDesignバイナリとIDMLを変換しなければならないでしょう。それぞれの表現は片方に加えられた拡張を完全に運ぶべきです。

IDMLフォーマットとInDesignバイナリフォーマットの変換には多くの作業フローがあります。わたしたちですら想定外なバラエティに富んだ用法があります。いくつかの一般的なクラスのワークフローは、以下のものを含みます:

• IDMLドキュメントは、データベース情報やXMLツールによるフィードを使って構成できます。次にInDesignで開かれます。
• 使用テンプレートとしてInDesignドキュメントをIDMLにエクスポートできます。IDMLテンプレートは、XMLツールを使用して修正し、InDesignに変換できます。
• InDesignドキュメントをIDMLファイルにエクスポートして、InDesignの前バージョンで開いたり保存できます。

フォーマット間で変換するとき、バイナリ等価性を維持は必須ではありません。 ただ、視覚的に忠実である必要があるだけです。

7.3　XML Elementsからの独立

IDML中のXMLエレメントとして表されたInDesignオブジェクトは、可能ならば独立したものとして扱われます。例えば、長方形を追加し、変更し、削除するために、特定のファイルで長方形を操作しなければなりません。他のオブジェクトタイプはもう少し複雑でしょう。例えば、テキストフレームはテキストフレームに示されたテキストを含むストーリーの指示を含む必要があります。IDMLパッケージの中にすべてのテキストフォーマット属性を含む個別のストーリーが別々のファイルになります。

7.4　エレメントより属性を使用すべし

可能ならば、IDMLはほとんどのオブジェクトプロパティを格納するために、XMLエレメントではなく、XML属性を使用します。XML属性はコンパクトであり、XMLエレメントよりパフォーマンスに優れます（XML属性はそれらを含むエレメントの始まりと共にパースされます、子エレメントより先に）。

7.5　自己をドキュメント化（Self-Documenting）

IDMLの構造はできる限り自己ドキュメント化がなされるべきです。エレメントの親子関係はInDesignバイナリーのオブジェクトモデルにオブジェクト関係を反映する必要はありませんが、それらはInDesignのスクリプティングモデルを反映しています。

スクリプティングモデルでのオブジェクトとプロパティは、XMLエレメントと属性としてIDMLの中で表わされます。エレメントのタグ名と属性は、スクリプティングDOMに定義されたオブジェクトとプロパティを識別するための「ロングネーム」です。

7.6　InDesignデータ構造のリテラル表現ではない

IDMLはInDesignの内部データ構造を表わすようには意図されません。さらにInDesign SDKのために置き換えとしても意図されません。InDesign APIとバイナリーファイル形式は、今後も発展し続けるでしょう。そして、プラグイン開発者は既存のインタフェースを使用し続けるでしょう。スクリプティングDOMを使用することによって、IDMLはInDesign APIの変化や低レベルのファイルシステム変化などから無縁でいられます。

7.7　パフォーマンス

IDMLはパフォーマンスを念頭に設計されています。 IDMLの読み書きで、性能改良をもたらすデザイン決定があります:

• オブジェクト情報は読み書きを最適化するために整理されます。
• C++のコードレベルでは、IDMLコア処理コードと特定のスクリプトプロバイダーがより良いパフォーマンスのために調整されました。
• IDMLドキュメントはファンクションコンポーネントに分けられました（将来のバージョンでは、書き出し時にマルチタスクの恩恵を受けられるでしょう)。

7.8　旧バージョンのためのサポート

InDesignの旧バージョンでIDMLを開くのは可能になるはずです（たとえばInDesign CS4でInDesign CS5からのIDMLファイルを開く）。もちろん、IDMLはInDesign CS4で導入されてたので、InDesign CS4のIDMLがInDesign CS3（またはそれ以前の）では開くことはできません。代わりに、InDesign CS4はINXにエクスポートすることができるでしょう。(INXはInDesign CS3バージョンで開くことができるでしょう）。

（プラグイン構成によって）InDesign/ InCopyで非互換性が生じたバージョンを使ってIDMLを開くと、アプリケーションはエラーメッセージを表示するでしょう。ユーザはIDMLファイルを開くのを試みるのを選ぶことができます。

8　IDMLのドキュメント構造

あなたがIDMLとしてドキュメントをエクスポートすると、InDesignは複数のXMLファイルを含むZIPアーカイブを作成します。これらのファイルは、InDesignドキュメントの重要な部分を表現するためにIDMLマークアップを使用します。

個別のファイルで仕事ができるようにドキュメントを分割します。例えば、ドキュメント中のテキストがストーリーに含まれているように、不安定要素を除いたカラーやグラフィックスのように。この区画化で、自動化プロセスやドキュメント平行処理がより簡単になります。さらに、InDesignドキュメントの断片を保存して再使用するのがより簡単になります。

このアプローチは、IDMLを読み書きするとき、InDesignの将来のバージョンがマルチスレッドを利用できることを意味します。

8.1　IDMLパッケージファイル機構

InDesignからエクスポートされたIDMLドキュメントはZipアーカイブです。 ファイルフォーマットの、より詳細についてはAppendix Aの「Universal Container Format.」を参照してください。しかしながら、これはIDMLが取ることができる唯一の形ではありません。IDMLの単一ファイルバージョンはInDesign スニペット（.idms）とInCopyストーリー（.icml）で使用されます。いくつかのシチュエーションでは、単一XMLファイルでIDML形式の方がUCFパッケージを使用するより実用的であるかもしれません。

IDMLパッケージの中に保存されたXMLドキュメントは、特定の内容を見つけるのをより簡単にするようにアレンジされます。例えばスプレッドやストーリー、XML構造、設定などのファイルはフォルダーの中に分類されます。下図はIDMLアーカイブ内のXMLファイルの配置を示します。

図1　IDMLパッケージ内容

8.1.1　MIMETYPE

IMIME（Multipurpose Internet Mail Extensions）は、IDMLパッケージ中のファイルのontent typeを指定する標準的な方法を提供します。一般的なMIMEメディアタイプについての詳細はRFC 2045を参照してください。さらに、IDMLパッケージ中のファイルのMIMETYPEについては「付録A　UCFコンテナフォーマット（UCF Container Format）」を参照してください。

8.1.2　designmap.xml

「designmap.xml」ファイルはIDMLパッケージの中に現れる他のファイルのすべてのキーです。このファイルはドキュメントが展開した順序を指定します。ファイルのリソースと内容の相互参照を持ち、他のファイルによってサポートされなかったさまざまなドキュメントレベル属性を定義します。 「designmap.xml」ファイルの詳細については、「10.2　designmap.xml」を参照してください。

8.1.3　Master SpreadsフォルダとMasterSpreads.xml

MasterSpreads.xmlファイルは、<MasterSpread>エレメントとして保存されたドキュメントのマスタースプレッドを含んでいます。このファイル内の各<MasterSpread>エレメントは、マスタースプレッドに現われるページアイテム（長方形、楕円、線、多角形、グループ、ボタン、テキストフレームなど）をすべて含んでいます。「MasterSpreads.xml」ファイルの詳細については、「10.3　スプレッドとマスタースプレッド」を参照してください。

MasterSpreadファイルのネーミング規則については「8.2　IDMLコンポーネントの名前」の項を参照してください。

8.1.4　Resourcesフォルダ

IDMLパッケージの中のResourcesフォルダは、色やフォント、段落スタイルなどのように、他のファイルから汎用に使われるエレメントを含んでいます。さらに、ドキュメントのための設定の大部分はこのフォルダーに保存されます。 Resourcesフォルダは以下のファイルを含んでいます:

Graphic.xml

「Graphic.xml」ファイルは、ドキュメントのリンクやカラー、スウォッチ、グラデーション、混合インキ、混合インキグループ、濃淡、線種などを含んでいます。「Graphic.xml」ファイルの詳細については「10.6　グラフィック」の項を参照してください。

Fonts.xml

「Fonts.xml」ファイルは、ドキュメントで使われるフォントを含んでいます（合成フォントがあればそれを含みます）。「Fonts.xml」ファイルの詳細については「10.5　フォント」の項を参照してください。

Styles.xml

「Styles.xml」ファイルは、段落スタイルや文字スタイル、オブジェクトスタイル、セルスタイル、表スタイル、TOCなどのドキュメントで使用するすべてのスタイルを含んでいます。「Styles.xml」ファイルの詳細については「10.8　スタイル」の項を参照してください。

Preferences.xml

「Preferences.xml」ファイルはドキュメントのすべての設定を含みます。「Preferences.xml」ファイルの詳細については「10.7　プリファレンス]」の項を参照してください。

8.1.5　Spreadsフォルダ

Spreadsフォルダはドキュメントのスプレッドを表すXMLファイルを含んでいます。各スプレッドにはすべてのページアイテム（長方形、楕円、線、多角形、グループ、ボタン、テキストフレームなど）を含んでいます。<Spread>エレメントは （関係する属性やエレメントを含んだ）<Page>エレメントを含んでいます。ただし、<Page>エレメントにはページアイテムを含まないのを注意してください。

スプレッドにはテキストストリーム内容を含んでいません（Storiesフォルダのファイルの<Story>エレメントに<TextFrame>XMLエレメントの参照として含みました）。

スプレッドファイルのネーミング規則については「8.2　IDMLコンポーネントの名前」の項を参照してください。

8.1.6　Storiesフォルダ

StoriesフォルダはInDesignドキュメントのストーリのすべてを含んでいます。InDesignからエクスポートされたIDMLアーカイブのStoriesフォルダーのそれぞれのXMLファイルは、ひとつだけのストーリー（<Story>エレメントとして）のコンテンツとストーリーのテキストに適用されたフォーマット属性のすべてを表します。ストーリー中には、インラインやアンカーフレーム、テキストに関連するXMLエレメントなどのオブジェクトを含むことができます。

ストーリーのテキストをフォーマットする段落スタイルや文字スタイル、オブジェクトスタイルは<Story>エレメントの中で定義されません。 代わりに、ストーリーは対応するスタイルに、Resourcesフォルダに格納された「Styles.xml」ファイルに相互参照（一意のSelf属性を使用して）に含まれています。

ストーリーファイルのネーミング規則については「8.2　IDMLコンポーネントの名前」の項を参照してください。

8.1.7　XMLフォルダ

XMLフォルダはInDesignドキュメントのXMLのエレメントと設定を含んでいます。

ここで論ずるXMLエレメントは実際にInDesignドキュメントに現れるXML要素です。すなわち、あなたがInDesignユーザーインタフェースの構造化ウインドウで見るものです。XMLのいずれのコンテンツもIDMLアーカイブにファイルされません。 IDMLファイルはXMLで作られますが、それが記述するInDesignドキュメントは必ずしもXMLエレメントを含むというわけではありません。

BackingStory.xml

「BackingStory.xml」ファイルはInDesignドキュメントに配置されていないコンテンツ（エレメントがレイアウト上にマップしていないコンテンツ）を含んでいます。

Tags.xml

「Tags.xml」ファイルは未使用のタグを含むInDesignドキュメントに保存されたXMLタグ定義を含んでいます。

Mapping.xml

「Mapping.xml」ファイルはInDesignドキュメントで定義された「スタイルをタグにマップ」「タグをスタイルにマップ」のマッピングスタイルを含んでいます。

8.1.8　META-INFフォルダ

「container.xml」ファイルは、UCFパッケージの標準部品であり、パッケージ中にファイルによって使用されるファイルエンコーディングについて説明します。また、container.xmlはIDMLパッケージ（通常、designmap.xml）のルートドキュメントの参照を含んでいます。

8.2　IDMLコンポーネントの名前

スプレッドやストーリー、またはマスタースプレッドのためにIDMLコンポーネント名を定義できます。IDMLパッケージの中では、これらのエレメントの各インスタンスは別々のファイルとして現れます。コンポーネントの名前はオブジェクトインスタンスのためにファイル名として使用されます。さらに、それはdesignmap.xmlの中でファイルを参照するために使用されます。コンポーネント名がエレメントのself属性の値を変えないことに注意してください。

8.2.1　デフォルト名

InDesignドキュメント中のオブジェクトがユーザ定義されたコンポーネント名を持っていない場合、デフォルト名が使用されます。デフォルト名は、スクリプトオブジェクトタイプにオブジェクトのUID（InDesignの内部値）を追加して生成されます。例えば、UID 0x1c8を持つストーリーのデフォルト名は「Story_uic8」です。

8.2.2　ユーザー定義名

ユーザ定義された名前は以下の要件をすべて通過しなければなりません:

• IDMLパッケージ内で一意であること。
• 同じタイプのエレメントのために、どんな既存の名前とも衝突してはいけません。
• デフォルト名と衝突してはいけません。 デフォルト名との衝突を避けるために、以下のパターンの名前は有効ではありません: スクリプトオブジェクト名で始まり、「_」が続き、さらに1つ以上の16進数があるもの。たとえば、「Story_u123」は有効ではありません（デフォルト名パターンと一致するので）。しかし、「Story123」「Story_123」、「Story_u123_Transformed」はすべて有効なユーザ定義のコンポーネント名です。
• 妥当なファイル名であること（ファイル名として無効な文字を含んだり、予約語を含んだりしないこと）

8.2.3　インポート時にコンポーネント名をリセットする

IDMLパッケージがInDesignによって開けられるとき、ユーザ定義のコンポーネント名がドキュメントに保存されるので、ドキュメントをエクスポート時にそれらを使用できます。

デフォルト名はドキュメントで保存されません。インポート中に作成されたオブジェクトが異なるUIDを持っているかもしれないので。ドキュメントがエクスポートされるとき、新しいデフォルト名が生成されます。

8.2.4　スクリプティングインターフェイス

スプレッド、ストーリー、マスタースプレッド、各オブジェクトのIDMLComponentNameプロパティを通じてコンポーネント名にアクセスできます。

8.2.5　C++API

InDesignのC++APIを使うと、コンポーネント名を追加できます。詳細については「InDesign SDK Programming Guide」を参照してください。

9　IDMLの文法

このセクションはIDML構文の概要を提供します。まず、IDMLで使用されるコンベンション（しきたり）とデータ型、次に、InDesignオブジェクトとプロパティを表す方法の詳細に移行します。

9.1　XMLコンベンションとスタイル

ここでは、私たちがIDMLのために採用した多くのコンベンションについて説明します。

9.1.1　IDML中の名前

IDMLファイルのXMLエレメントと属性はInDesignスクリプト用のオブジェクトモデルに対応するオブジェクトの「長い名前」を使用します。例えば、スクリプティングにおけるRectangleオブジェクトはIDMLの<Rectangle>エレメントになります。StrokeWeightのプロパティはStrokeWeight属性になります（以下のように<Rectangle>エレメントの中で）:

Note: IDMLのテキストオブジェクトを表すエレメントが、スクリプト用のオブジェクトモデルで使用されるテキストオブジェクトと異なっていることに注意してください。一般に、IDMLのCharacterStyleRangeエレメントはスクリプト用のオブジェクトモデルでTextStyleRangeオブジェクトに対応しています。両方とも同一フォーマットの連続を表し、同じような値（スクリプティングにおけるプロパティと、IDMLの属性）を持ちます。

9.1.2　空要素の使用

可能であればいつも、IDMLはオブジェクトかプロパティを表すのに空要素を使用します。 例えば、<Page>エレメント中の<MarginPreference>エレメントはこんな感じになります:

Note: IDMLのテキストオブジェクトを表すエレメントが、スクリプト用のオブジェクトモデルで使用されるテキストオブジェクトと異なっていることに注意してください。一般に、IDMLのCharacterStyleRangeエレメントはスクリプト用のオブジェクトモデルでTextStyleRangeオブジェクトに対応しています。両方とも同一フォーマットの連続を表し、同じような値（スクリプティングにおけるプロパティと、IDMLの属性）を持ちます。

9.2　IDMLスキーマの生成

Relax NG Compact Syntax（Relax NG短縮構文）のように、完全なIDMLスキーマを書けます。以下のスクリプトを使って、スキーマファイルを生成できます。

2つめのパラメータにfalseをセットしてIDMLスキーマを生成した場合、２つのファイルにすべてのスキーマ要素が含まれます。IDMarkupLanguage.rncとdatatype.rnc（後者のファイルは前者の参照を含む）。もし、IDMLパッケージ中の特定のタイプファイル（例えば、Story_nnn.xmlファイル）のスキーマ要素を見るだけならば、IDMLパッケージに含まれる各XMLファイル（MasterSpreads.xml、Spread.xml、Text.xmlなど）に対応する個別のスキーマを生成します。以下のようにして、スクリプトを実行してみてください。

あなたが指定した出力フォルダに以下のスキーマファイルを含むでしょう（IDMLパッケージと同じフォルダ構成）:

Note: datatype.rncファイルの内容がスキーマを生成するメソッドと同じであることに注意してください。

9.3 IDMLのデータ型

IDMLデータ型はdatatype.rncというRelax NG Compact Syntaxファイルで宣言されています（それはすべてのスキーマファイルに含まれます）。このスキーマは、スクリプト用のオブジェクトモデルにオブジェクトとプロパティを加えるInDesignプラグインで拡張できます。InDesignは新しいバージョンのスキーマをいつでも生成できます。ファイルの生成についての詳細は「9.2　IDMLスキーマの生成」の項を参照してください。

次の表に基本型のリストを示します。最初のコラムはスクリプトデータ型をリストアップします、第2コラムはRelax NGスキーマに使用する対応型名です、第3コラムはIDMLファイルに現れるタイプ属性の値です（Note: タイプ属性が<Properties>エレメントの子要素にだけ現れることに注意）：

表1　IDMLの基本データ型

スクリプトデータ型	スキーマデータ型	IDML中のタイプ属性の値
boolean	xsd:boolean	boolean
string	xsd:string	string
short integer	xsd:short	short
long integer	xsd:int	long
longlong integer	xsd:int	longlong
double	xsd:double	double
object	xsd:string	object
object list	xsd:string	スペース区切りの文字列である、文字列のリスト
list	xsd:string	スペース区切りの文字列である、単純なタイプのリスト
date	xsd:date	date
file	xsd:string	file
enumeration	xsd:string	datatype.rncの中で指定された列挙定義に依存します。
unit	xsd:double	unit または double
record	text	record
stream	text	binary

9.3.1　スカラーデータ型 vs. 複合データ型

スカラ型は単一の値を持つ基本型です。 それは他のすべてのデータ型を構成するブロックです。

複合型は基本型のコンビネーションで構成されます。リストとレコードはスクリプト用のオブジェクトモデルに存在する複合型に関する2つの例です。

• リストは要素の同列コレクションです。それはプログラミング言語の配列と同様です。リストはリストの長さを識別する属性を含んでいます。
• レコードは要素の異種コレクションです。レコードは他のレコードを含んでいるかもしれません。また、レコードはリストの中に含まれるかもしれません。

9.3.2　Enumeration

InDesignスクリプティングは、プロパティ値のスコープを定義するために使用Enumerationを作成します。例えば、ストーリーでは「Regulartext」「Toctext」「Indexingtext」となります。InDesignのエクスポートでは、Enumerationの値の表し方を決定するためのルールとして以下を使用します：

• プロパティの値が常にEnumerationである時、エレメントの属性は「string」データ型で得られます。
• もしプロパティの値がいくつかの異なった型になれる時、プロパティは<Properties>エレメントの子要素として取り出せます（enumerationの属性型で）。例えば、<DocumentPreference>エレメントの次のセグメントは、コラムとマージンガイド色が「緑色」であることを示します。

IDMLスキーマ例：（designmap.rncからoff-topic属性を削除した）

スキーマ例1　ColumnGuideColorとMarginGuideColorエレメント

IDMLパッケージからの例（off-topic属性を削除）

IDML例1　プロパティは属性かエレメントの値に依存

上記の例では、<ColumnGuideColor>か<MarginGuideColor>の値は、InDesign UIColorType Enumeration（datatype.rncファイル中で定義）かRGBカラーのどちらかです（3つのdoubleの配列として定義）。値はsingle以上になりうるし、シンプルな型だから、属性よりもエレメントとして表現されます。カラーが<ColumnGuideColor>エレメントのようにEnumerationである時、Enumerationの名前はエレメントの値として現れます。カラーがRGBの配列である場合、<MarginGuideColor>エレメントの子要素によって示され、エレメントのシリーズで表現します。

9.3.3　キー文字列

IDMLの多くのエレメントと属性は、名前（例えば、デフォルトカラーとかスタイル）またはInDesignユーザーインタフェースに表示された文字で、InDesignドキュメントの各種設定方法を参照します。この文字列はアプリケーションのロケール（または言語）として変化できます。

IDMLはこれらの値に「キー文字列」と非翻訳された文字列を使用できます。キー文字列はローカライズ（翻訳）された文字列を調べるために使用されます。翻訳されていない文字列は検査なしで「そのままで」使用されます。これらの文字列使用は両方とも「string」スクリプトデータ型として表されます。

4文字の接頭辞「$ID/」が付いている文字列がキー文字列であり、InDesignがIDMLインポートプロセスの間に適切なローカライズ文字列を調べるであることを示します。例えば、以下の簡略化された<IndexOptions>エレメントでは、「Title」属性の値はキー文字列です。

上記の例では、キー文字列の使用は、InDesignがIDMLドキュメントをインポートするプロセスの間にローカライズ文字列を調べることを意味します。ドキュメントが開かれると、現在のアプリケーションでの正確な文字列はユーザーインターフェイスの適切なエリアで表示されるでしょう。また、対応する値（オブジェクトまたは設定）にプロパティが適用されるでしょう。もし、属性の値が単純な用語「Index」だったならば、InDesignのロケールに関わらずその文字列を表示し、その名前のオブジェクトか設定を適用しようと試みます。

InDesignがキー文字列の交換文字列を見つけられなければ、キー文字列はそのままで使用されるでしょう。

以下の例はキー文字列がエレメントに現れるとき使用される構文を示しています:

9.3.4　単位

InDesignからエクスポートされたIDMLの単位は、常にポイントです（1/72インチ）。

9.4　オブジェクトの表現

InDesignオブジェクト(例えば、スプレッド、カラー、テキストフレームなど）はIDMLのXMLエレメントによって表されます。各オブジェクトは、子要素または属性として示すことができるプロパティを持っています。

一般に、InDesignドキュメントのオブジェクトは以下の形式（簡略）でIDML XMLエレメントとして記述されています:

IDML例2　オブジェクトのシリアライズ

「Object」はInDesignのオブジェクトタイプの名前、「SimpleProperty」はXML属性となりうるプロパティ、「Self」はオブジェクトの一意の識別子、「Value」はプロパティの値、「ComplexProperty」はXMLエレメントとして示さなければならないプロパティ（9.5　プロパティの表現参照）、「ChildObject」はオブジェクトに含まれるオブジェクト（例えば、ブループ内のオブジェクト）です。 <ChildObject>エレメントの内容は<Object>エレメントと同じパターンが続きます。

<Properties>と<ChildObject>セクションはオプションであり連続しているオブジェクトに依存します。両方が空の場合、オブジェクトは単純化された形式として書くことができます:

9.5　プロパティの表現

プロパティは属性か子要素のどちらかで表現できます。一般的に、単純な値は属性として、より複雑な値はエレメントとして表わされます。

9.5.1　属性としてのプロパティ表現

以下の条件のどれかを満たすと、オブジェクトのプロパティはXML属性として表現されるでしょう:

• プロパティはシンプルなスクリプトタイプ（すなわち、StreamTypeでない、VariableType、RecordType、「9.5.2　エレメントとしてのプロパティ表現」を参照）として定義され、プロパティの名前は「Contents」ではありません。なぜならば、Contentsプロパティが非常に長い文字列であるかもしれないし、ラインを終了する文字を含んでいるかもしれないので、XMLエレメントとして表わされることは適切ではないので。
• プロパティの値は１次元配列であり、それぞれの値はシンプルなデータ型です。配列のすべての値が同じデータ型である必要はありません。
• プロパティの有効な値のすべてが、オブジェクトかEnumerationのどちらかです。

スクリプト用のプロパティの名前は、一般的にXML属性のキーとして使用されます。その値は単一の値、またはスペース区切りのリストになります。たとえば：

Note: プロパティの値がスペースを含んでいる場合、「%20」とエンコードされます。

9.5.2　エレメントとしてのプロパティ表現

与えられたプロパティが属性として書かれているために、上で説明した規則を満たさないと、含んでいるオブジェクトを表しながら、XML要素の<Properties>子要素で言い表されるでしょう。スクリプト用のプロパティの名前はエレメントの名前として使用されます、そして、プロパティの値はエレメントの内容としてシリアライズされます。一般に、値のデータ型はエレメントの「type」属性で指定されるでしょう。

プロパティはエレメントの2つの基本的なフォームで示されます: 「単一の値」と「リスト値」として。

表2　エレメントのプロパティ

単一の値：

リスト値：

上の例では、UIColors_EnumValueのEnumerationかカスタムRGBカラーのいずれかなので、InDesignガイドのガイドカラーのプロパティがエレメントとして示されています。

スクリプト用のオブジェクトモデルはIDMLのエレメントとしていつも表される2つのデータ型を含みます: 「RecordType」と「Geometry」。 さらに、VariableType タイプのいくつかのプロパティがエレメントとしてIDMLに書かれています。 以下のセクションはこれらのタイプについて論じます。

RecordType

データ型（スクリプト用のオブジェクト・モデルの）がRecordTypeであるプロパティは<Properties>エレメントにおける一連の子要素としてXMLに連載されます。以下の例に示します（TabListはプロパティの名前、Alignment、AlignmentCharacter、Leader、およびPositionがプロパティのレコードのアイテムです）:

IDML例3　RecordTypeのシリアライズ

Geometry

ページアイテムgeometry（ページアイテムの形状）は<PathGeometry>エレメントとして表されます。 この要素は順番に1つ以上の<GeometryPathType>エレメントを含んでいます。それはそれぞれ順番に2つ以上の<PathPoint>エレメントを含みます。

<PathGeometry>エレメントは次の形式を持っています:

IDML例4　Geometryシリアライズ

IDMLのGeometryの詳細は「10.3　スプレッドとマスタースプレッド」を参照してください。

VariableType

StreamTypeデータ型または名前が「Contents」であるスクリプト用のオブジェクトモデルのプロパティは、XMLエレメントとして表されます。

Complex Structures

プロパティのスクリプト用のオブジェクトモデルデータ型が私たちが議論した構造より複雑であるなら、それはエレメントのリストとしてシリアライズされます。<Descriptor>エレメント（<Page>エレメント中）は1つ以上の任意のタイプのエレメントを含んでいる配列です。以下の例に示すように一連のプロパティのエレメントを含むエレメントとしてシリアライズします:

一般に、<ListItem>エレメントのようにシリアライズされた特性は、InCopyとのやりとりに使用され、読み出し専用と見なすことができます。あなたがこれらのエレメントを構築する必要はおそらくないでしょう。

9.5.3　プロパティエレメントの属性タイプを使う

<Properties>エレメントがオブジェクトのプロパティを表すのに使用されるなら、各プロパティは<Properties>エレメントの子要素として表されます。それぞれの子要素で、セットされたプロパティのデータ型（「9.3　IDMLのデータ型」を見よ）が値のものだったら、type属性を含みます。 例えば:

上記の例では、値「LightBlue」は、「datatype.rnc」ファイルにあるUIColors Enumerationの定義から来ています。

9.5.4　オブジェクト参照フォーマット

スクリプト用のオブジェクトモデルのプロパティは、しばしばオブジェクトの参照を含んでいます。例えば、「Rectangle」の「FillColor」のプロパティは常に「Color」「Tint」「MixedInk」「Gradient」、または「Swatch」オブジェクトを参照するでしょう。IDMLは、属性を表すXMLエレメントかプロパティの値としてオブジェクト（ドキュメントのほかの場所に保存される）を表すXMLエレメントへの言及を含めることによって、この関係を表現します。オブジェクト参照はIDMLファイル内の最も一般的な相互参照フォーマットです。

XML要素にオブジェクトをシリアライズするとき、InDesignはエレメントのIDに一意な文字列を生成して、「Self」属性にそれを格納します。ID生成するのに使用されるアルゴリズムは、複雑でAdobe独自ですが、以下の規則に従います:

• オブジェクトが、名前によってそのメンバーを識別するクラスに属する場合、エレメントの「Self」属性の値が名前になるでしょう。名前が一意でない場合、InDesignはインポート時に接頭辞（かつ／または）接尾語を加えて固有のIDを生成します。
• オブジェクトが別のオブジェクトの子供であるなら、親オブジェクトの名前かIDが接頭語として「Self」属性の値に加えられるでしょう。パス構文と同様のパターンを使用して:

• オブジェクトに名前がないと、オブジェクトのIDプロパティの値は、エレメントの「Self」属性の値として使用されるでしょう。
• 複数のオブジェクトが同じタイプで存在している場合、インデックス数が接尾辞として「Self」属性に加えられるでしょう。
  「Self」属性の値の唯一の要件は、IDMLパッケージの中で一意であることです。IDMLを自分で書いているなら、あなたは上のパターンを観測する必要はありません--（IDMLパッケージ内でその値が）一意であり、エレメントのすべての参照の変更が一致する限り、「Self」属性の値を好きなように変更できます。

下記にXMLエレメントの値として表現された要素参照の例を示します。例では、<ParagraphStyle>エレメントの<BasedOn>エレメントは「Self」属性が値の「Heading」（段落スタイルの名前）を含む別の<ParagraphStyle>エレメントを参照します。この場合、段落スタイルはIDMLパッケージの中のResourcesフォルダーの中のStyles.htmlファイルで定義されます。

また、相互参照は属性の値として現れることができます。次の例では、<IndexOptions>エレメントの「TitleStyle」属性は「Self」属性が値の「IndexTitle」（段落スタイルの名前）を含む<ParagraphStyle>エレメントを参照します。この場合、段落スタイルはIDMLパッケージの中のResourcesフォルダーの中のStyles.htmlファイルで定義されます。

次の例はエレメントを参照するためにエレメントの「Self」属性を使用する相互参照を示しています。上に示されるように、値「ucb」は<Story>エレメントの一意な識別子です。

• IDMLファイルは前方への参照を含むことができます。（すなわち、IDMLファイルにまだ含まれていないオブジェクトの参照）
• 参照はIDMLパッケージ、あるいは単一のIDMLファイル内でのみ有効です。 1個のパッケージ（またはファイル）から別のものへの参照は許されていません。

9.5.5　ファイル相互参照例

以下の例は、designmap.xmlファイル中の<Document>エレメントが、ドキュメントを作る際のスプレッドをどう参照するかを示しています。

図2　相互参照：<Document>からスプレッドファイル

以下の例は、Spread.xmlファイル中の<TextFrame>エレメントの「ParentStory」属性が、テキストフレームのテキストがどのストーリーを参照するかを示しています。

図3　相互参照：<TextFrame>から<Story>

以下の例は、Story.xmlファイル中の<ParagraphStyleRange>エレメントの「AppliedParagraphStyle」属性が、どうテキストに適用された<ParagraphStyle>の「Self」属性をどのように参照するかを示しています。

図4　相互参照：<ParagraphStyleRange>から<ParagraphStyle>

上の例では、<ParagraphStyle>は<RootParagraphStyleGroup>の一部です。IDMLはファイルパス参照と同様の構文を使って、グループ内の段落スタイルを参照します。例えば、「ListStyles」という段落スタイルグループに「ListFirst」というスタイルがあるなら、スタイルの参照は下記のようになるでしょう：

この例で、「%30a」としてエンコードされたコロンは、パスセパレーター文字の役割をします。

以下の例は、<Rectangle>エレメントが外部のファイルをどのように参照できるかを示しています。リンクファイルはIDMLパッケージファイルの外に保存されます。IDMLファイルがInDesignで開かれるとき、ファイルを見つけることができないと、それはミッシングリンクとしてリストされるでしょう。

図5　相互参照：外部ファイルへの参照

以下の例は、外部のハイパーリンク場所をどのように参照するかを示します。

図6　相互参照：ハイパーリンクソースとハイパーリンク場所