アーキテクチャ仕様(第4章 DITAの処理)

4.1 IDと参照

DITA識別属性は、検索またはリンクのために内容を識別する機構を提供する。IDを参照する文法は、参照機構によらずに一定である。

id属性は、要素に固有の識別子を割り当てて、要素を参照可能にする。id属性の固有性の範囲はDITAアーキテクチャの中での要素の、次のような役割に依存する：

トピックのID

トピックはDITAの基本的な単位なので、トピックのid属性は、文書インスタンスの中で固有でなければならない。

トピックのアーキテクチャは、トピックを参照によって配布物に組み立てる。トピックを参照されうることを保証するためには、そのトピック要素にidが必須である。

トピックの完全な識別子は、文書インスタンスへのURI、分離用の#（ハッシュ文字）、トピックのidから（http://some.org/some/directory/topicfile.xml#topicidのように）構成される。URIについてはRFC2396に記述されている。URIでは典型的であるが、相対URIは、それが参照する文脈から解決可能な場合に限り、文書インスタンス識別子として使うことができる。例えば、ファイルシステムのディレクトリの中は、文書インスタンスのファイル名で（some/directory/topicfile.xml#topicidのように）十分である。同じ文書の中では、（#topicidのような）トピックのidのみで十分である。（topicfile.xmlにおけるように）トピックの要素が文書インスタンスのルート要素である場所では、文書インスタンスの外部の文脈は、そのトピック要素を参照するとき、トピックidを省略するかもしれない。（ditabase文書型のように）対象が、<dita>要素によって組織化された多数の同輩のトピックを含むとき、その参照は対象の最初のトピックになるように解決される。但し、（PDFを出力する間のように）topicrefsが包含の指示として解決されるときは除外される。この場合、特定のトピックが対象か否かに関わらず、すべての対象ファイルが含まれる。

トピックidは、トピックの内容への参照の一部として使用されるのと同様に、トピックへのtopicref、link、xref、そのトピックへのconrefを含む他の要素によって参照されることができる。

DITAトピックのid属性は、XMLのID型であり、文書インスタンスの内部で固有でなければならない。

トピックの中の要素ID

トピックの内容は常にトピックの中に含まれているので、あるトピック内容要素のid属性は、それを直接含むひとつのトピックの中でのみ固有でなければならない。このアプローチによって、文書インスタンス、トピック、内容が存在する限り、識別子が妥当になるので、内容への保守可能な参照を保証する。トピックの中での内容の位置と、文書インスタンスの中でのトピックの位置は、内容の識別子を無効にすることなく、変更できる。加えて、このアプローチによって、トピックを集積する時に、名前の衝突を避けるために、トピックの内容idを書き直す必要を避けることができる。

idはオプションであり、内容を参照可能にするためにのみ付加される必要がある。

トピックの内容のための完全な識別子は、（http://some.org/some/directory/topicfile.xml#topicid/contentidのように）トピックの完全な識別子と、分離用のスラッシュ（/）、トピックの内容idから構成される。以前に注意したように、トピックの識別子の部分は、（some/directory/topicfile.xml#topicid/contentidのように）相対URIが解決できるところでは、文脈の中における文書インスタンスのための相対URIを使用することができる。

要素idを参照するときは、それを含むトピックのidを必ず含まねばならない。そうでないと、他のトピックへの参照は、同じトピックの中でのひとつの要素への参照と区別することができない。同じ文書インスタンスの中での参照では、その文書インスタンスの識別子は、（#topicid/contentidのように）ともに省略可能である。

DITAトピックの中の要素のid属性は、ID型ではなく、文書の中で固有である必要はない。しかし、トピックの中で固有でなければならない。

マップのIDとマップの内部の要素ID

マップについては、要素のidは文書インスタンスの中で固有でなければならない。このアプローチは、これらの要素は、マップidで修飾することなく、マップの外側で参照されることができることを保証する。

アンカー要素、これはマップの中での参照のための対象位置を識別するためにのみ存在するものだが、についてはid属性は必須である。その他の要素についてはid属性はオプションである。

マップ要素の完全な識別子は、（http://some.org/some/directory/mapfile.xml#topicrefidのように）マップ文書インスタンスの絶対URIと要素idの組み合わせからなる。

マップとアンカーのid属性はID型であり、文書インスタンスの中で固有でなければならない。マップの中の他のid属性はID型ではなく、固有であることを要求されない。

4.2 ナビゲーションの振る舞い

次の振る舞いは、DITAトピックへ、またはその間のリーダのナビゲーションの作成をサポートする。

目次（TOC）

DITAのマップから生成される；複数のDITAマップから編成されることができる。生成される目次から、マップの一部を、toc属性を使って、除外することができる。

関連リンク

個別のトピックの中で編集されるか、マップから生成される。マップで生成したリンクは、リンク属性を使って制御されることができる。

索引付け

トピックの本体、トピックの前文、またはDITAマップで発生する索引エントリから生成される。

4.3 内容の包含（conref）

DITAのconref属性は、内容の断片を再利用する機構を提供する。conref属性は、他の要素への参照を蓄積し、参照している要素を、参照されている要素で置き換えるための処理がなされる。

