Exposé : principes d'adaptation de DITA

Configurer

• Intégrer des modules pour étendre (ou restreindre) le jeu d’éléments DITA disponibles

• Permet de supprimer tout ce que l’on ne veut pas voir apparaître

  • De façon générale

  • Dans des contextes particuliers (Contraindre modèles de contenus)

• Spécialiser

  • Ajouter de nouveaux domaines

  • Ajouter de nouveaux types de documents

• Dans les deux cas

  • En respectant méthode/architecture proposée par DITA

    • Pour un type de format de modélisation (DTD, XSD, Relax NG)

  • Toujours penser maintenance : pouvoir par la suite à nouveau configurer/spécialiser

Créer de nouvelles définitions de nouveaux éléments

• En s’appuyant sur des éléments de base existants

• Spécialisations structurelles

  • Nouveaux types de topics

  • Nouveaux types de maps

• Spécialisation de vocabulaires

  • Nouveau jeu d’éléments liés à un domaine d’utilisation

  • Nouveaux attributs (à partir de @base ou @props)‏

• La hiérarchie de spécialisation doit être explicite

  • Topic -> concept -> slide -> slide_intro

  • Permet des processus par défaut et des spécialisations de ces processus

  • Permet un échange sans obligatoirement avoir la connaissance de toutes les spécialisations

    • Echange de fichiers résolus

    • Ou échange de fichiers avec modèle, afin de pouvoir résoudre la hiérarchie

• Impose des contraintes liées :

  • à DITA

  • à la méthode utilisée pour spécialiser

Quand la spécialisation de type de documents a une réelle valeur ajoutée :

• Valeur en rédaction pour contraindre et limiter

• Valeur en publication pour ne pas avoir à gérer tous les cas d’usage

• Valeur supérieure à celle nécessaire à l’implémentation du type de document

Tout usage non-trivial de DITA nécessite une spécialisation pour :

• Contraindre des modèles de contenus trop laxistes

• Jouer sur les métadonnées

• Jouer sur la gestion du filtrage

• Jouer sur les taxonomies

Spécialiser des maps peut être utile :

• Même si les topics ne sont pas spécialisés

• Pour imposer des organisations

La spécialisation ne nécessite pas obligatoirement de changer d’outils :

• Simplement les adapter

• Et adapter les publications

Document type : spécialisation

• Structures spécifiques basées sur les topics de base

• Vocabulaires basés aussi sur les structures de base

• Contraintes sur les structures de base

  <learningOverview 
      id="overview_moduleI" 
      domains="(topic hi-d) (topic ut-d) … (topic learningBase learningOverview) "
      class="- topic/topic learningBase/learningBase learningOverview/learningOverview ">
      <title class="- topic/title ">Module I : introduction à DITA</title>
      ...

Document type shell :

• Représentation d’un document type

• Sous forme de DTD (ou Schema ou Relax NG)

• Aide à la génération de documents conformes

  • Structure de contenus et attributs DITA

<!DOCTYPE learningOverview 
    PUBLIC "-//OASIS//DTD DITA Learning Overview//EN" 
           "learningOverview.dtd"> 
<learningOverview id="overview_moduleI" xml:lang="fr"> …

Le document type shell (un fichier)

• N’est que l’agrégateur d’informations déclarées ailleurs dans d’autres fichiers

• L’outil de mise en place des spécialisations

Mais

• Basé sur des entités paramètres définies préalablement

  • Pour être sûr de la cohérence des définitions dans tous les shells

• Basé sur des déclarations d’élément définies à part

  • Réutilisation à nouveau dans les shells

Une limite : le standard ne prévoit pas de réutilisation des structures de construction des shells

• Un travail de maintenance important pour gérer la cohérence globale

Configurer

• Supprimer un domaine

• Contraindre

Configurer et spécialiser

• Ajouter un domaine

Spécialiser

• Attributs

• Topic

Et voir comment tout cela fonctionne dans le DITA-OT

• Prendre en compte des spécialisations

• Prendre en compte des modifications des processus de publication