[Rédigé par Tanguy Wettengel] 

Avant de comparer TIM avec DITA, soulignons que l'un comme l'autre peuvent  être considérés comme des méthodes de description d'environnements techniques où un travail est censé se dérouler. La comparaison qui suit examine, en particulier, leurs approches respectives de la représentation de l'activité au moyen d'une structure de tâches.

Il existe des logiciels capables d'assister cette analyse, d'en publier le résultat (manuels, aides en ligne, etc.) ou de le stocker dans une base de données sous forme de modules à assembler lors d'une publication ultérieure : plusieurs éditeurs XML pour DITA, TimBox, pour TIM. Ces logiciels produisent des fichiers XML (à stocker ou à transformer pour la publication PDF, HTML, etc.) et la structure de leur contenu est définie par une ou plusieurs DTD interconnectées, parfois aussi par des Schémas.

Dans le cas de TIM, cette DTD n'est pas l'unique expression formelle de la description : un langage de modélisation autonome (Task-oriented Information Modelling Language), conçu et optimisé entre 1992 et 1999, a permis de tester TIM dans des domaines variés, du logiciel à la machine-outil en passant par l'analyse de process. Ce langage décompose fortement les expressions intégrées dans les modèles, toutes construites à partir de trois primitifs ("objet", "facette", "opération") et ouvre la voie à des applications où l'analyse de l'activité est conduite par combinaison d'entités stockées dans des bibliothèques, au lieu de reposer sur l'utilisation du langage naturel.

DITA

DITA (Darwin Information Typing Architecture) est un dispositif permettant de valider des fichiers XML. La (ou les) DTD DITA encapsule(ent) un méta-modèle d'information conçu pour définir le contenu de certains types de documents techniques. Tout comme TIM, DITA met la tâche au centre de ce méta-modèle. Pourtant, les approches de DITA et de TIM sur le contenu du méta-modèle sont très différentes : alors que TIM en exclut toute considération sur l'aspect des documents à publier, DITA permet de piloter l'apparence que le contenu prendra lors de la publication (segmentation du document -sections, paragraphes, etc.-, présentation de l'information, -listes, tableaux, etc.-).

Ce choix invite l'analyste travaillant sous DITA à se placer simultanément dans le rôle d'expert de son domaine (électronique, médecine, informatique, etc.) et dans celui d'un rédacteur technique. Même si cette double compétence semble improbable, la tâche de l'analyste-rédacteur aurait sans doute bénéficié d'une séparation claire de ces deux domaines d'intervention (le travail obéissant à la logique du métier, d'un côté, celui engageant la logique de la publication, de l'autre). Pour cela, il eût fallu dissocier nettement la couche "métier" de celle relative à la mise en forme.

Or, ces couches sont relativement adhérentes, comme le souligne le graphique ci-dessous : la structure prévue pour définir des termes ("definition of terms"), par exemple, est un sous-type de "liste" ; les commandes données en référence sont liées au formats "tableau" et "liste".

 

Il y a également une dissymétrie surprenante entre les types de catégorie associés à l'unité de contenu ("topic") de type "concept" et au celle de type "tache" : alors que les derniers sont en général porteurs de valeurs sémantiques relatifs au genre d'information qu'ils expriment ("prerequisite", "steps", "substeps", "result", etc. apparaissent comme l'articulation sémantique d'une tâche),  les premiers, exception faite de "definition of terms" et "example", en sont presque entièrement dénués.

