Discussion :

[clavier12AZQSWX]

bonjour,

je viens de lire l'excellent tutoriel de dvp :
http://gilles-chagnon.developpez.com/cours/xml/concepts-de-base/#LIII-D-4

mais il n'a pas répondu à une question que j'ai depuis longtemps, sans réponse.

quelle différence entre formaliser cela :

<personnes>
<individu genre="masculine" age="28">
<nom>michael</nom>
<prenom>toto</prenom>
</individu>
</personnes>

et le formaliser comme cela :


<personnes>
<individu>
<genre>masculin</genre>
<age>28</age>
<nom>michael</nom>
<prenom>toto</prenom>
</individu>
</personnes>


y-a-t-il une grande différence ?

[Mac LAK]

Usuellement, un attribut est unique (au sein de l'élément), tandis qu'un élément existe potentiellement en plusieurs exemplaires.
De plus, il n'est pas possible bien sûr de définir un attribut sans l'élément dont il fait partie !

Dans ta première formalisation, le genre et l'âge peuvent être omis si besoin, mais ne peuvent pas être renseignés hors d'une balise <individu> (bon, ça va, une personne a rarement plus d'un âge et plus d'un genre, ce n'est guère gênant).
Dans la seconde, ils peuvent éventuellement exister en plusieurs exemplaires, et ça, ça peut devenir gênant.

Pour un cas aussi simple que le tien, cela n'a guère d'importance, mais la formulation <individu nom="michael" prenom="toto" genre="masculine" age="28"/> serait tout aussi efficace (en fait même plus efficace) et moins lourde en cadeau-bonus.

Cela devient nettement plus problématique dans le cas de collections importantes décrites en XML, ou de dépendances complexes (quand une clé conditionne la présente d'autres informations notamment).

Exemple : si ton élément XML décrit un fichier, la donnée "pathname" n'est pas vraiment une donnée accessoire ou optionnelle, donc autant la mettre en attribut obligatoire (mandatory). Par contre, le type du fichier (binaire, texte, PDF, ...), ou des informations additionnelles (résumé, taille, etc.) sont des éléments optionnels et/ou inconnus et/ou pouvant avoir plusieurs sens ou valeurs : tu en feras donc des entités optionnelles, le choix entre attribut et sous-éléments se faisant sur l'unicité (ou pas) de l'information. La taille du fichier, par exemple, est unique à priori, donc serait un attribut, tandis que le "résumé" du document peut avoir plusieurs aspects (titre, aperçu texte formaté ou non, aperçu image, ...) et serait donc un sous-élément.

Après, tu peux partir du principe qu'un attribut contient les informations "uniques", connexes et requises par la présence même d'un élément, tandis que l'élément est plutôt réservé pour les données pouvant exister en plusieurs exemplaires. Cela te donnera un bon schéma dans la plupart des cas.

Ceci étant dit, on peut discourir pendant des pages sur les subtilités entre éléments et attributs : je t'ai donné une vision des choses, en tant qu'utilisateur XML "normal", il y a sûrement plein d'autres cas particuliers, avantages et inconvénients entre les deux entités.

[clavier12AZQSWX]

merci !

j'avais aussi remarqué qu'en général, une structure xml est plus longue à traiter quand il y a bcp de tag encapsulés qui s'enchainent en arbre...

donc en résumé le choix de passer une propriété en "attribut" ou en "tag" n'est fonction que du nombre (one2many).

c'est aussi ce que je me disais au départ, mais je n'ai trouvé aucune version officielle aucun court qu idit de faire plutôt que ça...

c'est donc juste une question de bon sens et non sémantique!

[Mac LAK]

Exactement, du simple bon sens, plus effectivement la notion de cardinalité des données.
Si XML te pourrit la vie, dis-toi qu'il y a de fortes chances que ce soit un mauvais schéma qui en soit la cause plutôt que le format XML en lui-même !!


(Je ne parles pas du décodage de l'XML lui-même, qui dépend de la librairie/techno que tu vas utiliser pour lire/écrire ton XML, mais bien de stocker efficacement les données dedans).

[GrandFather]

c'est donc juste une question de bon sens et non sémantique!

Il y a quand même quelques subtilités lexicales qui peuvent dans certains cas influer sur le choix, au delà des considérations sémantiques (liste non exhaustive) :

• La structure <![CDATA[]> n'est pas disponible pour les attributs ; les caractères <, >, & présents dans les valeurs d'attributs doivent donc toujours être convertis en références de caractères ou en leurs entités
• Il y a normalisation des espaces lors de l'analyse (parsing) de la valeur des attributs (les retour-chariots, tabulations, etc. sont remplacés par des espaces) et il y a suppressions des espaces de début et de fin si l'attribut n'est pas déclaré comme un CDATA dans la DTD
• Il est possible avec les DTD de définir des valeurs par défaut pour des attributs absents d'un document, ce n'est pas possible avec les éléments
• Le type de contenu ID qui permet de définir des identifiants uniques dans les DTD n'existe que pour les attributs
• Les valeurs d'attributs sont insérés entre simples ou doubles quotes ; si la valeur de l'attribut contient un de ces mêmes caractères de délimitation, il faudra le remplacer par son entité ou sa référence de caractère.

Généralement, ces nuances ont peu d'importance, les outils de sérialisation XML et les parsers se chargent pour nous des détails sordides. Si par contre le XML est produit d'une autre manière, plus « artisanale », alors il vaut mieux connaître ces subtilités...

Sur la question choix attribut/élément, l'usage est de placer en attribut les metadonnées d'un élément, i.e. une information sur l'élément lui-même et non une information délivrée par l'élément. Par exemple : l'attribut xml:lang qui indique au lecteur (humain ou non) la langue dans laquelle est rédigé le contenu de l'élément, mais ne fait pas partie de ce contenu.