Copyright © 2004-2023 Yves MARCOUX; dernière modification de cette page: 2023-02-09.
Yves MARCOUX - EBSI - Université de Montréal
La question se pose à la modélisation, c’est-à-dire au moment où l’architecte de documents crée un modèle XML apte à contenir l’information à gérer.
Une valeur d’attribut ne peut pas être validée de la même façon que le contenu d’un élément. Donc, pour pouvoir utiliser un attribut au lieu d’un sous-élément, il ne faut pas que les données à stocker aient une structure interne qu’il est important de valider. Également, on ne peut pas imposer aux attributs un « ordre d’apparition », comme on le peut avec les sous-éléments. Par exemple, on peut exiger qu’un sous-élément survienne comme premier sous-élément, comme dernier, etc. Mais la notion d’ordre d’apparition n’existe pas pour les attributs: on peut toujours mettre les spécifications d’attributs dans l’ordre que l’on veut dans une balise de début (pourvu qu’on n’essaie pas de spécifier deux fois le même attribut).
Si les données possèdent une structure logique importante à valider, ou si leur ordre d’apparition est important, alors il faut préserver ces aspects dans le modèle XML et on doit utiliser un sous-élément. Autrement, on a a priori le choix entre un sous-élément et un attribut. On choisira un attribut de préférence à un sous-élément si un des cas suivants s’applique :
Le contrôle de contenu n’est pas possible pour un élément textuel
(#PCDATA), mais il l’est pour un attribut, grâce au
type que l’on donne à l’attribut dans la déclaration
ATTLIST. Le type CDATA n’impose aucune
contrainte sur la valeur de l’attribut, mais les types énumérés et
NMTOKEN permettent de restreindre les valeurs possibles. Les
types énumérés, notamment, permettent de n’accepter qu’une valeur parmi une
liste fermée pré-établie de valeurs.
Il n’est pas possible de spécifier une « valeur par
défaut », ou un « contenu par défaut »,
pour un élément. Pour un attribut, cependant, on peut spécifier une valeur
par défaut pour l’attribut dans la déclaration ATTLIST (même si
ce n’est pas vu dans le Premier Tour d’horizon de XML). Lorsqu’une
valeur par défaut est spécifiée dans la déclaration, alors le fait de ne pas
spécifier l’attribut revient à le spécifier avec comme valeur la valeur par
défaut.
#PCDATA) ou mixte. Il faudrait alors intégrer
le sous-élément à un modèle de contenu mixte, ce qui rendrait la
validation trop permissive, étant donné la forme très restreinte que peut prendre
un modèle de contenu mixte (en l’occurrence, le sous-élément pourrait
apparaître un nombre arbitraire de fois n’importe où dans le texte ou
ne pas apparaître du tout). Le fait d’utiliser un attribut assurera que
l’information est spécifiée au plus une fois (puisqu’un même attribut ne peut être
spécifié plus d’une fois dans la même balise). De plus, le modèle de contenu de
l’élément auquel l’attribut est ajouté ne change pas (et donc, il ne devient ni
plus permissif, ni plus restrictif).En l’absence d’une de ces raisons, on choisira habituellement un sous-élément.
Les réflexions ci-dessus sont illustrées par des exemples dans le dossier
170-Ex-attribut-vs-sous-element des exemples du cours.
Les explications se trouvent dans le fichier nommé explications.html
du même dossier.
On veut représenter des montants d’argent, avec une indication de la devise
(200 $US, 150 €, etc.), de sorte que tant le montant que la devise soient clairement
et facilement identifiables. On a déjà déterminé que la valeur numérique du montant
sera dans un élément montant, déclaré (#PCDATA). On
voudrait ajouter quelque part une indication de la devise, suivant la norme ISO 4217, qui
propose des codes de trois lettres servant à identifier les devises. A
priori, on pourrait utiliser un sous-élément ou un attribut de
montant.
Avec un sous-élément, le contenu de montant deviendrait mixte :
<montant><devise>USD</devise>200</montant>
Il faudrait alors changer la déclaration de :
<!ELEMENT montant (#PCDATA)>
à :
<!ELEMENT montant (#PCDATA | devise)*>
puisque c’est la seule forme de modèle de contenu mixte en XML. Mais ce modèle de contenu serait trop permissif, le sous-élément pouvant apparaître un nombre arbitraire de fois, incluant zéro fois, ou plusieurs fois avec chaque fois une valeur différente, ouvrant la porte à des documents incohérents, comme dans les exemples suivants :
<montant>15000</montant>
<montant>250<devise>USD</devise>200<devise>MNT</devise></montant>
Le choix d’un attribut est donc ici clairement meilleur. Les deux déclarations
(incluant un commentaire doc: pour spécifier une info-bulle pour
l’attribut) seraient :
<!ELEMENT montant (#PCDATA)>
<!-- doc: Utiliser le code de devise à trois lettres de la norme ISO 4217
<https://www.currency-iso.org/dam/downloads/lists/list_one.xml> -->
<!ATTLIST montant devise NMTOKEN #REQUIRED>