内容参照を含む要素は、参照されている要素のための場所確保として働く。参照されている要素のための識別子は、絶対的であるか、それとも参照している要素の文脈の中で解決されなければならない。（識別子の詳細については、「IDと参照」を見よ。）

より形式的には、DITAのconref属性は、文章の埋め込み機構として考えることができる。その点では、conrefはXIncludeやHyTimeの値参照に類似している。しかし、置換する内容の進行中の妥当性を新しい文脈で保証するためのそれぞれの文脈における制約を比較すると、DITAはこれらの機構とは異なる。言い換えると、conrefの妥当性は、単純に置換時の現行の内容に適用されるのではなく、二つの文書型の制約によって与えられた可能な内容の範囲に適用される。妥当なconref処理器は、再利用されるまたは再利用する内容のどちらかの規則のもとでの可視化が妥当でなくなるかもしれないような、再利用関係の解決を許さない。

参照されている要素が、参照する要素と同じ型であり、また参照されているトピック・インスタンスの中における領域の一覧が、参照する文書の領域の一覧と同じ、または、部分集合ならば、参照されている要素の中の要素組は、場所を確保する要素の中で許されている要素組と同じか、あるいは、部分集合であることが保証される。より好ましいアプローチとしては、conrefを解決する処理器は、妥当な要素の専門化に耐えられるべきであり、また、内容断片中の要素を、参照する文脈のために必要なように一般化するべきである。

場所確保の置換は、文書を解析した後で、しかし、なんらかのスタイル付け、または、トピック全体に対する変換または表示関連の操作の前に発生する。

conrefの対象は、構築時または実行時の条件に基づいて置き換えられても良い。例えば、製品名やパスは、トピックが他の製品によって再利用されるときに変更になるので、トピックの内容から分離されることができる；再利用する製品は、conrefのための自分自身の対象を、自分自身の製品名やインストール・パスの解決を許すために置き換えることができる。

conrefの対象は、DITAのトピックかDITAのマップの内部（または、完全なトピックまたはマップへのポイント）でなければならない。（ただひとつの段落を含む文書のような）DITA内容の断片は、自分自身について、conref処理器がそれらへの参照の妥当性を決定できるだけの十分な内容をふくまない。

解決済みの要素属性の指定は、ソースと対象の要素の両方から次の優先順位で導かれる：

1. ソース要素に指定されている、″-dita-use-conref-target″値を指定する属性を除く、すべての属性
2. ターゲット要素に指定されている全ての属性。但し、次を除く：
   1. id属性
   2. （ソース要素に）指定された値が″-dita-use-conref-target″ではない、ソース要素に指定されているすべての属性
3. xml:lang属性は、「xml:lang属性」に記述されているように、特別な扱いを受ける。

解決した要素が、指定された値が″-dita-use-conref-target″である属性を包含するのは、そのターゲット要素が″-dita-use-conref-target″値を指定された属性をもち、ソース要素が、その属性に値を指定されていないか、または、″-dita-use-conref-target″値を指定された属性をもつ時のみである。最終的な解決済みの要素が、（すべてのconref鎖の完全な解決の後）″-dita-use-conref-target″値をとる属性をもつなら、その属性が指定されていないのと同等として扱われるべきである。

解決済みの要素の与えられた属性は、ソースまたはターゲットから完全に来る：ある属性に対するターゲットとソースの属性値は、仮に特性が（聴衆のリストのように）値のリストを取るとしても、決して加法的ではない。

もし、ターゲット要素がconref属性を指定されているならば、上の規則は、、ひとつのソース／ターゲットの組み合わせから解決される要素が、次のソース／ターゲットの組み合わせに参加する二つの要素のひとつになる、といったように再帰的に適用されなければならない。結果は、オリジナルの文脈で妥当な全ての要素を、もし仮にそれらが中間の文脈で妥当でないとしても、一般化することなく保持しなければならない。例えば、トピックAとトピックCがハイライトを許しており、トピックBがそうでないならば、トピックA->トピックB->トピックCの内容参照鎖は、参照される内容の任意のハイライト化要素を保持しなければならない。結果は、conrefの組が、ソース要素から始まって、再帰的に解決されるのと同じである。

4.4 条件付き処理（プロファイル化）

条件付処理は、プロファイル化としても知られているが、処理時点基準に基づく、情報のフィルタリングまたはフラグ化である。

DITAは、条件付処理を意味論的に有意なやり方で実装しようと試みている：オリジナルの著者にのみ意味がある、文書の中で、時間がたつにつれて一般的な目的の処理属性の中に、任意の値が累積していくことを許すよりも、内容の特定のメタデータ属性を使って、メタデータを編集することを推奨する。これらのメタデータ値は、フィルタリングのみに適切というよりも、むしろ、フィルタリング、フラグ化、検索、索引付けを含む任意の数の処理によって、影響力を与えられる。

条件付処理属性