Ce déséquilibre réduit la notion d'"élément"à un simple facteur de décomposition des unités de contenu ("topics"), sans propriétés constantes (il définit tantôt le mode de présentation du contenu ou la segmentation d'un document, tantôt les constituants d'une tâche d'un point de vue sémantique), et met la structure documentaire (celle de l'unité de type "concept" mais aussi celle de l'unité de type "référence") au même niveau que la structure orientée-métier (unité de type "tâche"). Autrement dit, tantôt on raisonne en termes de décomposition formelle d'un document (section, paragraphe, liste, etc.), tantôt en termes de décomposition sémantique d'une activité (étape, sous-étape, résultat d'étape, etc.).

Pour terminer, notons que le critère permettant de séparer les types d'unité (concept, référence, tâche) est difficile à comprendre : alors que "tâche" se distingue facilement de ce qui relève d'informations nécessaires à l'exécution de la tâche (connaissances générales du domaine, résumé des paramètres, commandes, etc.), la différence entre "concept" et "référence" est d'une tout autre nature. En effet, du point de vue de la signification des contenus qu'ils intègrent, rien n'interdirait de fondre ces deux types de concept en un seul. La distinction est faite pour marquer le caractère auxiliaire de ce qui apparaît sous "référence", il s'agit ainsi d'un contrast d'usage et non d'une distinction fondée sur le sens.

Même si le mécanisme dit de "Specialisation" permet de modifier la structure du contenu des trois unités de contenu de base DITA (concept, référence, tâche) et de l'adapter ainsi à des besoins spécifiques, le modèle  générique de ces sujets affiche une forte superposition de la gestion de la présentation et de celle de la structure du contenu. Contrairement à TIM, DITA ne définit pas de limites prècises entre la construction des modèles et la publication de documents.

TIM

TIM est un environnement permettant la modélisation du travail dans des contextes divers. Les modèles bâtis sous TIM peuvent être utilisés pour fournir le contenu des documents de guidage (manuels, aides, etc.) mais aussi pour planifier des processus de production ou pour définir des cahiers de charges fonctionnels d'équipements et logiciels. TIM n'est donc pas un outil pour rédiger des documents, c'est une méthode de description du travail à des fins multiples. La dissociation entre le langage de modélisation de l'activité et la production de documents à partir des modèles obtenus explique que l'on ne trouve dans TIM aucun moyen pour définir la mise en forme de l'information.

Il n'est donc pas surprenant que le méta-modèle d'une tâche TIM soit exclusivement peuplé de notions relatives à l'analyse sémantique du travail, telles que Entrée, Sortie, Procédure, etc., comme l'illustre l'image ci-dessous.

Les informations relatives à l'engagement d'une tâche comprennent les pré-requis d'engagement ("Accès"), l'objectif (représenté par la polarité entre l'"Entrée" et la "Sortie") et les répercussions de l'engagement de la tâche sur l'environnement global ("Impact"). Une tâche décomposée distribue l'activité nécessaire pour le passage de l'Entrée à la Sortie en sous-tâches, alors qu'une tâche de dernier niveau (non-décomposée) les exprime au moyen d'une liste d'actions, appelée "Procédure".

Les informations concernant l'engagement d'une tâche sont des "descriptions", toujours exprimées sous la forme d'états ou de propriétés. Les états et les propriétés se distinguent du fait que les états sont réversibles (la situation où une vanne est ouverte, par exemple, si elle peut également être fermée), alors que les propriétés sont persistantes (la capacité de la vanne, par exemple). Etats et propriétés sont construits dans le modèle en combinant des objets (ici, la vanne), avec des facettes (des descriptions partielles d'objets, comme leur statut à un moment T [ouvert, fermé] ou leur capacité exprimée en litres par seconde, par exemple).

Une tâche est placée dans une arborescence. Lorsqu'elle est décomposée, les sous-tâches qu'elle comporte peuvent être obligatoires ou optionnelles et comporter ou non des conditions d'engagement (celles qui en possèdent sont dites "conditionnelles"). Une tâche de l'un des types cités, si elle doit être répétée tant qu'une condition placée dans l'Accès n'est pas satisfaite, est dite "cyclique".

Par ailleurs, des tâches décomposées de façon à ce que l'une seule des décomposantes soit nécessaire pour assurer le passage de l'Entrée à la Sortie sont appelées "Alternatives" dans TIM. A noter qu'une structure de tâches TIM inclut toute l'information sur les séquences obligatoires, les options, les alternatives et les mises sous condition de  l'engagement de certaines tâches, et que l'enrichissement de l'arborescence par un "plan" externe (du type Hyerachical Task Analysis - HTA -) ne sont pas nécessaires.

Le formalisme permettant de  construire l'ensemble de cette architecture est obtenu par la combinaison de trois primitifs : les objets, les facettes et les opérations. Les objets sont les entités manipulées, les facettes représentent l'une de leur caractéristiques en situation et les opérations, les manipulations que les objets subissent  :

Le périmètre d'une tâche (accès, entrée, sortie, impact) est constitué de descriptions (états et/ou propriétés) ; les actions, associées uniquement aux tâches de dernier niveau, représentent la composante opérative de la tâche, appelée "procédure". L'objectif d'une tâche apparaît dans la polarité entre l'entrée et la sortie et permet de distinguer les sous-tâches obligatoires des optionnelles dans une situation donnée. Le contenu de l'accès indique si une tâche peut être engagée en toute circonstance, ou bien si elle conditionnelle ou cyclique. Le texte enbleu dans la figure suivante exprime le modèle syntaxique d'une tâche simple.

Toutefois, le modèle complet de cette tâche en TIM ne comporte que l'information suivante :

La position des éléments dans le modèle définit la catégorie à laquelle ils appartiennent (dans l'ordre, accès, entrée, sortie, impact et procédure). La combinaison de la valeur sémantique des expressions et ce celle de la catégorie à laquelle ils appartiennent rendent possible une traduction fidèle en langage naturel : dans l'exemple ci-dessus, l'accès est traduit par "l'icône du fichier cible doit être affiché", "doit" interprétant le fait que cette description est placée dans l'accès. En outre, le fait que l'accès de cette tâche ne soit pas vide, indique qu'il  s'agit d'une tâche conditionnelle.

CONCLUSION

DITA est un environnement conçu pour la production de contenus diversifiés en vue de leur publication sous forme de documents techniques Nous nous sommes interrogés ici sur les performances de cette architecture dans le domaine de la modélisation de contenus, en particulier celle des tâches. Nous avons souligné la forte imbrication entre les catégories relevant de la structure documentaire ainsi que de la présentation matérielle de l'information et les catégories décrivant cette information du point de vue sémantique. La prééminence de la perspective liée à la publication nous incline à considérer DITA comme un outil de structuration de contenus documentaires et non comme un environnement de modélisation du travail.

TIM  ne comporte aucun élément en rapport avec la publication de contenus. C'est un environnement exclusivement dédié à la modélisation de l'activité à l'aide d'un ensemble de catégories sémantiquement identifiées. Ces catégories sont exprimées dans un modèle à l'aide d'une structure syntaxique contrainte par un langage formel. Ce langage comporte l'ensemble des symboles disponibles ainsi que les règles définissant les combinaisons autorisées. Le seul type de contenu pouvant être traité par TIM est une structure de tâches.