5.6. Limites de la spécialisation

Parfois un nouveau type de structure ou de domaine ne semble pas entrer dans la hiérarchie existante, selon la sémantique des types existants et les restrictions du processus de spécialisation. On doit alors examiner diverses options.

Le mécanisme de spécialisation de base utilisé par les types de document DITA peut aussi servir pour des types de document non-DITA pour profiter des mêmes avantages de réutilisation, de spécialisation et d'échange offerts par les types de document DITA, mais restreints au domaine spécifique dans lequel les nouveaux types de document s'appliquent. Notez que même si l'on utilise les types définis par DITA comme point de départ, toute modification de ces types de base non accomplie au travers d'une spécialisation définit un type de document complètement nouveau, qui n'a pas de relation significative ou normative aux types de document DITA et qui ne peut pas être considéré d'une quelconque façon comme étant une application DITA conforme. En d'autres termes, l'utilisation de la spécialisation DITA à partir de types de base non-DITA ne produit pas des types de document conformes à DITA.

En revanche, vu les avantages substantiels de construction depuis les classes de basse DITA communes (y compris la capacité de généraliser vers un format commun, l'utilisation d'outils et de processus conformes aux standards et la réutilisation du contenu à travers les types de document, au travers de cartes DITA et de l'attribut conref), on doit examiner quelques techniques avant de se détourner complètement de l'architecture de contenu DITA.

Spécialiser à partir d'éléments ou d'attributs génériques

La première option à considérer est de choisir des éléments ou attributs de base plus génériques dans le jeu disponible. En DITA, des éléments génériques sont disponibles à chaque niveau de détail, depuis les thèmes génériques globaux en descendant jusqu'aux mots-clés génériques individuels, et on peut utiliser la base d'attributs génériques pour la spécialisation d'un domaine d'attribut.

Par exemple, si l'on veut créer un nouveau type de liste, sans y parvenir utilement en spécialisant des éléments <ul>, <ol>, <sl> ou <dl>, on peut créer un nouveau jeu d'éléments de liste en spécialisant des éléments <ph> imbriqués. Cette nouvelle structure de liste ne sera pas sémantiquement liée aux autres listes par ascendance, et demandera donc un traitement spécialisé pour recevoir un style de sortie approprié. Quoiqu'il en soit, elle restera une spécialisation DITA valide, avec une gestion standard de la généralisation, du référencement du contenu, du traitement conditionnel, et ainsi de suite.

Les éléments de base suivants dans l'élément <topic> sont suffisamment génériques pour soutenir presque toutes les spécialisations avec une structure valide :

topic

Toute unité de contenu qui a un titre et un contenu associé.

section

Toute division du contenu non imbriquante (non-nesting) au sein d'un thème, titré ou non.

p

Tout bloc de contenu non titré sous le niveau de la section.

fig

Tout bloc de contenu titré sous le niveau de la section.

ul, ol, dl, sl, simpletable

Tout bloc de contenu structuré qui se compose d'éléments listés en une ou plusieurs colonnes.

ph

Toute division de contenu sous le niveau du paragraphe.

keyword

Toute division non imbriquante du contenu sous le niveau du paragraphe.

data

Tout contenu conçu pour un traitement interne plutôt que pour une sortie intelligible.

foreign

Tout contenu ayant déjà un balisage non-DITA mais qui nécessite d'être créé comme une partie du document DITA.

unknown

Tout balisage non standard qui ne correspond pas au modèle DITA mais qui a besoin d'être géré comme une partie d'un document DITA.

Les attributs suivants dans l'élément <topic> sont aptes à une spécialisation de domaine en vue de fournir les nouveaux attributs qui sont exigés partout dans un type de document :

props

Tout nouvel attribut de traitement conditionnel.

base

Tout nouvel attribut qui est universellement disponible, a une syntaxe simple (valeurs alphanumériques délimitées par des espaces) et n'a pas déjà un équivalent sémantique.

On devrait autant que possible spécialiser à partir de la correspondance sémantique la plus proche. Si quelque exigence structurelle force à choisir un ancêtre plus général, veuillez en informer le comité technique : au cours du temps, un ensemble d'éléments génériques plus riche devrait être disponible.

Types de document restreints personnalisés pour la création

Le balisage DITA est organisé en modules de domaine et de type structurel, et les groupes de création peuvent facilement sélectionner le sous-ensemble de balisage dont ils ont besoin en créant un nouvel interpréteur (shell) de type de document. Toutefois si un groupe de création demande un sous-ensemble de règles de balisage qui ne respecte pas les frontières des modules de type (par exemple, la suppression globale de certains attributs ou éléments), on peut si nécessaire créer un type de document personnalisé pour le respect de ces règles lors de la création, tant que les types de documents sont validés en utilisant un type de document conforme aux standards lors du traitement.

On devrait créer un type de document restreint personnalisé (customized subset document type) sans éditer les modules de type. L'interpréteur du type de document peut passer outre les entités dans les fichiers de module, y compris les attributs et les modèles de contenu, en fournissant une nouvelle définition de l'entité préalablement à l'importation des fichiers de module.

Les types de document restreints personnalisés ne sont pas conformes au standard DITA et ne seront peut-être pas reconnus par les outils conformes aux standards. Par exemple, si on personnalise les types de document afin de supprimer l'élément <xref>, il ne sera peut-être pas possible d'utiliser des éditeurs DITA prêts à l'emploi pour créer son contenu.

Liaison d'un type de document personnalisé à DITA au cours du prétraitement

Bien que l'on puisse utiliser une spécialisation pour adapter les types de document à plusieurs objectifs de création différents, certaines exigences de création ne peuvent pas être remplies au travers d'une spécialisation, en particulier séparer ou renommer les attributs, ou renommer les éléments au travers d'une spécialisation sans spécialiser aussi leurs conteneurs.

Aux cas où la spécialisation de structure ou de domaine des éléments ou attributs ne suffit pas, et où le nouveau type de document peut être transformé de manière directe et fiable en un type de document standard, le groupe de création sera peut-être mieux servi par un type de document personnalisé qui est transformé en un type de document standard dans le flux de publication. Par exemple, si un groupe de création a besoin que l'élément <p> s'écrive <paragraph>, le type de document pourrait être personnalisé afin d'y changer <p> en <paragraph> puis prétraité afin de renommer les éléments <paragraph> en <p> avant d'injecter les documents dans un processus de publication standard.

On devrait créer un type de document personnalisé sans éditer les modules de type. L'interpréteur du type de document peut passer outre les entités dans les fichiers de module, y compris les attributs et les modèles de contenu, en fournissant une nouvelle définition de l'entité préalablement à l'importation des fichiers de module de type.

Les types de document personnalisés ne sont pas conformes au standard DITA et ne seront peut-être pas reconnus par les outils conformes aux standards. Un prétraitement peut assurer la compatibilité avec les processus de publication existants mais n'assure pas la compatibilité avec les outils de création ou les systèmes de gestion de contenu compatibles avec DITA. En revanche, lorsqu'une mise en œuvre est fortement personnalisée en tout cas, un type de document personnalisé peut aider à isoler et contrôler les implications d'une conception non standard dans une mise en œuvre personnalisée.

OASIS DITA Version 1.1 Architectural Specification — OASIS Standard, 1 August 2007
Copyright © OASIS Open 2005, 2007. All Rights Reserved.