classL'attribut class a une syntaxe particulière à respecter pour son traitement correct.
Chaque élément doit avoir un attribut class. L'attribut class commence par
un caractère SIGNE MOINS « - » s'il est déclaré dans un module structurel,
ou par un caractère SIGNE PLUS « + » s'il est déclaré dans un module de domaine. Après l'atome
d'entame se trouvent une ou plusieurs valeurs délimitées par des blancs, qui se terminent par un blanc. Chaque valeur a deux parties :
la première identifie un module de spécialisation, par exemple un type de thème ou un nom de domaine, et la seconde (après un
caractère BARRE OBLIQUE « / ») identifie un type d'élément. Les noms structuraux proviennent de
l'élément racine du type de thème ou du type de carte. Les noms de domaine sont définis dans le module de domaine.
Typiquement, l'attribut class devrait se déclarer comme une valeur d'attribut par défaut dans la
définition DTD ou le schéma plutôt que directement dans l'instance de document. L'auteur ne devrait pas
modifier l'attribut class.
Figure 1. Exemple d'élément de type structurel avec un attribut class
<appstep class="- topic/li task/step bctask/appstep ">A specialized step</appstep>
Figure 2. Exemple d'élément de domaine avec un attribut class
<wintitle class="+ topic/keyword ui-d/wintitle ">A specialized keyword</wintitle>
Lorsque l'attribut class est déclaré dans la définition DTD ou le schéma, on doit le déclarer
avec une valeur par défaut. Pour permettre les allers-retours de généralisation (généraliser un contenu spécialisé en une forme générique
puis le ramener à la forme spécialisée), la valeur par défaut ne doit pas être fixe. Cela permet au processus de généralisation
de remplacer les valeurs par défaut dans un type de document général par les valeurs spécialisées prises dans le document à généraliser.
Lorsqu'un type spécialisé déclare de nouveaux éléments, il doit fournir un attribut class pour
le nouvel élément. L'attribut class doit inclure une relation pour chaque type structuré ou domaine dans
l'ascendance du type spécialisé, même ceux où aucun renommage d'élément n'intervient. La relation devrait commencer par la valeur
du type de base (par exemple topic ou map) et finir par le type de l'élément courant.
Figure 3. Exemple d'attribut avec une valeur intermédiaire
<windowname class="- topic/kwd task/kwd guitask/windowname ">
Les valeurs intermédiaires sont nécessaires afin que les transformations de généralisation ou de spécialisation puissent associer
les valeurs simplement et précisément. Par exemple, si la valeur task/kwd manque et qu'un utilisateur décide
de généraliser cet élément guitask vers un thème de tâche, alors la transformation devra deviner s'il faudrait
le relier à kwd (approprié si task est plus général que guitask,
ce qui est le cas) ou le laisser comme windowname (approprié si task était plus spécialisé,
ce qui n'est pas le cas). En fournissant toujours les relations des valeurs plus générales, nous pouvons alors
appliquer la règle simple selon laquelle les relations manquantes doivent être par défaut vers des valeurs plus spécialisées que
celles vers lesquelles nous généralisons, ce qui signifie que la dernière valeur dans la liste est appropriée. Par exemple,
si l'on spécialise vers task, et qu'un élément p n'a pas de valeur cible pour
task, nous pouvons supposer sans risque que p n'est pas spécialisé de
task et ne devrait pas l'être.
Quoique cet exemple soit simple, les hiérarchies plus compliquées (disons à cinq niveaux de profondeur avec un renommage n'intervenant qu'au deuxième et quatrième niveau) rendent essentielles les valeurs intermédiaires explicites.
Un type spécialisé n'a pas besoin de changer l'attribut class des éléments qu'il ne spécialise pas
mais réutilise simplement par référence depuis des niveaux plus génériques. Par exemple, puisque les éléments
<task>, <bctask> et <guitask> utilisent l'élément <p>
sans le spécialiser, ils n'ont pas besoin d'en déclarer les relations.
Un type spécialisé déclare seulement les attributs class des éléments qu'il déclare particulièrement (uniquely).
Il n'a pas besoin de déclarer les attributs class des éléments qu'il réutilise ou dont il hérite.
Section parente 5.7. Spécialisation dans le contenu
Retour au sommaire.
OASIS DITA Version 1.1 Architectural Specification — OASIS Standard, 1 August 2007
Copyright © OASIS Open 2005, 2007. All Rights Reserved.