トピックとtopicrefについては、聴衆、プラットフォーム、製品のメタデータを、トピックまたはtopicref要素の属性、またはトピックの前文またはtopicmeta要素の中の要素によって表すことができる。メタデータ要素はより表現力があるが、値の意味は同じであり、また、協調して用いることもできる：例えば、前文の要素は、トピックの聴衆を完全に定義することができる、そして、メタデータ要素は、内容の中でそれらの聴衆の一部にのみ当てはまる部分を識別するために用いられることができる。

audience（聴衆）

聴衆メタデータ要素の列挙された属性の値は、内容要素の聴衆属性の中で使われるときと同じ意味をもつ。例えば、″user″値は、トピックの聴衆要素のtype（型）属性の中で現れるにしても、内容要素の聴衆属性の中で現れるにしても、同し意味をもつ。この原則は、聴衆要素の型、job（仕事）、experience level（経験レベル）の属性についても当てはまる。

聴衆属性の値は、聴衆要素の中で、聴衆について、より完全な記述を参照するために用いても良い。聴衆属性の中で同じ聴衆を参照するときは、聴衆要素の中の聴衆の名前を用いること。

聴衆属性は、空白で区切った値のリストを取る。それは、任意の聴衆要素の名前の値に合致することもあるし、合致しないこともある。

platform（プラットフォーム）

プラットフォームは、OSであったり、ハードウエアであったり、あるいは他の環境であるかもしれない。この属性は、トピック・メタデータのプラットフォーム要素に同等である。

プラットフォーム属性は空白で区切った値のリストを取る。それは、前文のプラットフォーム要素の内容に合致することもあるし、合致しないこともある。

product

製品または部品の名前、バージョン、商標、または内部コードまたは番号。この属性は、トピック・メタデータのprodinfo要素に同等である。

製品属性は空白で区切った値のリストを取る。それは、前文のprodinfo要素の値に合致することもあるし、合致しないこともある。

rev

改訂レベルの識別子。例えば、段落が改訂1.1の間に変更されるか加えられたら、新しいrev属性は″1.1″という値を含むだろう。

otherprops

ないようについてのメタデータ修飾子のがらくた入れである。この属性は、トピック・メタデータのothermeta要素に同等である。

この属性は空白で区切った値のリストを取る。それは、前文のothermeta要素の値に合致することもあるし、合致しないこともある。

例えば、単純なotherprops値のリスト：<codeblock otherprops="java cpp">

この属性は、値のラベル付きグループを取ることもできる。しかし、その文法はDITA 1.1では廃止されて、属性の専門化になっている。レベル付きグループ文法は、一般化属性文法に類似しており、処理器のために混乱を起こすかもしれない。ラベル付きグループは、文字値、続いて開き括弧、続いてひとつ以上の空白で区切った値、続いて閉じ括弧からなる。単純な形式は、情報の組が、製品、プラットフォーム、および聴衆の基本的なメタデータに加えて、唯一の付加的なメタデータ軸を要求するときには十分である。完全な形式は、それがひとつ以上のメタデータ軸を許す、と言う点で属性の専門化に類似している。例えば、複雑なotherpropsの値のリスト：<codeblock otherprops="proglang(java cpp) commentformat(javadoc html)">

props

条件付き処理値のための一般的属性。DITA 1.1では、props属性は新しい条件付処理値を作成するように専門化されることができる。

メタデータ属性を使用する

各属性は、ゼロ以上の空白で区切られた文字値を取る。例えば、product属性をその要素が二つの特定の製品に適用されることを識別するために使うことができる。

<p audience="administrator">Set the configuration options:
<ul>
<li product="extendedprod">Set foo to bar</li>
<li product="basicprod extendedprod">Set your blink rate</li>
<li>Do some other stuff</li>
<li platform="Linux">Do a special thing for Linux</li>
</ul>
</p>

図3 ソース例

メタデータ属性を処理する

処理時において、（DITA言語仕様に記述されている）条件付処理プロファイルを使用して、除外したい値、フラグを付けたい値を指定することができる。例えば、基本的な製品を使いながら、混在する聴衆のための情報を制作する出版者は、管理者に適用される情報にフラグを付け、拡張された製品に適用される情報を除外することを選択できる。そしてその選択を条件付プロファイルを使って次のように表現できるだろう：

<prop att="audience" val="administrator" action="flag" >
<startflag>ADMIN</startflag>
</prop>
<prop att="product" val="extendedprod" action="exclude"/>

出力時には、この段落にはフラグが付けられる。そして最初のリスト項目は（これは、extendedprodに適用されるので）除外される、しかし、2番目のリスト項目（これは、extendedprodに適用されるが、同時にbasicprod、これは除外されない、にも適用される）は含まれる。

結果は次に示すようになるだろう：

フィルタ化のロジック

特定の要素を除外するかどうかを決定するとき、処理では各属性を、ついで、属性の組を評価しなければならない：

• 属性のすべての値が″exclude″に設定されていれば、その属性は″exclude″に評価される。
• 任意の属性が除外するに評価されれば、その要素は除外される。

例えば、段落が３つの製品にあてはまり、出版者がそれらの全てを除外することを選択したとき、処理ではその段落を除外しなければならない；もし、その段落があなたが除外しない聴衆やプラットフォームに適用されるとしても。しかし、もしその段落が除外されていない追加製品に適用されるならば、その内容は意図した出力に関連があり、保持されねばならない。

