5.8.4. Modularisation dans les définitions DTD

En soutien de l'extensibilité et de la connectivité, DITA exige d'une implémentation DTD de modules de spécialisation de structure et de domaine qu'elle soit conforme à des modèles de conception bien définis.

Cette section décrit ces modèles de conception, qui réalisent l'architecture de la spécialisation avec les capacités et dans les limites de la grammaire DTD.

Modèle de spécialisation structurelle

Chaque type structurel doit être défini dans un module DTD séparé dont le nom se compose du nom de l'élément de thème et de l'extension « .mod ». Pour un exemple, cf. le module concepts.mod du type de thème concept.

Le module de type structurel doit se conformer au modèle de conception suivant.

Entités d'élément par défaut
Chaque élément défini dans le module doit avoir une entité correspondante dont la valeur par défaut est le nom de l'élément. L'exemple suivant provient de la définition du type de thème concept :
<!ENTITY % conbody "conbody">

L'interpréteur de type de document peut prédéfinir une entité d'élément afin d'ajouter des éléments spécialisés de domaine dans chaque contexte où l'élément de base appararaît.

Entité de domaines inclus par défaut
Un module doit définir l'entité included-domains avec une valeur par défaut vide comme dans l'exemple suivant :
<!ENTITY included-domains "">

L'interpréteur de type de document peut prédéfinir l'entité included-domains afin de lister les domaines ajoutés au type de document.

Entité de thèmes imbriqués par défaut
Les modules de type de thème doivent définir une entité info-types nommée, ayant pour préfixe le nom de l'élément de thème et pour suffixe « -info-types ». Cette entité peut avoir pour valeur par défaut une liste d'entités d'élément si le thème a des thèmes subordonnés par défaut. Si le thème n'a pas de thèmes subordonnés par défaut, l'entité peut avoir pour valeur par défaut celle de l'entité info-types comme dans l'exemple suivant :
<!ENTITY % concept-info-types "%info-types;">

L'interpréteur de type de document peut alors contrôler la façon dont les thèmes peuvent s'imbriquer en redéfinissant l'entité type-de-thème-info-types de chaque type de thème, ou créer rapidement des règles d'imbrication communes en redéfinissant l'entité info-types principale.

Modèle de contenu de l'élément racine du type structurel
Comme pour toutes les spécialisations, l'élément racine d'une spécialisation structurelle doit avoir un modèle de contenu qui restreint ou conserve le modèle de contenu de l'élément qu'il spécialise. En outre, pour les types de thème, la dernière position dans le modèle de contenu doit être l'entité des thèmes imbriqués comme dans l'exemple suivant :
<!ELEMENT concept        ((%title;), (%titlealts;)?, (%shortdesc;)?,
        (%prolog;)?, (%conbody;), (%related-links;)?, 
        (%concept-info-types;)* )>
Attributs
Comme pour toutes les spécialisations, les attributs de l'élément racine doivent restreindre ou conserver les attributs de l'élément qu'il spécialise. En particulier, le thème doit affecter l'attribut DITAArchVersion de la valeur de l'entité DITAArchVersion et l'attribut domains de celle de l'entité included-domains.
<!ATTLIST concept         id ID #REQUIRED
                          ...
                          DITAArchVersion CDATA "&DITAArchVersion;"
                          domains CDATA "&included-domains;"
>

Ces attributs donnent aux processus un moyen fiable de vérifier la version de l'architecture et de consulter la liste des domaines disponibles dans le type de document.

Définitions des éléments et attributs
Le module définit chaque élément spécialisé utilisé comme sous-structure dans le thème. Les éléments spécialisés doivent suivre les règles architecturales dans la définition des modèles de contenu et des attributs. Les modèles de contenu doivent utiliser des entités d'élément au lieu de noms d'élément littéraux.

En particulier, le module défini un attribut class pour chaque élément spécialisé. L'attribut class doit inclure la valeur de l'attribut class de l'élément de base et ajouter à la fin le nom de l'élément qualifié par le nom d'élément de thème, avec au moins un espace de tête et de queue. L'attribut class d'un élément introduit par une spécialisation structurelle doit commencer par un SIGNE MOINS « - ».

Modèle de spécialisation de domaine

Chaque spécialisation de domaine doit avoir deux fichiers :

Cf. les fichiers highlightDomain.ent et highlightDomain.mod pour un exemple.

Fichier de déclaration d'entité de domaine

Le fichier de déclaration d'entité de domaine doit être conforme au modèle de conception suivant :

Entité d'extension d'élément
Le fichier de déclaration doit définir une entité pour chaque élément étendu par le domaine. Le contenu de l'entité doit être la liste des éléments spécialisés de l'élément étendu. Le nom de l'entité a un préfixe qui est l'abréviation du domaine et un suffixe qui est le nom de l'élément étendu. Dans l'exemple suivant, le domaine de mise en exergue (highlighting), abrégé en hi-d, étend l'élément <ph>.
<!ENTITY % hi-d-ph "b | u | i | tt | sup | sub">
Entité de déclaration de domaine
Le fichier de déclaration doit définir une entité afin que l'interpréteur de type de document enregistre le domaine. Le nom de l'entité se compose d'un préfixe qui est l'abréviation du domaine et du suffixe « -att ». La valeur de l'entité doit lister les dépendances du module de domaine, en ordre de dépendance de gauche à droite, entre des parenthèses englobantes, en commençant par le module de thème et en listant les dépendances de domaine par leurs abréviations (y compris le domaine définissant comme dernier élément dans la liste). L'exemple suivant déclare la dépendance du domaine de mise en exergue (highlighting) par rapport au module de thème de base.
<!ENTITY hi-d-att "(topic hi-d)">

