Spécialisation de structure contre spécialisation de domaine

La spécialisation structurelle définit de nouveaux types d'information structurée, ainsi des nouveaux types de thème ou de carte. La spécialisation de domaine crée un nouveau balisage qui peut être utile dans plusieurs types structuraux, ainsi de nouveaux types de mot-clé, de table ou de liste, ou de nouveaux attributs, tels que des attributs de traitement conditionnel.

Les types structuraux définissent les structures des modules d'information, tels qu'un concept ou une tâche ou une référence, qui s'appliquent souvent à travers les domaines (par exemple, une tâche de l'interface utilisateur et une tâche de programmation peuvents toutes deux se composer d'une série d'étapes). Lorsque de nouveaux éléments sont introduits au travers d'une spécialisation de structure, les éléments qui contiennent les nouveaux doivent aussi être spécialisés, et les nouveaux éléments conteneurs doivent avoir leurs conteneurs spécialisés à leur tour, et ce jusqu'à l'élément racine du module (par exemple, l'élément <topic> ou l'élément <map>).

Les domaines définissent typiquement le balisage d'un domaine ou d'un champ d'application particuliers, tels que la programmation ou le matériel. Les éléments de domaine sont disponibles partout où leurs éléments ancêtres sont permis, dès lors que les domaines sont intégrés aux spécialisations structurelles dans un type de document. Les attributs de domaine (fondés à partir des attributs props ou base) sont disponibles partout où les attributs props ou base sont permis.

Les hiérarchies de spécialisation de structure comme les hiérarchies de spécialisation de domaine sont des hiérarchies « est un » (as is), dans la terminologie orientée objet, chaque type structurel ou domaine étant une sous-classe de son parent. Par exemple, une spécialisation de tâche est toujours une tâche, et une spécialisation du domaine de programmation est toujours en rapport avec la programmation.

Les hiérarchies de structure et de domaine doivent partager un module de base commun pour être intégrées ensemble. Par exemple, les domaines à utiliser à travers des types de thème doivent en fin de compte être spécialisés à partir des éléments ou des attributs spécialisables dans l'élément <topic> ; les domaines à utiliser à travers les types de thème et les types de carte doivent être spécialisés à partir des éléments ou des attributs spécialisables communs aux deux types.

Hormis les modules de base communs (thème et carte), un domaine ne peut pas être spécialisé à partir d'un type structural. Par exemple, un domaine ne peut pas être spécialisé à partir des éléments dans un élément <task>, seulement à partir des modules structurels racines <topic> ou <map>. Cette règle assure l'intégration des domaines et la généralisation des types de document, de manière prévisible.

Les éléments et attributs créés par spécialisation ont leur portée définie (scoped) par le nom du type structurel ou du domaine dans lequel ils ont été déclarés. Pour les types structurels, le nom est le même que celui de l'élément racine, par exemple le type structurel dont l'élément racine est <task> a pour nom « task ». Pour les domaines, le nom n'est pas partagé avec un élément mais est attribué par le développeur de la spécialisation. Par convention, les noms de domaine se terminent par « -d » et sont courts, par exemple ui-d pour le domaine d'interface utilisateur et pr-d pour le domaine de programmation. Les domaines d'attribut forment un cas particulier, et sont nommés habituellement d'après l'attribut défini, en ajoutant « -a ».

Section parente 5. Spécialisation DITA

Section précédente 5.2. Pourquoi la spécialisation ?

Section suivante 5.4. Spécialisation d'un contenu étranger ou inconnu

Retour au sommaire.

5.3. Spécialisation de structure contre spécialisation de domaine