フラグ化のロジック

特定の要素をフラグ化するかどうか決定する時には、処理では各値を評価すべきである。その属性に、（例えば、audience=″ADMIN″）フラグ化されるとして設定された値が現れるならば、処理はフラグを追加しなければならない。ひとつの要素に複数のフラグが適用される時、複数のフラグが、典型的には遭遇する順番に、出力されねばならない。

4.5 処理をまとめる（Chunking）

内容は、編集の目的、内容配布のため、ナビゲーションのために、異なる方法でまとめる（分割または合併して新しい出力文書にする）ことができる。例えば、分離されたトピックの組として、最適に編集されたあるものが、ひとつのウエブ・ページとして配布される必要があるかもしれない。マップの著者は、出力処理の一部として、ひとつの文書を分離してトピックの部品にしたり、複数のトピックを組み立ててひとつの文書にしたりするためにチャンク属性を使うことができる。

使用例

チャンク属性の潜在的な使用のいくつかの例を挙げる：

ネストされたトピックの再利用

内容の提供者はトピックの組をひとつの文書として作成する。再利用者は、文書の中のネストしたトピックの中のただひとつだけを組み込むことを望む。その再利用では、DITAマップから、チャンク属性をつかってそのトピックが自分の文書中に制作されるべきことを示して、そのネストしたトピックを参照することができる。

トピックの組を単位として識別する

カリキュラムの開発者が、トピックの組から、それらのトピックの再利用に制限をつけずに、SCORM LMS（学習管理システム）のための教程を編成することを望む。LMSは、教程が参照されることができる単位として認識されるなら、学習者の教程を通じての進捗を保存し、回復することができる。カリキュラムの開発者は、SCORMのマニフェストを作成する前に、学習モジュールをユニットとして識別するために、チャンク属性を使ってDITAマップでトピックの集合を定義することができる。

処理まとめ属性の使用法

トピックの組が、マップを使って出力のために変換されるとき、マップの著者は、既定の処理まとめの振る舞いが適用されるものを乗り潰すために処理まとめ属性を使っても良い。処理まとめ属性は、多トピックの文書が多数の文書に分けられること、そして多数の個別のトピックがひとつの文書に結合されることを、マップの著者が要求することを許す。

処理まとめは必然的に、出力のある型に要求されるが他の型では支持されない、処理まとめされた出力に特有の出力変換である。処理まとめは、また、ある実装が、すべてではないがある処理まとめ方法を支持し、あるいは、この仕様で記述されている標準の方法に新しい実装特有の処理まとめ方法を追加する、という点で実装特有である。

処理まとめ属性の値は、ひとつ以上の空白で区切られたトークンから構成される：

by–topic

処理まとめ属性の値が、“by–topic”トークンを含むとき、現在のtopicref要素に対して、ターゲット・トピックとその子孫のそれぞれに対して、分離された出力処理まとめが作成されるという、処理のまとめ方針が設立される。その方針は、マップ要素に設定されているときを除いて、“by-topic”方針がマップ全体に設立されるとき、現在の要素（例えば、to-content）の処理まとめの振る舞いにのみ適用される。

by–document

処理まとめ属性の値が、“by–document”トークンを含むとき、現在のtopicref要素に対して、参照されている文書に対して、単一の出力処理まとめが作成されるという、処理まとめ方針が設立される。その方針は、マップ要素に設定されるときを除いて、“by-document”方針がマップ全体に設立されるとき、現在の要素（例えば、to-content）の処理まとめの振る舞いにのみ適用される。

select–topic

処理まとめ属性の値が、“select–topic”トークンを含むとき、個別のトピックが、同じ文書の中からの他（先祖、子孫、あるいは同輩）のあらゆるトピックなしに、選択される。その値は、それが指定されている要素がトピックを指さないときは、無視される。

select–document

処理まとめ属性の値が、“select–document”トークンを含むとき、参照されているトピックの内容が、同じ文書に含まれる他（先祖、子孫、あるいは同輩）のあらゆるトピックと共に選択される。その値は、それが指定されている要素がトピックを指さないときは、無視される。

select–branch

処理まとめ属性の値が、“select–branch”トークンを含むとき、個別のトピックとそれが含む任意のネストされたトピックが選択される。その値は、それが指定されている要素がトピックを指さないときは、無視される。

to–content

処理まとめ属性の値が、“to–content”トークンを含むとき、処理は新しい内容の処理まとめを生成する。マップ要素に指定されているとき、そのマップによって参照されているすべてのトピックを含む、ひとつの文書を生成する。

to–navigation

処理まとめ属性の値が、“to–navigation”トークンを含むとき、処理は新しいナビゲーション（目次、関連リンク）の処理まとめを生成する。マップ要素に指定されているとき、そのマップのすべての内容をもつ、ひとつのナビゲーションの処理まとめを生成する。

select-xxxxxトークン値の組は、多数のトピックを含む文書中でひとつのトピックを指し示すときのみ利用できることに注意せよ。

