| XML Top | XSL Formatter | AH Formatter V5 | Web Interface | Report Designer | XML エディタ | トップページ |
| DITA | システム製品総合案内 | PDF総合案内 | OEM総合情報 | リセラーページ | XML資料室 | English Site |
アーキテクチャ仕様(第5章 DITAの専門化) |
| 目次へ戻る |
専門化とは、既存の設計に基づいて、新しい設計が作成される過程であり、新しい種類の内容が既存の処理規則を使って処理される。
専門化は、主要なアーキテクチャと設定の中央での管理の必要性と、グループ特有また内容特有のガイドラインと振る舞いのための局所的な管理の必要性との調停の方法を提供する。専門化により、沢山の内容と出力が、型と変換の階層を通じて、共存することを可能とする。この階層により、一般的な変換が、新しく特殊な内容をどう取り扱うかを知り、また、専門化された変換に、一般的な変換からロジックを再利用させる。結果として、内容と変換が専門化に準拠し、そして同じ階層の一部である限り、任意の内容が任意の変換によって処理されることができる。専門化器は、専門的な解決策の利を受けるが、また、共通の標準と共有資源の利も得る。
| 内容 | 処理 | 結果 |
|---|---|---|
| 専門化されてない | 専門化されてない | 基本処理、期待した結果 |
| 専門化されてない | 専門化された | 基本処理、専門化された乗り潰しは無視される。期待した結果 |
| 専門化された | 専門化されてない | 基本処理、専門化された内容が一般的に取り扱われ、出力は期待を満たさないかもしれない |
| 専門化 | 専門化 | 専門化された処理、期待した結果 |
| 専門化 | 異なる専門化 | ある種の専門化処理、専門化された内容が最も近い共通の分母となり、出力は期待を満たさないものとなるかもしれない |
次のトピックは専門化の概要、ある種の利用の勧告、その機構の詳細の規則を提供する。
専門化は、既存の設計とコードを可能な限り再利用して、交換、移行、保守のコストを最小化または削除し、新しい種類の情報（新しい構造型または新しい情報の領域）を定義することを可能とする。
専門化は、新しい型や新しい領域が必要なときに使われる。DITAの専門化は一貫性と記述性をより増すために設計を変更したいと望むとき、または、現在のデータ・モデルでは処置できない、非常に特殊な出力の必要性に使うことができる。DITA文書は専門化に頼らなくても異なる出力に変換され得る（「カスタム化」を参照）ので、専門化は単に異なる出力型を生成するためのみなら推奨されない。
専門化の階層にはふたつある：ひとつは構造型（トピックとマップをルートにもつ）のためのものであり、もうひとつは領域（ルートがトピックまたはマップの中の要素、または、属性propまたはbase）のためのものである。構造型は、概念またはタスクまたは参照のような、しばしば主題の範囲（例えば、ユーザ・インターフェイスのタスクとプログラミングのタスクはともに手段（ステップ）のつながりから構成される）を超えて適用される、トピックまたはマップの型を定義する。領域は、プログラミング、またはハードウェアのような、特定の情報領域または主題範囲のためのマークアップを定義する。両方とも、各構造型または領域がその親の部分クラスであるという、オブジェクト指向の用語では、”である”階層を表す。例えば、タスクの専門化は依然としてタスクである；ユーザ・インターフェイス領域の専門化は依然としてユーザ・インターフェイス領域の一部である。
新しい意味（新しい、意味のある情報分類、新しい構造型または新しい領域の形式にのどちらか）を扱うときは、専門化を使用せよ。新しい意味は、専門化の階層の一部として符号化されることができ、それらをより一般的な等価体に変換して戻すことができ、また、専門化された内容が既存の変換で処理されることを保証する。
専門化は、新しい文書アーキテクチャの開発において劇的な効用をもつことができる。
効用の中には：
構造的専門化は、新しいトピック型や新しいマップ型のような構造化情報の新しい型を定義する。領域の専門化は、新しい種類のキーワード、表、リスト、条件付の処理属性のような新しい属性など、多数の構造型で使用できる新しいマークアップを定義する。
構造型は、概念、タスク、参照のように、主題の型（例えば、ユーザ・インターフェイスのタスクとプログラミングのタスクはともに段階のつながりから構成される）をまたがって適用される情報のモジュールのための型を定義する。新しい要素が、構造的専門化を通じて導入されるとき、新しい要素を含む要素も同じように専門化されねばならない；そして新しい包含要素は、今度は、そのモジュールのルート要素まで（例えば、<topic> 要素または <map>要素）ずっと、専門化されたコンテナをもたねばならない。
領域は典型的には、プログラミングまたはハードウェアのような、特定の領域または主題範囲のためのマークアップを定義する。領域要素は、その領域が、文書型の中で構造的専門化と統合されると、いつでもその祖先の要素が許されるときは常に利用可能になる。領域属性（propsまたはbaseに基づくもの）は、そのpropsとbase属性が許されるところではどこでも利用可能になる。
構造的専門化の階層も領域専門化の階層も、各構造型または領域がその親の部分クラスであるという、オブジェクト指向の用語で、“である”階層である。たとえば、タスクの専門化は依然としてタスクであり、プログラミング領域の専門化は依然としてプログラミングに関係する。
構造および領域の階層は、一緒に統合されるためには共通の基礎モジュールを共有しなければならない。例えば、トピック型をまたがって使う領域は、究極的には<topic>要素の中の要素と専門化できる属性から専門化されねばならない；トピック型とマップ型を通じて使われる領域は、両方の型に共通の要素または専門化可能な属性から専門化されねばならない。
共通の基礎モジュール（トピックとマップ）は別として、領域は構造型から専門化されることができない。例えば、<task>の中の要素から領域を専門化することはできず、<topic> または<map>のための構造モジュールからのみである。この規則は領域が統合化されることができ、文書型が予測できるように一般化されることができることを保証する。
専門化で作成される要素と属性は、それが宣言される構造化型と領域の名前によって有効範囲が決まる。構造型については、名前はルート要素と同じ名前である：例えば、タスクは、そのルート要素が<task>である構造型の名前である。領域については、名前はどの要素とも共有されない、しかし、専門化の開発者によって割り当てられる。慣例によって、領域の名前は″-d″で終わり、短く付けられる；例えば、ユーザ・インターフェイス領域はui-d、プログラミング領域はpr-d。属性領域は特別なケースであり、一般的には定義されている属性にそって、″-a″の付加して、名前がつけられる。
<foreign> または <unknown>要素の専門化は、DITAアーキテクチャに対するオープンな拡張であり、DITAの応用者が、新しいまたは、MathMLやSVGのような、非テキストのための既存の標準語彙を、インラインのオブジェクトとして統合することを可能とする。
DITAの応用者がDITAに外部の内容を統合することができる3つの方法がある。
<foreign> または <unknown>の専門化は通常領域として実装するべきであるが、内容をより制御したいと考えているものに対しては外部の語彙を構造の専門化の一部として実装することができる。
専門化されてない<foreign> または <unknown>要素の中に内容を埋め込むことは、ANY内容モデルの理由で、内容についてもっとも少ない制御を提供しており、相互運用性を妨げる。
DITAではクラス属性は特別な目的に使われている。それは、要素型と先祖の要素型のための専門化モジュールと、それらが属する専門化モジュールを識別する。すべてのDITA要素はクラス属性をもたねばならない。外部の語彙の中で定義されている要素は非DITA要素なので、それらの要素がアーキテクチャ的のクラス属性を持つ必要はない。<foreign> または <unknown>を専門化する要素は、従ってDITA要素であり、クラス属性をもつことが求められる。
DTDの専門化についてのより詳しい情報は、「DTDのモジュール化」を見よ。
<!-- declaration for the specialized wrapper -->
<!ENTITY % svg "svg">
<!-- included SVG document type -->
<!ENTITY % SVG.prefix "svg" >
<!ENTITY % svg-qname.mod
PUBLIC "-//W3C//ENTITIES SVG 1.1 Qualified Name//EN"
"svg-qname.mod" >
<!-- definition for the specialized wrapper -->
<!ELEMENT svg ((%SVG.svg.qname;)>
<!ATTLIST svg %global-atts;
class CDATA "+ topic/foreign svg-d/svg ">
<p>This is an ellipse.
<svg>
<svg:svg width="100%" height="100%" version="1.1"
xmlns="http://www.w3.org/2000/svg">
<ellipse cx="300" cy="150" rx="200" ry="80"
style="fill:rgb(200,100,50);
stroke:rgb(0,0,100);stroke-width:2"/>
</svg:svg>
</svg>.
</p>XMLスキーマの専門化についてのより詳しい情報は、「スキーマのモジュール化」を見よ。
<!-- importing MathML document type -->
<xs:import namespace="http://www.w3.org/1998/Math/MathML" schemaLocation="mathml2.xsd">
<!-- definition for the specialized wrapper -->
<xs:element name="mathML" type="mathML.class" />
<xs:complexType name="mathML.class">
<xs:choice>
<xs:element ref="mml:math" />
</xs:choice>
<xs:attribute name="outputclass" type="xs:string"/>
<xs:attributeGroup ref="univ-atts"/>
<xs:attributeGroup ref="global-atts"/>
<xs:attribute ref="class" default="+ topic/foreign mathML/mathML"/>
</xs:complexType>
<!-- definition for each element extended by the domain -->
<xs:group name="ma-d-foreign">
<xs:choice>
<xs:element ref="mathML" />
</xs:choice>
</xs:group>
<!-- definition for the named model groups -->
<xs:group name="foreign">
<xs:choice>
<xs:group ref="foreign"/>
<xs:group ref="ma-d-foreign"/>
</xs:choice>
</xs:group>MathMLを使う <object>要素をもつ専門化された<foreign> 要素の例
<p>... as in the formula
<object>
<desc>4 + x</desc>
<mathML>
<mml:math display="block">
<mml:mrow>
<mml:mo>∑</mml:mo>
<mml:mn>4</mml:mn>
<mml:mo>+</mml:mo>
<mml:mi>x</mml:mi>
</mml:mrow>
</mml:math>
</mathML>
<object>.
</p>
<data>要素は、単純な値から複雑な構造まで広がる特性を表す。処理は自動操作のため、または本体の流れと関連付けられたデータを整形するために<data>要素を収穫する。<data>要素は、主として、専門化を作るために使用することが意図されている。
<data>要素を構造のためにネストすることができる。<data>要素の、住所、回数、量、などの、インスタンスの意味を示すために、name属性を使うことができる。しかし、多くの場合、もっと精細な意味のため、また、構造や値の制約のために、<data>要素を専門化することを選ぶかもしれない。例えば、専門化は、値の属性を列挙することを指定できる。
あるケースでは、特性をその主題の内容の一部として維持するのは可能でなく、また便利でもない。例えば、本体の中の注か例に適用する拡張データを<prolog>に維持することを選好するかもしれない。このような例外を処理するために、<data-about>要素を、特性の主題を識別するために使うことができる。
処理過程では、データの値を、RDFのような機械で処理可能な表現として収穫することができる。既定値の整形では、<body>要素の中の<data>要素を無視する。特性が表示されるべきかどうか、どのように表示されるべきかを理解することで、カスタム化、または専門化した処理はある整形された出力にデータの値を含むように整形を拡張できる。
注意：
本体フローの一部であるテキストのための<data>要素を、特に、基本内容モデルの制約を回避するために、専門化するのはDITAのアーキテクチャの濫用である。例えば、特別な種類の段落は、<data>要素よりも、むしろ、基本の<p>を専門化しなければならない。内容を他と交換したり、専門化を止めるとき、<data>要素から専門化した段落は、一般化されるであろう。そして、その結果、基本の整形によってスキップされ、講話の流れを台無しにし、その結果、妥当でない内容に帰結する。
<data>要素の利用には次の項目を含む：
次の例は、自動化したプロセスが、コードの断片を再書き込みできるようにする、コードの断片のための区切られたソースコードを定義している。<fragmentSource>, <sourceFile>, <startDelimiter>および<endDelimiter>要素は、<data>から専門化されているが<codeFragment>は、<codeblock>から専門化されている。これらの特性は、整形した出力には（恐らくは、再書き込みにおけるデバッグの問題を除いて）現れない。
<example>
<title>An important coding technique</title>
<codeFragment>
<fragmentSource>
<sourceFile value="helloWorld.java"/>
<startDelimiter value="FRAGMENT_START_1"/>
<endDelimiter value="FRAGMENT_END_1"/>
</fragmentSource>
...
</codeFragment>
</example>
次の例は、家の記述の一部としての不動産の特性を識別する。<realEstateProperty> 要素とそれが含むすべては、<data>から専門化される。<houseDescription> 要素は、<section>から専門化される。専門化したプロセスでは、ちらしのために適切であれば、その用地を識別するための値を整形することができる。
<houseDescription>
<title>A great home for sale</title>
<realEstateProperty>
<realEstateBlock value="B7"/>
<realEstateLot value="4003"/>
...
</realEstateProperty>
<p>This elegant....</p>
<object data="B7_4003_tour360Degrees.swf"/>
</houseDescription>
既存の型の意味や専門化過程の制限に基づいて、新しい構造や領域の型が、既存の階層にぴったり合わないように見えるときがある。これらのケースでは、考慮すべきさまざまな選択肢がある。
非DITA文書型でも、DITAの文書型で使われる基本的な専門化の機構を、DITA文書型から得ることができるのと同じ、再利用、専門化、相互運用の利点を提供するために用いることができる。しかし、新しい文書型が適用できる特定の領域に制限される。DITAで定義した型を使っているとしても、専門化を通じてではないような方法で基本型に変更をすれば、DITAの文書型とは何の意味も規範的な関係ももたない新しい文書型を定義し、それは、いかなる意味でもDITA準拠のアプリケーションとは考えられないことに注意せよ。言い換えると、DITAの専門化を非DITAの基本型から利用しても、DITA準拠の文書型を生み出さない。
しかしながら、（共通形式への一般化の能力、標準に準拠するツールと処理、DITAマップとconrefを通じての文書を跨っての内容の再利用を含めて）共通のDITA基本クラスからの建設の実質的な利点が与えられるとして、DITA内容のアーキテクチャから完全に離れる前に考えるべき幾つかの技巧がある。
最初の選択肢は、利用可能な組の中から、より一般的な要素と属性を選択することである。DITAには、完全に一般的なトピックから個別の一般的キーワードに至るまで、それぞれの詳細レベルにおいて、利用可能な一般的要素があり、そして、一般的な属性のベースが属性領域の専門化のために利用可能である。
例えば、新しい種類のリストを生成したいが、<ul>, <ol>, <sl>または<dl>からの専門化では有用にできないならば、ネストした<ph>要素を専門化して、新しいリスト要素の組を生成することができる。この新しいリスト構造は、他のリストとは家柄によって意味的に結合されていない、そして、適切な出力のスタイル化を受けるためには専門化処理を要求する。しかし、それはDITAの妥当な専門化であり、一般化、内容参照、条件付き処理などの標準がサポートされる。
<topic>における次の基本要素は、一般的であり、ほとんど任意の構造的に妥当な専門化をサポートする：
トピックの次の属性は、文書型を通じて必要とされる新しい属性を提供するための領域の専門化に適切である：
いつでも可能な限り、意味的に最も近い相手から専門化するべきである。なんらかの構造的な要求から、より一般的な先祖から選択しなければならなくなったら、技術委員会に連絡してください：時間の経過につれて、より豊富な一般的な要素の組が利用可能になるはずである。
DITAのマークアップは、編集のグループが必要とするマークアップの部分集合を、新しい文書型シェルを作成することで、簡単に選択することができるように、領域と構造の型に組織化されている。しかしながら、編集グループが、（例えば、ある属性または要素を広域に除去する）型モジュールの境界に従わないようなマークアップ規則の部分集合を要求するときは、必要であれば、編集時にそれらの規則を強制するためにカスタム化した文書型を、その文書型が処理時点で標準に準拠した文書型を使って妥当性検証される限り、生成できる。
カスタム化した部分文書型は、型モジュールを編集することなく生成されるべきである。文書型シェルは、モジュール・ファイルをインポートする前に、実体の新しい定義を提供することにより、モジュール・ファイルの中の実体を、属性と内容モデルを含めて乗り潰すことができる。
カスタム化された部分文書型は、DITA標準に準拠しておらず、標準準拠のツールではサポートされないかもしれない。例えば、<xref>要素を削除するために文書型をカスタマイズするならば、内容を生成するために、出来合いのDITA編集器を使えないかもしれない。
専門化は文書型を様々に異なる編集目的に適合するために用いられるが、専門化によってでは満足させることができないある種の編集への要求がある、特に、属性の分割や名前の付け直し、そのコンテナを専門化させることなく、専門化を通じての要素の名前の付け直しなど。
要素または属性の構造と領域の専門化が十分でないところ、並びに新しい文書型が直接にまたは信頼をもって標準の文書型に変換することができるところでは、出版のパイプラインの一部として、標準の文書型に変換されるカスタム化した文書型が編集グループに最もうまく奉仕できる。例えば、編集グループが<p> 要素を <paragraph>として綴ることを要求するならば、文書型をカスタマイズして<p> 要素を <paragraph>として綴り、それから、文書を標準の出版プロセスに送り込む前に、 <paragraph>の名前を<p> に変えて戻す事前処理をすることができる。
カスタム化した文書型は、型モジュールを編集することなく生成されるべきである。文書型シェルは、型モジュール・ファイルのインポートの前に、実体の新しい定義を提供することで、モジュール・ファイルの実体を、属性と内容モデルを含めて、乗り潰すことができる。
カスタム化した文書型は、DITA標準に準拠しない、そして標準準拠のツールでサポートされないだろう。事前処理によって、既存の出版過程との互換性を保証できる。しかし、DITAをサポートする編集ツールや内容管理システムとの互換性は保証しない。しかしながら、何かのケースで実装が重度にカスタマイズされているときは、カスタム化した文書型は、カスタム化した実装における非標準設計の意味するところを分離し制御する助けになる。
専門化は内容において二つの属性を使って表現される：クラス属性と領域属性。それらは、文書インスタンスに必ずしもあるとは限らないが、DTDまたはスキーマで表現される既定値によって供給される。
専門化属性は、処理やツールに、あなたのマークアップがどの規則の組に準拠しているかを知らしめる。これによって、ツールと処理を、経験のないマークアップのために再利用可能になる。
構造の専門化を作成するとき、既存の属性の内容を新しい要素に対して制限できる；（条件付き処理のための）props属性または（単純なトークン属性のための）base属性に基づく領域の専門化を通して、新しい属性を作成することもできる。
領域属性の専門化はDITA文書型の開発者が、フィルタリングまたはフラグ化に使うことのできる新しい条件付処理属性、または、条件付き処理属性と同じ方法で管理したり一般化されることができる、等価な既存の属性がない、新しい属性を組み込むのを許す。
新しい属性は、propsまたはbaseに基づいている必要がある：
既存の条件付処理属性は、将来、propsに基づく領域に移行する、強い可能性があるので、構造的専門化では、その属性の値を制限することは、やめる方が良い。
DITAのアーキテクチャで宣言されている各要素はクラス属性をもっている。この属性は、その要素の現在の名前とより一般的な等価要素との間の対応関係を提供する。要素の型がより専門化すればするほど、そのクラス属性値はより長くなる。
例えば、taskトピック型のstep要素のクラス属性：
<!ATTLIST step class CDATA "- topic/li task/step ">
これは、step要素が一般的なトピックのli要素と同等であることを語っている。これはまたstepはtaskピックにおけるstepに同等であることを語っている。そのことは既に知っているが、これを属性で注意することで、上位レベルと下位レベルのタイプの間を、情報を失うことなく、往復で移行することが可能になるという意味がある。例えば、もしユーザが全ての要素をそれの最初のクラス属性の値に変換するが、しかし、その内容と属性を保持する、「一般化」変換を行うとすると、そのユーザは、（内容と属性の値を保持しながら）すべての要素をその最後のクラス値にマップするという「専門化」変換でそれを追随することができる。そして、二つの一般的な変換とクラス属性の情報を使いながら、二つの文書型の間を、すべての内容に渡って完全な往復変換を提供することができる。
クラス属性は、処理器に対して、現在の要素が属している一般的なクラス要素は何かを伝える。DITAは、文書型の代わりに、（例えば、トピック型、領域型、マップ型）モジュール型によって値の範囲を決める。それによって、文書型の開発者は、変換ロジックを複雑化することなく、複数のトピック型を結合してひとつの文書型にする。
値の系列は、それが、処理器にどの値が最も一般的で、どれが最も専門的であるかを告げるので重要である。これは、特に、「専門化」変換で重要である。そこでは、次の一般規則を適用できる：要素がターゲット・トピック型への対応をもたないならば、単にクラス属性の最後の値を使え。（そして、その専門化トピック型は、それらが宣言されたレベルのみ対応関係をもつ、ある種の一般要素宣言を再利用していることを仮定せよ。）
クラス属性値は、乗り潰されることが可能で、固定でない、既定値として提供されている。クラス属性を変更する能力は、移行において対応の永続性のために重要である：内容をより抽象的な要素に移行するとき、クラス属性の中に、より専門化された履歴を保持することができ、より専門化された、またより一般の表示の間で、内容を往復変換することができ、異なるアプリケーションによって、それが理解したり、支持する任意のレベルで処理されることができる。
クラス属性は、正しく処理されるためには従わねばならない特別な文法を持っている。
各要素はクラス属性を持たなければならない。クラス属性は、もし構造モジュールで定義されていれば"-"から、領域モジュールで定義されていれば"+"から始まる。開始のトークンの後ろに、ひとつ以上の空白で区切った値、最後は空白で終わる。各値には二つの部分がある：最初の部分は、例えばトピック型または領域名のような専門化モジュールを識別し、ふたつめの部分（/の後ろ）は要素型を識別する。構造名はトピック型またはマップ型のルート要素から取られる。領域の名前は、領域モジュールで定義される。
典型的には、クラス属性は、文書のインスタンスの中で直接というよりもむしろ、DTDまたはスキーマの中で既定値として宣言されるべきである。クラス属性は編集者に修正されてはならない。
<appstep class="- topic/li task/step bctask/appstep ">A specialized step</appstep>
図4 クラス属性をもつ構造型要素の例
<wintitle class="+ topic/keyword ui-d/wintitle ">A specialized keyword</wintitle>
図5 クラス属性をもつ領域要素の例
クラス属性がDTDまたはスキーマで宣言されるとき、既定値を伴って宣言されねばならない。一般化の往復（専門化された内容を一般形式に一般化するのと、それを専門化形式に戻す）を支持するためには、既定値は固定であってはならない。これは、一般化過程が、一般化されている文書から取得した専門化された値で、一般の文書型の既定値を乗り潰すことを許す。
専門化型が新しい要素を宣言するとき、その新しい要素のクラス属性を提供しなければならない。クラス属性は、専門化された型の家系の中の、すべての構造型と領域のマッピングを含まなければならない。マッピングは、基本型（例えば、トピックまたはマップ）の値から始まり、現在の要素型で終わるべきである。
<windowname class="- topic/kwd task/kwd guitask/windowname ">
図6 中間の値をもつ属性の例
中間の値は、一般化と専門化の変換が、値を単純にかつ正確にマップできるために必要である。例えば、task/kwdが値として欠けていて、ユーザがこのguitaskをタスク・トピックに一般化することを決めたら、変換では、kwdにマップする（タスクがguitaskよりも一般的であるとき適切である、これがそうだ）か、それともwindowname（タスクがより専門化されていたなら適切である、これはそうでない）として残すかを推定しなければならない。より一般的な値へのマッピングを常に提供することにより、欠けているマッピングは、既定値では、一般化するものよりも、より専門化された値へのものでなければならないという単純な規則を適用できる。このことは、リストの最後の値が適切であることを意味している。例えば、<task>へ専門化するときは、<p>要素が、<task>のための対象値をもたないならば、我々は<p>は、<task>から専門化しない、そして一般化されるべきではないと安全に仮定できる。
この例は、些細なものであるが、より複雑な階層（例えば、5段階の深さで、名前の付け直しが2段階と4段階のみで起きている）は、明示的な中間値を本質的なものにする。
専門化された型は、それを専門化しない要素のためにクラス属性を変更する必要がなく、より一般的なレベルから、単純に、参照により再利用する。例えば、task、bctask、guitaskはp要素を専門化しないで用いるので、それらは、その(pの)ためのマッピングを宣言する必要はない。
専門化された型は、それがユニークに宣言する要素のためのクラス属性のみを宣言する。それが再利用するまたは継承する要素のクラス属性を宣言する必要はない。
領域属性は、現在の文書型で使われている領域の名前と各領域の家系をリストする。領域属性は、各トピック型のルート要素に宣言される。
使用されている各領域は、括弧の中に、各祖先の領域の名前とそれが寄与している領域の名前を与える文字列を提供する。各括弧の組の中に、領域とその家系が、最も遠い先祖（その領域階層が基づいているルートの型）から初めて、使用されている領域の名前で終わるようにリスト化されるべきである。
<task id="mytask" class="- topic/topic task/task " domains="(topic ui-d) (topic sw-d) (topic pr-d cpp-d)"> ... </task>
この例では、タスクは、ユーザ・インターフェイス（ui-d）、ソフトウエア（sw-d）、C++プログラミング（cpp-d）を記述するためのタグの使用を許している。
ひとつの要素を他から、あるいは新しい属性をpropsまたはbaseから専門化するとき、新しい要素または属性は、妥当な専門化であるためにある種の規則に従わねばならない。
専門化された内容は、任意の先祖の型に一般化できる。一般化の過程では、同じ内容の専門化と非専門化された形式との間の往復変換を許すために、より以前の段階の専門化の情報を保持できる。
一般化は移行目的（例えば、不成功な専門化をやめるとき）、または、暫定的な往復変換目的（例えば、内容を専門化を知らない、基本構造型のインスタンスのためにのみ可能とされている過程を通して動かす）でありうる。移行のための一般化のときは、一般的なDTDまたはスキーマにおける既定値が使われるために、クラス属性と領域属性は、一般化されたインスタンス文書には存在してはならない。往復変換のための一般化のときは、クラス属性と領域属性は、一般化されたインスタンス文書の中に、元の専門化された値を保持するべきである。
任意のDITA文書は、最低ひとつの構造型とゼロ以上の領域からのマークアップの混在を含むことができる。特定の文書型の中の構造型と領域は、文書型シェルによって定義される。
文書を一般化するとき、一般化器は、構造型または領域をあるがままにしておくことを選ぶか、型と領域をその祖先のどれかに一般化することを選ぶことができる。
一般化器は、各一般化に対してソースとターゲットを提供できる：例えば、参照からトピックに一般化する。一般化器は、ひとつのパスで多数のターゲットを指定できる：例えば、参照からトピックへ、および、ui-dからトピックへの一般化。ソースとターゲットが提供されないとき、一般化は、すべての構造化された型から基本（トピックまたはマップ）へ、であり、領域のための一般化はない、と想定される。
一般化器は、ターゲット文書型を提供することもできる。ターゲット文書型が提供されないとき、一般化された文書はDTDまたはスキーマ参照を含まないだろう。将来のある時点で、文書型シェルとターゲット文書型を、一般化された文書のおけるクラスと領域の属性に基づいて自動的に生成することが可能かもしれない。
一般化過程は、一般化のためのソースだけ（このケースでは、指定されたソース型がトピックまたはマップに一般化される）、一般化のためのターゲットだけ（このケースでは、ターゲットのすべての子孫が、そのターゲットに一般化される）、または両方が与えられる（このケースでは、ターゲットの指定された子孫だけが、そのターゲットに一般化される）ケースを処理できるべきである。
各構造型のインスタンスに対して、一般化過程は、構造化型のインスタンスが一般化の候補かどうか、あるいは、それが一般化の候補である領域をもつかをチェックする。どの構造化型インスタンスを処理するかについて選択的であることが重要である：処理が単純にそのクラス属性値に基づいてすべての要素を一般化するのならば、"参照"を"トピック"に一般化するという指示は、"参照"から再利用する任意の要素は、トピック・レベルの同等要素に名前を変えられてしまうので、妥当でない内容モデルをもつAPI参照トピックを残してしまうだろう。
構造型のルート要素のクラス属性は、構造型を一般化する前にチェックされる：
| ターゲットとソース | ソースが指定されていない | ソースが指定されている |
|---|---|---|
| ターゲットが指定されていない | この構造型を基本の祖先に一般化 | トピック型のルート要素が指定されたソースにマッチするかどうかをチェックせよ；マッチすればその基本の祖先に一般化し、そうでないときは一般化するべき領域をもっていない限り、その構造型インスタンスを無視せよ |
| ターゲットが指定されている | クラス属性がターゲットを含むかどうかをチェックせよ；含むならばターゲットに一般化し、そうでないときは一般化するべき領域をもっていない限り、その構造型インスタンスをスキップせよ。 | ルート要素が指定されたソースにマッチし、クラス属性がそのターゲットを含まないならば、エラー・メッセージを出せ。ルート要素が指定されたソースにマッチし、クラス属性がそのターゲットを含むならば、そのターゲットに一般化せよ。そうでないときは、一般化するべき領域をもっていない限り、その構造型インスタンスを無視せよ。 |
領域を一般化する前に、その構造型のルート要素の領域（domanins）属性をチェックする：
| ターゲットとソース | ソースが指定されていない | ソースが指定されている |
|---|---|---|
| ターゲットが指定されていない | この構造型における領域専門化を一般化しない | 領域属性が指定された領域をリストしているかどうかチェックせよ；そうであれば一般化の処理をすすめ、そうでないならば、それ自身が一般化の候補でないかぎり、その構造化型インスタンスを無視せよ。 |
| ターゲットが指定されている | その領域属性がターゲットを含んでいるかどうかをチェックせよ；そうであればターゲットに一般化し、そうでなければ、それ自身が一般化の候補でない限り、その構造化型インスタンスをスキップせよ。 | 領域属性が、指定したソースにマッチし、しかし、その領域値がターゲットを含まないならば、エラーメッセージを出せ。その領域属性が指定したソースにマッチし、そして領域値の文字列がターゲットを含まないから、ターゲットに一般化せよ。そうでなければ、それ自身が一般化の候補でない限り、その構造化型インスタンスをスキップせよ。 |
候補となる構造型インスタンスにおける各要素について：
| ターゲットとソース | ソースが指定されていない | ソースが指定されている |
|---|---|---|
| ターゲットが指定されていない | そのクラス属性が、"_"（構造型の一部）で始まるならば、その要素を基本先祖の同等要素にリネームせよ。そうでないならば、それを無視せよ。 | クラス属性の最後の値が、指定したソースにマッチするかどうかをチェックせよ；そうであればその基本祖先に一般化し、そうでないならばその要素を無視せよ。 |
| ターゲットが指定されている | クラス属性がターゲットを含むかどうかをチェックせよ；もしそれがターゲットを含むならば、要素をそのターゲットに関連付けられた値にリネームせよ、そうでないならばその要素を無視せよ。 | クラス属性の最後の値が指定されたソースにマッチし、しかし、その前の値がターゲットを含まないならば、エラーメッセージを出力せよ。クラス属性の最後の値が指定されたソースにマッチし、そして、その前の値がターゲットを含むならば、その要素をターゲットに関連付けられた値にリネームせよ。そうでないならばその要素を無視せよ。 |
往復変換の一般化の間に要素をリネームするとき、一般化処理は、すべての属性の値を保持するべきである。一方向または移行の一般化の間に要素をリネームするとき、その処理は、ターゲット文書型によって提供されるべきであるクラスと領域属性を除く、すべての属性の値を保持するべきである。
propsまたはbaseから専門化された属性は、特別な属性一般化構文を用いて一般化することができる。専門化を知っている処理は、属性の専門化と一般化された形式の両方をその値において同等であるとして認識し、処理することができなければならない。
一般化されるとき、専門化した属性の名前によって先行される括弧の中に、専門化属性値をターゲットの先祖の属性の最後に追加される。一般化されている各属性について、分離したラベルと括弧で囲まれた値の組が、先祖の属性に追加される。
例えば、"jobrole"が、"person"から専門化されており、また"person"は"props"から専門化された属性であると仮定する：
一般化と再専門化はdomains属性を役割の祖先を決定するために用いることができ、その故に、personの妥当性を一般化の中間的なターゲットとして用いることができる。
一般化された属性は、通常は、直接、オーサリングや編集したりされることは期待されていないが、文書が暫定的に一般化された形式になっている間、専門化された値を保持することが期待されている。
ひとつの要素が、ふたつ以上の構文における属性の値を含むならば、それはエラーである。例えば、<p person=″role(programmer)″ role=″admin″>...</p>は、両方ともrole属性に値を提供しているが、一方は一般化された構文であり、他方は専門化された構文である。これは、その文書が部分的にのみ一般化されたか、または、一般化された後専門化された文書型を用いて編集されたことを意味するので、エラー条件である。
一般化の間、DITA要素はclass属性に基づいて、先祖の要素の名前を使うように修正される。これは、専門化された<foreign>要素の内容についてはできない。なぜならば、その内容はDITA要素ではなく、class属性を持っていないからである。
その代わりに、専門化された外部要素それ自身は通常の規則を用いて一般化されなければならない。外部要素の内容は、別のファイルにエクスポートされなければならず、インラインでは<object>要素によって置換されなければならない。オブジェクト要素は、そのdata属性を用いて、生成されたファイルを指し示さねばならない。そのオブジェクト要素のtype属性は、″DITA-foreign″に設定されなければならない。
オブジェクト要素は、<foreign>要素の内部では既に許されている。一般化の過程においてそれが存在するならば、それを別のファイルにエクスポートしてはならない。元のオブジェクト要素は、一般化の通常の規則によって要求されない限り、修正されてはならない。オブジェクト要素は、外部の内容を表示できない出版システムにおいては、代替内容として使用される。
外部内容要素は、代替内容のほかに、幾つかの主要素を含むかもしれない。これに対応するために、エクスポートされた内容は、ルートの<foreign>要素をもたねばならない。
エクスポートされたファイルの名前は、ユーザが、生成されたファイルの起源を認識するのを助けるために″dita-generalized-″から開始しなければならない。ファイル名は、また、トピックID、専門化型、要素IDまたは生成された識別子を含むことが推奨される。例えば、″topicid″というトピックの最初のmathmlオブジェクトは、″dita-generalized-topicid-mathml1.xml″という名前になるだろう。
例えば、DITA文書はMathMLのための<foreign>の専門化を含むかもしれない。これは次のように見えるであろう：
<mathml class="+ topic/foreign mathml/mathml ">
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mi>x</mi><mo>+</mo><mn>3</mn>
</math>
<object><desc>X plus three</desc></object>
</mathml>通常のDITA要素である、mathmlコンテナは、通常の規則を使って一般化されなければならない。DITA要素でない、<math>要素は、他のファイルにエクスポートされるだろう。<object>要素が残るだろう：
<foreign class="+ topic/foreign mathml/mathml "> <object data="dita-generalized-topicid_mathml1.xml" type="DITA-foreign"/> <object><desc>X plus three</desc></object> </foreign>
dita-generalized-topicid_mathml1.xmlの内容は：
<foreign class="+ topic/foreign mathml/mathml ">
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mi>x</mi><mo>+</mo><mn>3</mn>
</math>
</foreign>
ひとつのオブジェクトが複数のオブジェクト要素を含むかもしれない：
<mathml class="+ topic/foreign mathml/mathml ">
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mi>x</mi><mo>+</mo><mn>3</mn>
</math>
<object><desc>X plus three</desc></object>
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mi>y</mi><mo>-</mo><mn>2</mn>
</math>
</mathml>
通常のDITA要素である、mathmlコンテナは、通常の規則を使って生成されなければならない。コンテナに結合された要素と任意の存在するオブジェクト要素の各組に対してひとつのファイルを生成しなければならない。この例では、二つのファイルが生成され、二つの新しいオブジェクト要素が元のものに追加される：
<foreign class="+ topic/foreign mathml/mathml "> <object data="dita-generalized-topicid_mathml1.xml" type="DITA-foreign"/> <object><desc>X plus three</desc></object> <object data="dita-generalized-topicid_mathml2.xml" type="DITA-foreign"/> </foreign>
dita-generalized-topicid_mathml1.xmlの内容は：
<foreign class="+ topic/foreign mathml/mathml ">
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mi>x</mi><mo>+</mo><mn>3</mn>
</math>
</foreign>dita-generalized-topicid_mathml2.xmlの内容は：
<foreign class="+ topic/foreign mathml/mathml ">
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mi>y</mi><mo>-</mo><mn>2</mn>
</math>
</foreign>設計における専門化は、内容の専門化が処理規則の再利用を可能とするのと同じように、設計要素の再利用を可能とする。これらの規則には、マークアップ・モジュールを別々の再利用可能な単位として生成・管理することを含む。
専門化設計の規則に従うことは、専門化された要素の規則に従うことが内容の再利用を可能にするのと同じように、設計要素の再利用を可能にする。
設計モジュールを開発するための標準スキーマを使うことで、専門化は次のことを可能とする：
専門化階層は、各専門化に固有のマークアップと実体を宣言するモジュール・ファイルの組として実装される。モジュールは、使用される前に、文書型の中に統合されなければならない。
XHTMLのモジュール化の先導(http://www.w3.org/TR/xhtml-modularization/)におけるように、マークアップをモジュールに分割することは、専門化階層の中の特定の部品を簡単に再利用することを可能とし、また、（新しいモジュールを既存の文書型に影響を与えることなく追加できるので）階層の拡張を簡単にする。これにより、異なる源泉から来る設計要素を組み立てて、ひとつの統合化された文書型にすることが簡単になる。
各領域の専門化または構造的な専門化は、それ自身の設計モジュールを有している。これらのモジュールは多数の異なる文書型を生成するために結合されうる。特定のモジュールの組み合わせから、新しい文書型を生成する過程を統合化と呼ぶ。
統合化は、統合されるモジュールとそれがどのように統合されるかを定義する、文書型シェルを使って実行される。統合化は文書型の中でどんなトピック型と領域が許されるか、またトピック型がどのようにネストされることが許されるか、の両方を定義する。
特定の型のためのモジュールは、その型に固有の要素と属性の宣言のみを含まなければならず、他のモジュールを含んではならない。シェルには、マークアップ宣言を含んではならず、それが必要とするすべてのモジュールを直接参照するべきである。シェルのネスト、モジュールのネスト（シェルの中に他のシェルを埋め込んだり、モジュールの中に他のモジュールを埋め込んだりすること）は、複雑さをまし、ツールによってはうまく使えないので、思いとどまるべきである。文書型の間の共有は、なにか他の文書型を直接参照することでなく、共有モジュールを通じて実現されねばならない。モジュール間の依存性は、モジュール自身を通じてではなく、シェルの統合を通じて満たされなければならない。
拡張性とプラグ化可能性を支持するため、DITAは構造と領域専門化モジュールのDTD実装が、良く定義された設計パターンに準拠することを要求する。
この節では、これらの設計パターンを記述する。これらの設計パターンは、専門化アークテクチャを、DTD文法の能力をもって、その限界の範囲で実現する。
各構造型はトピック要素名とmod拡張子から構成される名前をもつ切り離されたDTDモジュールで定義されなければならない。例を見るために、conceptトピック型のためのconcept.modモジュールを見よ。
構造型モジュールは、次の設計パターンに準拠しなければならない。
<!ENTITY % conbody "conbody">
文書型シェルは、その中で基底の要素が生起するような全ての文脈の中に、領域で専門化した要素を追加するための要素実体を事前に定義することができる。<!ENTITY included-domains "">
文書型シェルは、included-domains実体を、文書型に追加された領域をリストするために事前定義することができる。<!ENTITY % concept-info-types "%info-types;">
それで、文書型シェルは、topictype-info-types実体を、各トピック型に再定義することによって、トピックがどのようにネストすることが許されるかを制御したり、あるいは、主のinfo-types実体を再定義することによって、共通のネスト規則を簡単に生成できる。<!ELEMENT concept ((%title;), (%titlealts;)?, (%shortdesc;)?,
(%prolog;)?, (%conbody;), (%related-links;)?,
(%concept-info-types;)* )><!ATTLIST concept id ID #REQUIRED
...
DITAArchVersion CDATA "&DITAArchVersion;"
domains CDATA "&included-domains;"
>これらの属性は、処理に対して、アークテクチャのバージョンをチェックしたり、文書型の中で得られる領域のリストを参照するための信頼できる方法を与える。特に、モジュールは全ての専門化された要素のためのクラス属性を定義する。クラス属性は、基底要素のクラス属性の値を含み、そして、前と後ろに空白が最低ひとつ付いたトピック要素名で修飾された要素名を追加しなければならない。構造的専門化で導入された要素のクラス属性は、マイナス符号で始まらなければならない。
各領域専門化は二つのファイルを持たねばならない。
例を見るためには、highlightDomain.entとhighlightDomain.modファイルを見よ。
領域実体宣言ファイルは、次の設計パターンに準拠しなければならない：
<!ENTITY % hi-d-ph "b | u | i | tt | sup | sub">
<!ENTITY hi-d-att "(topic hi-d)">
領域定義モジュールは、次の設計パターンに準拠している。
<!ENTITY % b "b">
属性領域のパターンは、propsとbase属性から専門化された新しい属性の生成を許す、領域専門化の特殊なケースである。
ひとつの属性毎にひとつのモジュール実体を生成せよ、例えば、newAttDomain.ent。各モジュールは次を含まねばならない：
<!ENTITY % newAtt-d-attribute "new CDATA #IMPLIED">
<!ENTITY newAtt-d-att "a(props new)" >：
文書型シェルは、次の設計パターンに準拠しなければならない。例を見ると、コンセプト文書型のためのconcepts.dtdを見よ。
<!ENTITY % hi-d-dec PUBLIC
"-//OASIS//ENTITIES DITA Highlight Domain//EN" "highlightDomain.ent">
%hi-d-dec;
<!ENTITY % newAtt-d-dec PUBLIC
"-//My Company//ENTITIES new Attribute Domain//EN" "newAttDomain.ent">
%newAtt-d-dec;<!ENTITY % pre
"pre | %pr-d-pre; | %sw-d-pre; | %ui-d-pre;">ひとつ以上の領域によって拡張された各属性に対して、文書型シェルはその属性のための実体を、専門化を提供する各領域からの属性の名前リテラルと属性拡張実体を含めて代替リストに再定義する。DITA 1.1 では属性は、prosまたはbaseからのみ専門化されることができる。
<!ENTITY % props-attribute-extensions
"%newAtt-d-attribute;
%othernewAtt-d-attribute;">
<!ENTITY % base-attribute-extensions
"%newfrombaseAtt-d-attribute;
%othernewfrombaseAtt-d-attribute;">
<!ENTITY % concept-info-types "concept">
<!ENTITY included-domains
"&ui-d-att; &hi-d-att; &pr-d-att; &sw-d-att; &ut-d-att; &newAtt-d-att"><!ENTITY % topic-type PUBLIC
"-//OASIS//ELEMENTS DITA Topic//EN" "topic.mod">
%topic-type;<!ENTITY % hi-d-def PUBLIC
"-//OASIS//ELEMENTS DITA Highlight Domain//EN" "highlightDomain.mod">
%hi-d-def;属性領域には領域定義はない。拡張性とプラグイン可能性を支持するため、DITAは、構造と領域の専門化モジュールのXMLスキーマ実装が、良く定義された設計パターンに準拠することを要求する。
この節ではこれらの設計パターンを記述する。これらの設計パターンは、専門化のアーキテクチャを、XMLスキーマの文法の能力で、その限界内で実現する。
各構造型に対して、文書型シェル文書は、新しいトピック型の専門化を実装するのに必要とされる、スキーマの文書、親の構造型モジュール、領域型モジュール、内容モデルを収集する。新しい各構造型は三つのファイルを要求する。例を見るためには、conceptトピック型のためのconcept.xsd文書型シェル文書を見よ。
モジュール・スキーマ文書は、トピック要素名の接頭辞と、-info-types接尾辞をもつように命名されたinfo-typeモデル・グループを定義しなければならない。ここに、conceptMod.xsdの中で定義されているinfo-typesモデル・グループの例がある：
<xs:group name="concept-info-types">
<xs:choice>
<xs:group ref="concept"minOccurs="0"/>
<xs:group ref="info-types" minOccurs="0"/>
</xs:choice>
</xs:group>
モジュール・スキーマ文書はその構造型の中で部分構造として使われる全ての専門化された要素を定義する。専門化された要素は、内容モデルと属性を定義するにあたり、アーキテクチャの規則に従わなければならない。内容モデルのための命名規約は、ルート構造型要素名と.classを使わねばならない。
すべての専門化と同様に、構造的専門化のルート要素は、それが専門化する要素の内容モデルを制限するか、維持する内容モデルを有しなければならない。ルート要素はまたDITAArchVersion属性とdomains属性を参照しなければならない。スキーマについては、文書型シェルの中でdomains属性値が設定される。domains属性に対して、どのように値を設定するかについてのより詳しい情報は、文書型シェルパターンを参照せよ。付け加えて、内容モデルの最後の位置は、次の例のようにネストしたトピック実体でなければならない：
<xs:complexType name="concept.class">
<xs:sequence>
<xs:group ref="title"/>
<xs:group ref="titlealts" minOccurs="0"/>
<xs:choice minOccurs="0">
<xs:group ref="shortdesc" />
<xs:group ref="abstract" />
</xs:choice>
<xs:group ref="prolog" minOccurs="0"/>
<xs:group ref="conbody" minOccurs="0"/>
<xs:group ref="related-links" minOccurs="0"/>
<xs:group ref="concept-info-types" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
....
</xs:complexType>
これらの属性は、処理に対して、アーキテクチャの版をチェックし、文書型で利用可能な領域のリストを探しだすための信頼できる方法を与える。
<xs:attribute name="id" type="xs:ID" use="required"/> <xs:attribute ref="ditaarch:DITAArchVersion" />
新しいファイルtopictypeGrp.xsdが、W3CのXML Schema 1.0 specificationの継承モデルを使うことなく、XMLスキーマのsubstitutionGroupsを真似するために必要とされる。この処理は、DITAのDTD設計パターンに非常に良く似ている。構造型については、スキーマ文書の名前は、ルートの構造要素名とGrp.xsd拡張子なら構成される。モデル・グループのスキーマ文書の例を見るならば、conceptGrp.xsdを見よ：
<xs:group name="concept">
<xs:sequence>
<xs:element ref="concept"/>
</xs:sequence>
</xs:group>
モデル・グループのスキーマ文書は、構造型の中の新しく専門化された要素の各々に対してモデル・グループを定義する。各構造型と領域は、モデル・グループ・スキーマ文書を持たねばならない。モデル・グループ・スキーマ文書は、専門化の本質的な部分である。
クラス属性は、基底要素のクラス属性の値を包含し、最低限一つの先行と後行する空白を伴って、ルート構造要素の名前または領域名で修飾された要素名を追加しなければならない。クラス属性は、それが構造モジュールで宣言されているならば"-"で始まり、もしそれが、領域モジュールで宣言されているなら"+"で始まる。
この属性は、要素の現行の名前とそのより一般的な等価物の間のマッピングを与える。それは要素の宣言に結合されていなければならないが、要素に参照されているcomplexTypeの中にあってはならない。例を見るならば、reference.xsdスキーマ文書を見よ。
<xs:element name="reference">
<xs:complexType>
<xs:complexContent>
<xs:extension base="reference.class">
<xs:attribute ref="class" default="- topic/topic reference/reference "/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
領域名とDomain.xsd拡張子から構成される名前をもつ領域型スキーマ文書。
構造モジュールに於けるように、領域モジュールは各専門化された要素、その属性、そのモデル・グループを定義しなければならない。すべての専門化に於けるように、領域要素は基底の名前を制限しなければならない。領域名のクラス属性は、プラス記号から開始しなければならないが、それ以外は、トピックの専門化によって導入された要素のためのクラス属性と同じ規則に従わねばならない。
ひとつ以上の領域によって拡張された各要素について、領域型スキーマ文書は、基底要素のモデル・グループに、専門化を提供する各領域文書からきた要素の名前リテラルと要素の拡張実体を含む、代替のリストを定義する。
スキーマ文書は、領域によって拡張される各要素のためにモデル・グループを定義しなければならない。モデル・グループの内容は、その拡張された要素のための専門化された要素のリストでなければならない。モデル・グループの名前は、その領域のための略称の接頭辞と拡張された要素の名前の拡張子を持つ。次の例では、ユーザ・インターフェイス領域（ui-dと略称される）は、ph要素を拡張している。
<xs:group name="ui-d-ph">
<xs:choice>
<xs:element ref="uicontrol" />
<xs:element ref="menucascade" />
</xs:choice>
</xs:group>
各文書シェル型について、次の名前付きモデル・グループinfo-typesが定義されなければならない。このモデル・グループは、デフォルトの従属トピックのリストを定義することができる。もし、このトピック型がデフォルトの従属トピックを持たないならば、info-typesモデル・グループのデフォルト値は、空グループとして定義されなければならない。
<xs:group name="info-types"> <xs:sequence/> </xs:group>
基底のルート構造要素と専門化されたルート構造要素に於けるdomains属性のためのデフォルト値は、domains属性を居住させるためのスキーマの<redefine>機構を使って定義されなければならない。それはその構造型で使われる領域を識別する。この属性は、処理に対して、文書型で使用できる領域のリストを探し出す信頼できる方法を与える。領域のリストは、次の例のように文書型に含まれている：
<xs:redefine schemaLocation="topicMod.xsd" >
<xs:complexType name="topic.class">
<xs:complexContent>
<xs:extension base="topic.class">
<xs:attribute
name="domains" type="xs:string" default="(topic ui-d)
(topic hi-d) (topic sw-d) (topic pr-d) (topic ut-d) (topic indexing-d)"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:redefine>
ひとつ以上の領域によって拡張される各要素に対して、文書型シェルは、専門化を提供する各領域に対して、要素の名前リテラルと要素の拡張モデル・グループを含む代替リストに、その要素のモデル・グループを再定義する。文書型シェルに新しい領域を統合するためには、その文書型シェルによって使われている領域の数を管理するために、スキーマ<redefine>機構を使う。モデル・グループは、基底モデル・グループを拡張するためにそれ自身を参照することを要求する。例を見るために、topic.xsdスキーマ文書を見よ。
<xs:group name="pre">
<xs:choice>
<xs:group ref="pre" />
<xs:group ref="pr-d-pre" />
<xs:group ref="ui-d-pre" />
<xs:group ref="sw-d-pre" />
</xs:choice>
</xs:group>
新しい構造型に領域を追加するために、親の構造型領域スキーマ文書の内容を文書型シェルに複製することができる。新しい領域からモデル・グループを適切な名前のついたグループに追加または削除せよ。
<xs:group name="pre">
<xs:choice>
<xs:group ref="pre"/>
<xs:group ref="pr-d-pre" />
<xs:group ref="domainName-d-element"/>
</xs:choice>
</xs:group>
ひとつ以上の領域によって拡張された各属性に対して、文書型シェルは、その属性のための属性拡張モデル・グループを、専門化を提供する各領域から属性の名前リテラルと属性拡張モデル・グループを含む、代替リストに再定義する。DITA 1.1では、属性は、propsまたはbaseからのみ専門化できる。文書型シェルにおいて、新しい属性領域を統合するために、文書型シェルによって使われている属性領域の数を管理するためのスキーマ<redefine>機構を使え。
<xs:attributeGroup name="props-attribute-extensions"> <xs:attributeGroup ref="props-attribute-extensions"/> <xs:attributeGroup ref="newAtt-d-attribute"/> <xs:attributeGroup ref="othernewAtt-d-attribute"/> </xs:attributeGroup> <xs:attributeGroup name="base-attribute-extensions"> <xs:attributeGroup ref="base-attribute-extensions"/> <xs:attributeGroup ref="newfrombaseAtt-d-attribute"/> <xs:attributeGroup ref="othernewfrombaseAtt-d-attribute"/> </xs:attributeGroup>
属性領域パターンは、領域専門化パターンの特別なケースである。それは、propsまたはbase属性から専門化された新しい属性の生成を可能とする。
属性毎に、例えばnewAttDomain.xsdという、ひとつのモジュール実体ファイルを生成せよ。各モジュールは次のものを含まねばならない：
実際の属性の宣言を実体形式に保持する実体。この実体は、文書型シェルの中で、新しい属性を追加するのに使われる。例えば：
<xs:attributeGroup name="newAtt-d-attribute"> <xs:attribute name="new" type="xs:string"/> </xs:attributeGroup>
この属性領域宣言値は、文書型シェルの中で、DITAを意識する処理に対して、属性の入手可能性を合図するために使われることができる。それは、通常の領域宣言値と同じ文脈を使うが、先行する"a"を付加して、これが属性領域であることを合図する。
<xs:attribute name="domains" type="xs:string" default="... a(props new)"/>
専門化された処理は、必ずしも全ての専門化要素のためではなく、その祖先に基づく適切な既定の振る舞いを持たない要素のためである。
新しい変換を生成するかあるいは既存のそれを拡張するかのいづれにしても、他の専門化型のための変換の効率性、そして変換が新しい要求に適応するための保守性・拡張性を保証するために守られるべき幾つかの規則がある。
クラス属性に基づいてXSLTのテンプレートを適用することは、変換が、ひとつの要素型の代わりに要素型の全ての枝に適用されることを許す。
要素名（要素名の値を含む任意のXPath文）をチェックしようとするときはいつでも、その代わりに要素のクラス属性の内容をチェックするように変更する必要がある。処理器が要素を知らない場合でも、クラス属性は、その要素が知られている要素のクラスに属していることを変換に知らせることができ、そしてそのクラスの規則に従って、安全に取り扱いされることができる。
必ず、クラス属性の文字列チェックにおいて、先行と後行する空白を含むようにせよ。そうでないと、誤った一致（空白がないと、’task/step’は’task/step’及び’notatask/stepaway’の両方に一致するであろう）を得てしまうことがある。
ふたつ以上の型をターゲットとする変換を生成するときは、衝突を避けるために、必ず、より専門的な規則に、より高い優先度を与えるようにせよ。例えば、トピックのための既存の処理規則と、タスクのためのより専門的な処理規則を結合するときは、両方の規則の組をインポートするためにシェル・ファイルを使い、また、タスク特有の規則が、トピックのための一般的な規則と衝突しないように、インポートの優先度を使いなさい。
<xsl:template match="li">
は、
<xsl:template match="*[contains(@class,’ topic/li ’)]">
になる。
この一致文はそれが出会う任意のli要素で機能する。また、stepとappstep要素でも、それらが何であるかを明確には知らないにも関わらず、クラス属性がそれらが一般的に何であるかをテンプレートに使えるので、機能するだろう。
<xsl:template match="*[contains(@class,’ task/step ’)]">
この一致文は、一般のli要素には機能しないが、step要素とappstep要素の両方で機能する；それは、appstepが何かを知らないにも関わらず、stepのように扱うことを知っている。
専門化された属性には2種類がある：条件付処理のためにpropsから専門化されたもの、そして、他の目的のためにbaseから専門化されたもの。
propsから専門化された属性は、既定で条件付処理の振る舞いを継承するべきであり、それは一般的な形式でもまた機能するべきである。言い換えると、propsから専門化された新しい属性の値は、要素をフィルターしたりフラグ付けするために、他の任意の条件付処理属性（プラットフォームや聴衆など）と正確に同じように、条件付きで処理されることができる。
baseから専門化された属性は、既定では処理をもたないだろう；与えられた任意の処理は、同じように一般化された形式で機能するようにすべきである。
一般化された属性の文脈に関する情報は、「属性の一般化」を参照せよ。
<foreign>の既定の振る舞いは、内容を表示することである。もし、処理器が内容を可視化できないならば、警告を出しても良い。<unknown>の既定の振る舞いは、削除することである。
この節は、専門化された外来の内容の処理上の振る舞いを、非文章的な内容のための既存の標準的な語彙に基づいて、記述することである。
外来の語彙を動作に可能するものは、<foreign>のための基本的な処理を乗り潰すことによる処理を提供しなければならない。
<unknown>のための基本処理は、別途の指示がない限り、削除することである。
処理は、それらが支持する構造型または領域に基づいてモジュールに分割されるべきであり、そして、構造型と領域モジュールが、文書型に統合されることができるのと同じように、変換またはスタイルシートに一緒に統合されることができる。
出力の相違のみを必要とするときは、可搬性あるいは交換可能性に影響を与えることなく、そして、専門化を含むことなく、デフォルトの出力を乗り潰すために、DITAのカスタム化を使うことができる。
例えば、読者がたいてい経験を積んだユーザであるならば、沢山のサマリ表を生成し、検索可能性を最大化することに集中することができる；または、ブランドの存在を作り出すことが必要ならば、変換をカスタマイズして適切なフォントとインデントのスタイルを適用し、幾つかの標準のグラフィックスと著作権のリンクを含むことができる。
新しい出力を必要とするときは、下位の意味を変更することなく（内容について、何らの新しいあるいは意味があることを言っているのではなく、その表示のみ）、カスタマイゼーションを使用しなさい。
DITAの専門化のためのCSSにおけるスタイルシートのサポートは、DTDやスキーマのためのと同じ原則を使って適用されることができ、その結果、保守しやすく、最小の努力で、任意の、後の専門化を支持するスタイルシートになる。
CSSための専門化を意識する特性は、この形式のセレクタをもつ：
*[class~="topic\/section"] {
margin-top: 12pt;
display: block;
}スタイルを要素に関係付けるCSSのセレクタは、要素名へのリテラルな一致を使わない。その代わりに、（例えば）class="- topic/section reference/refsyn "というデフォルトの値をもつ要素に基づく、この規則は、実際の要素名が何であるかに関わらず、“topic/section”値 (または“word”)の上で引き金を引き、関連するスタイルまたは変換を実行する。
その属性文字列は、そうでないとCSSのセレクタの中では妥当でない、“/”文字のためのエスケープ文字を含まねばならないことに注意せよ。
この例に於けるセレクタのパターンは、実質的には、CSSの用語では、”topic\/sectionという単語を含むクラス属性をもつ任意の要素を選択する”と読める。
必ずしもすべてのCSSシステムは、インスタンス文書に物理的に存在しない値に基づいて一致できない。DITAのクラス属性値は、典型的には、DTDまたはスキーマに於けるデフォルトの宣言によって提供されているので、必ずしも全てのCSSシステムがDITAのソースを直接マッチできるとは限らない。
もし、直接の専門化を意識する一致が可能でないときは、代替手段には標準化（DTDまたはスキーマから値をインスタンスに直接プッシュするためのDITAソースの事前処理すること）を含むか、要素名ベースの規則を使う。
要素名ベースの規則は、専門化を意識しないだろう。あなたのスタイルシート呼び出しは、専門化されたトピックまたは語彙のスコープによって要求される、それぞれが要素名セレクタを使って明示的に定義された、それぞれの追加的なスタイルシートをインポートしなければならないだろう。このスキーマでは、支持されない新しい要素は、専門化を意識するシステムでは、それらの要素は、クラス属性文字列に於いて、以前にサポートされた値から引き金を引いて離れる規則にフォールバックすることができるにも関わらず、関連する可視化特性を持たないだろう。
CSSは、XSLTと同じように専門化を支持する。この文書は、DITAのDTDとスキーマのための専門化設計パターンに従う、CSSスタイルシートを名前付けしたり、普及させるための最上の実践法について記述する。この実践法は、DITAのCSS支持を実装するために必要とされてはいないが、この実践法に従うことは、続く専門化のパターンのための作業を最小化し、その結果、ファイルがより保守しやすくなる。
ユニークなクラス属性値を持って専門化が可能にされている、新しく専門化されたDITAのDTDまたはスキーマをサポートすることは、専門化においてユニークに新しい要素のために必要とされる規則のみを含む新しいモジュールを作成する。これは、専門化においてユニークな要素のみを宣言するmodファイルに似ている。このモジュールの名前は、その専門化モジュールのルート名と同じにするべきである。DITAの参照DTDの場合は、要素宣言は、reference.modの中にあり、CSSのための対応するデルタ規則はreference.cssにある。
次に、@import指示をもって始まる、乗り潰しCSSスタイルシートを作成し、CSSファイルをこの専門化で使われる親DTDによって名前付ける。このインポートは、親DTDに共通の全要素のための支持を拾い集める。次に他の@import指示を、そのCSSの以前に作成したデルタ・モジュールを指示して、順番に追加せよ。次に、新しい要素名に関係付けられる必要がある以前に定義した任意の支持のためのCSS規則にコピーし、セレクタを新しい要素の専門化されたそれぞれの値に追加せよ。これらの追加されたCSS規則は、以前のDTDにデルタ要素定義を追加することによって構築された専門化DTDと同じように、新しいスタイルシートのためのデルタである。この技術は、クラス属性を実際にルート・クラスにマップできるならば、普通なら起きるであろうことに対する"フォール・スルー"支持を近似する。
最後に、必要なら、これらの新しい、任意のデルタCSS規則の振る舞いを変更せよ。なぜならば、この処理は以前の振る舞いの非常に多くを再利用しているので、デルタ変更を支持するために費やされる時間は最小である。
専門化を可能にしたCSSスタイルシートを専門化されたDITAのトピックと一緒に使うことは、それを単純にW3Cが定義したスタイルシート・リンク処理指示、または、あなたのエディタまたはブラウザのための構成規則に従って、トピックに関連付けることである。
DITA使用のためのXSLTに於けるスタイルシート支持は、DTDまたはスキーマのための同じ原則を使って適用可能である。その結果、保守しやすく、それに続く任意の専門化を最小の努力で支持するスタイルシートに帰結する。
XSLTのための専門化を意識するテンプレートは、この形式の一致パターンを持つ：
<xsl:template match="*[contains(@class,’ topic/section ’)]">
<div>
<xsl:apply-templates/>
</div>
</xsl:template>
このXSLTのスタイルを要素に関連付ける照合宣言は、要素名とのリテラルな照合を使っている訳ではない。むしろ、class="- topic/section reference/refsyn "という既定値をもつ要素に基づいて、（例えば）この規則は、“ topic/section ”値（照合文字列の中の空白の区切子が必要なことに注意せよ）の上で引き金を引き、実際の要素名がどうであれ関連付けられたテンプレートのアクションを実行する。
この例に於けるXPathパターンは、有効には、「クラス属性が、空白で区切られた部分文字列"topic/section"である任意の要素を選択する。」と読める。
XSLTパターン照合化はDITAの専門化を意識した処理の基本である。そうであるから、DITAのトピックのための基本のXSLTスタイルシートは、原型のトピックからどんなに世代的に遠く移されていても、最小限、任意の専門化を支持すべきである。
新しく専門化された、ユニークなクラス属性を持ち、専門化を可能にされたDITAのDTDまたはスキーマを支持することは、専門化において、ユニークな新しい要素に要求されるテンプレートのみを含むモジュールを作成する。これは、専門化において、ユニークな要素を宣言するmodファイルに似ている。このモジュールの名前は、専門化モジュールのためのルート名と同じであるべきである。DITAの参照DTDの場合、要素宣言はreference.modにあり、対応するXSLTのためのデルタ規則はreference.xslにある。
次に、この専門化の親DTDによって使われるXSLTファイルを指名して、xsl:import命令をもって始まる乗り潰しXSLTスタイルシートを生成せよ。このインポートは、親DTDに共通の全要素のための支持を拾い集める。次に、以前に作成したXSLTデルタ・モジュールを指名して、他のxsl:import命令を順に追加せよ。さらに、このシェルに適用される必要がある任意の領域特有のインポートを追加することができる。それから、新しい要素名にユニークに関連付けられる必要がある、任意の以前に定義した支持のためのXSLTテンプレートの中にコピーせよ。そして、照合パターン文字列を各々の新しい要素のための新しい専門化値に必要なようにリネームせよ。これらの付加されたXSLTテンプレートは、以前のDTDの上に、デルタ要素定義を付加して構築された専門化されたDTDと同じように、新しいスタイルシートのためのデルタである。XSLTサポートのためには、新しい振る舞いを必要とするか、または、祖先の要素の処理の振る舞いを変更する必要があるかを、テンプレートに定義するだけである。
この過程は以前の振る舞いの非常に多くを再利用するので、デルタ変更を支持するのに費やす時間は最小である。
専門化を可能としたXSLTスタイルシートを専門化されたDITAのトピックと一緒に使うためには、W3Cが定義したスタイルシート・リンク処理指示か、それとも処理ツール（普通は、saxonまたはxsltprocのようなXSLT処理ユーティリティ）の構成規則に従って、単純にそれをトピックに関係付けるだけである。