Module de définition de domaine

Le module de définition de domaine doit se conformer au modèle de conception suivant :

Entités d'élément par défaut
Comme dans un module de thème, le module de définition de domaine doit déclarer une entité par défaut pour chaque élément défini par le domaine afin que d'autres domaines puissent étendre les éléments.
<!ENTITY % b "b">
Définitions des éléments et attributs
Comme dans un module de thème, le module de définition de domaine doit définir chaque élément spécialisé et ses attributs. Comme pour toute spécialisation, l'élément de domaine doit restreindre l'élément de base. L'attribut class de l'élément de domaine doit commencer par un SIGNE PLUS « + », mais sinon suit les même règles que l'attribut class d'un élément introduit par une spécialisation de thème.

Modèle de spécialisation du domaine d'attribut

Le modèle de domaine d'attribut est un cas particulier du modèle de spécialisation de domaine, qui permet la création de nouveaux attributs spécialisés à partir des attributs props ou base.

Créez un fichier d'entité de module par attribut, par exemple newAttDomain.ent. Chaque module devrait contenir ce qui suit :

Entité d'extension d'attribut
L'entité qui contient la déclaration réelle de l'attribut dans la forme d'entité. Cette entité peut ensuite être utilisée dans des interpréteurs de type de document pour ajouter le nouvel attribut. Par exemple :
<!ENTITY % newAtt-d-attribute "new   CDATA #IMPLIED">
Entité de déclaration de domaine
L'entité qui contient le nom du domaine d'attribut dans une forme d'entité. Cette entité peut ensutie être utilisée dans des interpréteurs de type de document pour signaler la disponibilité de l'attribut aux processus compatibles avec DITA. Elle emploie la même syntaxe qu'une entité de déclaration de domaine régulière mais ajoute un « a » en tête pour indiquer qu'elle est dans un domaine d'attribut. Par exemple :
<!ENTITY newAtt-d-att       "a(props new)"  >

Modèle d'interpréteur de type de document

L'interpréteur de type de document doit se conformer au modèle de conception suivant. Cf. le module concepts.dtd du type de document de concept pour un exemple.

Inclusions d'entité de domaine
L'intepréteur de type de document commence par inclure les fichiers de déclaration d'entité de domaine. L'entité de la déclaration de domaine se compose d'un préfixe qui est le nom de domaine et du suffixe « -dec », comme dans l'exemple suivant :
<!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;
Redéfinitions d'extension d'élément
Pour chaque élément étendu par un ou plusieurs domaines, l'interpréteur de type de document redéfinit l'entité de l'élément vers une liste d'alternatives comprenant le nom littéral de l'élément et l'entité d'extension d'élément de chaque domaine fournissant des spécialisations.
<!ENTITY % pre
    "pre     | %pr-d-pre;     | %sw-d-pre;     | %ui-d-pre;">
Pour chaque attribut étendu par un ou plusieurs domaines, l'interpréteur de type de document redéfinit l'entité de l'attribut vers une liste d'alternatives comprenant le nom littéral de l'attribut et l'entité d'extension d'attribut de chaque domaine fournissant des spécialisations. Les attributs ne peuvent se spécialiser qu'à partir des attributs props ou base dans DITA 1.1.
<!ENTITY % props-attribute-extensions
        "%newAtt-d-attribute; 
         %othernewAtt-d-attribute;">
<!ENTITY % base-attribute-extensions
        "%newfrombaseAtt-d-attribute; 
         %othernewfrombaseAtt-d-attribute;">
Redéfinitions de l'imbrication des thèmes
Pour chaque type de thème, l'interpréteur de type de document peut contrôler l'imbrication des sous-thèmes en redéfinissant l'entité des thèmes imbriqués vers le nom d'élément littéral d'un des thèmes inclus dans le type de document. L'interpréteur de type de document peut également définir simplement l'entité info-types pour établir la valeur par défaut de la plupart des types de thème. Voici un exemple :
<!ENTITY % concept-info-types "concept">
Redéfinition de déclaration de domaine
L'interpréteur de type de document redéfinit l'entité included-domains afin de lister les domaines inclus dans le type de document comme dans l'exemple suivant :
<!ENTITY included-domains
    "&ui-d-att; &hi-d-att; &pr-d-att; &sw-d-att; &ut-d-att; &newAtt-d-att">
Inclusions de définition structurelle
L'interpréteur de type de document inclut les définitions des modules de type structurel utilisés dans le type de document. L'entité de la définition structurelle se compose du nom du type structurel avec le suffixe « -type », comme dans l'exemple suivant :
<!ENTITY % topic-type PUBLIC
    "-//OASIS//ELEMENTS DITA Topic//EN" "topic.mod">
    %topic-type;
Inclusions de définition de domaine
L'interpréteur de type de document inclut les définitions de domaine des domaines utilisés dans le type de document. L'entité de la définition de domaine se compose d'un préfixe qui est le nom de domaine et du suffixe « -def », comme dans l'exemple suivant :
<!ENTITY % hi-d-def PUBLIC
    "-//OASIS//ELEMENTS DITA Highlight Domain//EN" "highlightDomain.mod">
    %hi-d-def;
Il n'y a pas de fichiers de définition de domaine pour les domaines d'attribut.