あるトークンまたはトークンの組み合わせは、かならずしもすべての出力型に適切でないかもしれない。出力処理の間に、支持されていない、または、矛盾するトークンに遭遇したとき、警告またはエラー・メッセージを出すべきである。このような矛盾または他のエラーからの回復は実装依存である。

処理まとめ属性には、既定値は存在しない。そして、処理まとめ属性は包含する要素から値を継承しない。マップ全体に対するby-xxx方針による既定値は、そのマップ要素に処理まとめ属性を設定することで設立することができる。

処理まとめ属性値がなにも与えられないとき、処理まとめの振る舞いは、実装依存であり、異なる実装で違っていても良い。この種の違いを望まないときは、マップ要素に処理まとめ属性値を含めることにより、マップ全体の既定値を設立できる。

処理まとめ処理により、新しい文書を作成するとき、もしあればcopyto属性から保存オブジェクト名または識別子（適切ならば）を取ることができる。そうでないときは、by-topic方針が有効なときはid属性から、もし、by-document方針が有効なときは参照されている文書の名前から、ルート名を取る。

例

idとしてP1, P2, ..., C1, C2, ..., GC1, GC2, ....、をもつトピックを含む、幾つかの単一のトピック文書、parent1.dita, parent2.dita, ..., child1.dita, child2.dita, ..., grandchild1.dita, grandchild2.dita、および、それぞれが二つのトピック、idとしてN1, N2, ...をもつ親のトピックとその親の中でネストされ、idとして、N1a, N2a, ...をもつ子供のトピック、という幾つかのネストしたトピック文書nested1.dita, nested2.dita, ...,、そして次の内容をもつditabase.ditaが与えられたとする：

<dita>
  <topic id="X"/>
  <topic id="Y">
    <topic id="Y1">
      <topic id="Y1a"/>
    </topic>
    <topic id="Y2"/>
  </topic>
  <topic id="Z">
    <topic id="Z1"/>
  </topic>
</dita>

map1.ditamap：

<map chunk="by-document">
  <topicref href="parent1.dita" chunk="to-content">
    <topicref href="ditabase.dita#Y1"
      chunk="select-topic"/>
  </topicref>
</map>

は、トピックP1にトピックY1を含むが、その中にネストするトピックY1aは含まない、ひとつの出力文書、parent1.xxxxを作成する。

map2.ditamap：

<map chunk="by-document"> <topicref href="parent1.dita" chunk="to-content"> <topicref href="ditabase.dita" chunk="select-branch"/> </topicref> </map>

は、トピックP1、トピックP1の中にネストするトピックY1、Y1の中にネストするトピックY1a、を含む、ひとつの出力文書、parent1.xxxxを作成する。

map3.ditamap：

<map chunk="by-topic">
  <topicref href="parent1.dita" chunk="to-content">
    <topicref href="ditabase.dita#Y1"
      chunk="select-document"/>
  </topicref>
</map>

は、トピックP1を含み、トピックX、Y、Zがそれらの子供とともにトピックP1の中にネストする、ひとつの出力文書P1.xxxxを作成する。

map4.ditamap：

<map chunk="by-document">
  <topicref href="parent1.dita" copyto="parentchunk">
    <topicref href="nested1.dita" chunk="select-branch"/>
  </topicref>
</map>

は、トピックP1と、P1の中にネストするトピックN1と、N1の中にネストするトピックN1aを含むparentchunk.xxxxという名前のついたひとつの出力文書を作成する。

map5.ditamap:

<map chunk="by-document">
  <topicref href="parent1.dita"
    chunk="to-content" copyto="parentchunk">
    <topicref href="child1.dita" chunk="select-branch"/>
    <topicref href="child2.dita"
      chunk="to-content select-branch"
      copyto="child2chunk">
      <topicref href="grandchild2.dita"/>
    </topicref>
    <topicref href="child3.dita">
      <topicref href="grandchild3.dita"
        chunk="select-branch"/>
    </topicref>
  </topicref>
</map>

はふたつの出力文書を作成する：parentchunk.xxxxの中にP1、C1、C3とCG3トピック。child2chunk.xxxの中にC2、CG2トピック。

map6.ditamap:

<map>
  <topicref href="nested1.dita#N1" copyto="nestedchunk"
    chunk="to-content select-topic"/>
</map>

は、単一の出力文書nestedchunk.xxxxを作成する。それは、中にネストするトピックをもたないN1トピックを含む。

map7.ditamap:

<map>
  <topichead navtitle="How to do lots of things"
    chunk="to-navigation">
     <topicref href="parent1.dita"
        navtitle="How to set up a web server">
      <topicref href="child1.dita"
        chunk="select-branch"/>
      ...
      </topicref>
     <topicref href="parent2.dita"
        navtitle="How to ensure database security">
      <topicref href="child2.dita"
        chunk="select-branch"/>
        ...
      </topicref>
    ...
  </topichead>
</map>

は、ふたつのナビゲーションの処理まとめを作成する。ひとつはP1、C1、...であり、2番目はP2、C2、...である。

上の例は、製品をひとつの単位として設定するためのハウツーを識別している。このハウツーは、ナビゲーション可能なHTMLページ、ルートのHTMLページに付随する印刷可能なPDFの両方で提供されても良い。

実装に特有のトークンと未来への考慮

DITA標準には、将来、もっと処理まとめトークンが追加されるかもしれない。また、同じように実装特有のトークンも定義されるかもしれない。実装間、または将来の標準への追加の間での名前の矛盾を避けるために、実装特有のトークンは、実装の名前または略称と、それに続けてコロン、つづけて処理まとめ方法の名前から構成される接頭辞から構成するべきである。例えば：“acme:level2”は、“level2”の処理まとめ方法を要求するAcme DITAツールキットのためのトークンになるだろう。

4.6 翻訳

DITAは、xml:lang属性、dir属性、そしてtranslate属性を含めて、内容を翻訳のために用意し、多言語の内容に働く特別な能力をもっている。

4.6.1 xml:lang属性

要素の内容の言語（オプションとしてロケール）を指定する。xml:langで宣言する意図は、その内容の中の他の要素に指定されたxml:langのインスタンスで乗り潰されない限り、それが指定された要素のすべての属性と内容に適用されると考えられる。xml:lang値が提供されていないときは、処理器は既定値を仮定するべきである。

この属性は、IETF RFC 4646 (http://www.ietf.org/ rfc/rfc4646.txt) またはその後継で定義される、言語指定子に設定されねばならない。

推奨利用法

単一の言語を含むDITA文書は、内容を含む最上位の要素には常にxml:lang属性を、文書に適用されるその言語（オプションとしてロケール）に指定するべきである。dita要素は、xml:lang要素をサポートしないので、xml:lang属性を設定すべき最上位要素はトピック要素（または同じレベルの派生）である。

二つ以上の言語を含むDITA文書では、最上位の要素には常にxml:lang属性を、文書に適用される首位言語（オプションとしてロケール）に指定するべきである。代替言語がその文書中で発生するときは常に、代替言語のテキストまたは構造を含む要素は、適切なxml:lang属性を設定するべきである。既定の文書言語を乗り潰す上の方法は、代替言語を使うブロックとインラインの要素の両方に適用される。

言語を識別するマークアップを使うことは、可能な限り文書を可搬にするために、強く推奨される。付け加えて、そのマークアップ文書は、人間に読まれたり理解されることができる。最後に、文書を更新するときに、各言語の境界が明確であり、それによって著者がその文書を更新するのがより容易になる。

アプリケーションは、すべての最上位レベルのトピック要素とルート・マップ要素に、明示的にxml:lang属性を割り当てることを保証するべきである。

マップにおける利用法

xml:lang属性はマップ要素に指定されることができる。マップの上における期待される言語の継承の振る舞いは、トピックの上におけるそれと類似である。それはすなわち、マップの首位言語をマップ要素（または、明示的に設定されていないならアプリケーションによって仮定される）に設定し、すべての子供の要素に、子供がxml:langに異なる値を指定していない限り、有効に保つということである。

topicrefの上のxml:lang値が、トピックのxml:lang値と一致しないならば、トピックの上の値が優先される。

conref属性における利用法

conrefをひとつのトピックの内容から他のトピックへ含めるために使用する場合、xml:lang値は、含まれているトピックから取得されねばならない。含まれている内容に明示的にxml:langが設定されていないならば、処理器は、含まれている内容の直近の親からxml:lang値を取得しなければならない。もし、含まれている内容が、xml:langを設定する親要素を持たないならば、そのアプリケーションは、xml:lang属性を設定していないトピックのために使われているのと同じ値を既定値とするべきである。

この振る舞いは次の例で示されている。そこでは、含まれているnoteのxml:lang値は、その先祖のxml:langを設定しているsection要素（id=″qqwwee″）から取得されている。この例では、idが″mynote″であるnoteに適用されるxml:lang値は″fr″である。

****************installingAcme.xml*********************
<?xml version="1.0"?>
<!DOCTYPE dita PUBLIC "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd">
<dita>
  <topic id="topic_3FD87D" xml:lang="en">
    <title>Installing Acme</title>
    <shortdesc>Step by step details on how to install Acme</shortdesc>
    <body>
      <p id="p_60A72">Welcome message goes here</p>
      <section id="section_C25">
        <title>Before you begin</title>
        <p id="p_E57324D">Special notes when installing Acme in
          France:</p>
        <note id="mynote" conref="warningsAcme.xml#topic_warnings/frenchwarnings"></note>
      </section>
    </body>
  </topic>
</dita>
*******************************************

****************warningsAcme.dita*********************
<?xml version="1.0"?>
<!DOCTYPE dita PUBLIC "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd">
<dita>
  <topic id="topic_warnings">
    <title>Warnings</title>
    <shortdesc>warnings in all languages</shortdesc>
    <body>
      <section id="qqwwee" xml:lang="fr">
        <title>French warnings</title>
        <p id="p_F2A">These are our French warnings.</p>
        <note id="frenchwarnings">Note in French!</note>
      </section>
      <section xml:lang="en" id="aassdd">
        <title>English warnings</title>
        <p id="p_5F961">These are our English warnings.</p>
        <note id="englishwarnings">Note in English!</note>
      </section>
    </body>
  </topic>
</dita>
*************************************

 4.6.2 dir属性

大部分の言語は、文字が左から右へ流れる文字でテキストが書かれるが、ヘブライ語と沢山のアラブ系の言語は右から左へ書かれる。ある言語では、ヘブライ語とアラビア語を含めて、番号や他の内容は左から右へ書かれる。また、例えば、英語とヘブライ語を含む多言語の文書は、あるテキストは左から右へ流れ、他のテキストは右から左へ流れる。

テキストの方向性は次のように制御される：

1. 明示的にルート要素に（dir属性を経由して）指定された、あるいは、設定されていないときは、処理アプリケーションによって仮定された方向性
2. ある要素に設定されている、継承された方向を乗り潰すdir=″ltr|rtl″属性。指定された方向は、要素の内容の中で、中立のUnicode文字（例．空白、句読点）のUnicodeの双方向アルゴリズムのみを乗り潰す。″ltr″ と″rtl″値は強い双方向性をもつ文字を乗り潰すことはない。
3. 要素のdir=″lro|rlo″属性。指定された方向は、その要素の内容の中のすべてのUnicode文字のUnicode双方向アルゴリズムを乗り潰す。

大部分の場合、著者はdir=″rtl|ltr″を、LTR要素の中のRTL句を取り巻く句読点が正しく可視化されることを保証するために用いる。強い型のUnicode文字（句読点、空白、数字を除く言語に適用される文字）の方向を乗り潰すためには、著者はdir=″lro|rlo″を使う必要があるだろう。dir属性とUnicodeアルゴリズムの使用法は、「テキストと表の方向を指定する：dir属性（http://www.w3.org/TR/html4/struct/dirlang.html#adef-dir）」という論文に明確に説明されている。参照されている論文には、dir=″rtl|ltr″の使用法に関するいくつかの例がある。

dir=″lro|rlo″の使用については例がないが、bdo要素（完全なUnicode双方向アルゴリズムを乗り潰す昔のW3Cの方法；今の好まれる方法は、dir属性に乗り潰す値を使う）を使っている例から類推可能である。

HTML 4.0の仕様から：

推奨される使用方法

Unicodeの双方向アルゴリズムは、さまざまな双方向性のレベルを、次のように提供する：

1. 方向性は、最も上位のレベルの要素（トピック、またはトピックから由来する同輩、ditamapのマップ）のdir属性を経由して明示的に指定されるか、処理アプリケーションに仮定される。トピックの最上位の要素またはマップのdocument要素にdir属性を指定することが推奨される。
2. LTRのテキストの繋がりの内側にRTLのテキストの繋がりを埋め込むときは、既定値の方向はしばしば正しくない結果をもたらす。特に、埋め込まれたテキストの繋がりが、埋め込まれたテキストの一方の終端に位置する句読点を含む場合。Unicodeでは、空白と句読点を中立の方向性をもつと定義しており、これらの中立の文字が強い方向性をもつ文字（空白または句読点でない大部分の文字）の間に現れたときの方向性を定義している。既定値の方向性で、しばしば言語の正しい方向性を決定するに十分であるが、たまに、それでは文字を不正確に（例えば、ヘブライ語の質問の最後の疑問符が、質問の最後ではなく最初に現れてしまうかもしれない）可視化してしまう。この振る舞いを制御するために、dir属性を必要に応じて、″ltr″または″rtl″に設定し、中立の方向性をもつ文字に望ましい方向が適用されることを保証する。″ltr|rtl″値は、すべてのUnicode文字ではなく、中立の文字のみを乗り潰す。
3. しばしば、強い双方向性をもつ文字の既定の方向性を乗り潰したいと希望するかもしれない。これは、Unicodeの双方向性アルゴリズムを乗り潰す″lro″ と″rlo″値を使ってなされる。これは本質的に要素の内容に方向を強制する。これらの乗り潰し属性は著者にUnicodeのBIDIアルゴリズムから独立に、方向性を設定する暴力的な力を与える。より優しい″ltr|rtl″値は、句読点とそのほかのいわゆる中立な文字のみに影響を与えると言う、より少ない過激な効果をもつ。

たいていの編集の必要には、″ltr″と″rtl″値で十分である。これらの値で望んだ効果が達成できないときのみ、乗り潰し値が使われるべきである。

Unicode標準は、マークアップを必要とすることなく方向性をマークするための隠しマーカを含んでいるが、これらのマーカを使うべきではない。文書を方向性を設定するためのdir属性を使ってマークアップすることを強く推奨する。Unicodeのマーカの代わりに、マークアップを使うことは次の利点がある：

• 文書ができる限り可搬になる。
• 文書をUnicodeのBIDIアルゴリズムを完全に実装していないアプリケーションで処理可能になる。
• マークアップした文書は人間が読んで理解することが可能である。
• 文書を更新するとき、各テキストの境界が明確であり、著者が文書を更新するのがより簡単になる。

実装の事前注意

ユーザは、記述的マークアップは必ずしも作業の終わりではないことに注意するべきである。考えられる各出力の可視化または表示ツールには、双方向テキストの管理のために異なる要求があるかもしれない。HTMLブラウザが異なると、CSSのサポートレベルが違うように、異なる出力ツールは、双方向アルゴリズムとそれに伴う方向制御を異なって実装をしている。例えば、HTMLをInternet Explorerで表示すると、FireFoxで表示したHTMLとは異なる要求をもっているかもしれない。同じように、HTMLファイルの、ページ本体のような、一部で働く制御は、他のところ、編成されたHTMLヘルプの表題や索引のような、では働かないかもしれない。大部分の出力で同じ不安定性が見出される。PostScriptまたはPDF可視化ツールは、双方向性を異なる取り扱いをする。Microsoft WordとOpenOffice Writerは、双方向のRTFを同じようには扱わない。Flashはいかなる双方向マークアップもほとんど関係ない、しかし、Unicodeのアルゴリズムに従って文字列を整形する。

入力はありうる出力に予想不可能に依存しているので、dir属性を、XMLがエディタで表示されるべきであるように適用するだけでは不十分である。ターゲットの形式とターゲットのツールの両方に関して、マークアップが確実に正しく変換される（あるいは、必要ならばソースのXMLに追加される）ようにさらに注意しなければならない。HTMLのケースを使うと、これは、最も共通のありそうなブラウザの機能に合わせた出力を生成すること、あるいは、最も機能の低いブラウザに合わせた出力を生成すること、そしてマークアップの機能を最もありそうで高機能のブラウザのために保証することを意味するであろう。例えば、Internet Explorerで完璧に表示される双方向HTMLはSafariでは正しく表示されないかもしれない。しかし、そのHTMLがSafariで完璧に表示されるならば、Internet Explorerでも正しく表示される可能性は十分である。しかしながら、これは確実ではない。それぞれのケースは資格のある個人によって試験し、確認されなければならない。

DITA文書を処理するアプリケーションは、編集、翻訳、出版、あるいは他の任意の段階にせよ、文書の中で使われる各言語のための書記法と方向性を正確に実装するためにUnicodeのアルゴリズムを完全にサポートするべきである。推奨する方法は、すべての方向性マーカーにXMLマークアップを使用して記述し、Unicodeの双方向性マーカーを使わないことである。Unicode双方向性マーカーを埋め込んだXMLマークアップを読むときは、これらのマーカーを、文書保存時にXMLマークアップに置き換えるべきである。

アプリケーションは、すべての最上位のトピック要素とルートのマップ要素に明示的にdir属性を割り当てるべきである。

4.6.3 翻訳属性をもつ全ての特性

ここにはすべての現在TCが承認した要素をモジュール毎に分けて含んでいる。ここには、通常、どれがブロックであり、どれが通常インライン要素であるかを記述しており、また、どの要素が、典型的に既定値で翻訳されるべきかを一覧にしている。

ブロックとインライン要素の間の違いは、究極的には要素を包含するものとそれに関連する処理によって制御されるので、同じ要素はある文脈ではブロックであり、他の文脈ではインラインになるかもしれない。文書型を指定することは、作成されている文書型の必要に従って、この振る舞いを変えるかもしれず、下記に与えられた方向性は、基本DITA文書型の既知の振る舞いのガイドとしてのみ与えられる。

下記の表についての注

• 専門化のためには、2つ目の欄が先祖の要素を与え、3番目の欄は、すべての振る舞いが継承されるかどうかを示す、すばやいyes/noのガイドを与える。もし、あるものが継承されないならば、変更は太字で現れる。
• 下記に一覧されない任意の専門化については、一覧された先祖の一番近いものにしかたなく頼ることになる。
• ブロック／インラインの表示欄は、要素が単一のブロックとして整形されるかどうかを示す。
• ブロック／インラインの翻訳欄は、その要素が完全な翻訳可能な区分を表すかどうかを示す。例えば、<cmd>は、他の要素と共にインラインで提示される、しかし、完全な翻訳区分を表す。
• ブロック***でマークされている項目はそれ自身のブロックであるが、区分の中央に現れるかもしれない。現在の区分の流れを妨げてはならない。翻訳では、″subflow″要素と考えられる。可能であれば、これらの要素は、翻訳を助けるために、文章の区切りにのみ配置されるべきであると勧告する。
• すべての要素について、翻訳属性は既定値の暗示的な翻訳設定を乗り潰す。そこで、表中の″yes″または ″no″の翻訳設定は、その要素が常に翻訳される、または、決して翻訳されない、ということを保証するものではない。
• 要素が翻訳属性をもっているならば、それらは最後の欄に一覧される。spectitleおよびspecentry属性は、脚注を付きで記述されていることに注意せよ。
• キーワード要素（キーワードの派生と同じように）は、文書の本体に現れるとき、インラインの、句と同じような要素である。また、topicmeta（マップについて）の中や、序文（トピックについて）に現れたりできる。<keywords>要素に現れるとき、各キーワードは、個別の区分を表し、より大きな区分の一部ではない；その位置で、キーワードは″subflow″要素の一部と考えられ得る。