Lequel choisir: attribut XML ou sous-nœud?


15

Nous voulons exporter certaines données de notre base de données au format XML. Par exemple, un Personpeut avoir age, nameet d'autres propriétés.

Nous avons deux choix pour définir le format XML.

Choix n ° 1:

<Persons>
   <Person>
       <Age>16</Age>
       <Name>Richard</Name>
   </Person>
   <Person>
       <Age>34</Age>
       <Name>Eric</Name>
   </Person>
   ...
</Persons>

Choix n ° 2:

<Persons>
   <Person Age="16" Name="Richard"/>
   <Person Age="34" Name="Eric"/>
   ...
</Persons>

Alors, quelle est la différence entre la définition d'un sous-nœud ou d'un attribut? Et quel est l'avantage de chaque choix?



2
Bien que cela ait été demandé sur Stack Overflow en 2008 , cela semble être une décision de conception et est sur le sujet ici.
Thomas Owens

Réponses:


9

Il n'y a pas de documentation claire / meilleure pratique pour cela, mais, considérez les alternatives, comme vous l'avez:

En tant que texte d'élément:

  • il peut être plus facile d'afficher les données au format xhtml, etc., où le contenu du texte est considéré comme du texte, plutôt que du balisage ou des métadonnées.
  • il peut y en avoir plus d'un. Si vous avez besoin de contenu enfant avec plusieurs lignes d'âge ou de nom, les attributs ne le permettront pas
  • si vous avez besoin de métadonnées au niveau de la ligne, vous avez la possibilité d'utiliser les attributs de <name>ou <age>à cette fin

Comme attributs:

  • le XML est plus compact
  • XSLT et DocTypes sont plus simples à spécifier
  • vous n'avez pas à vous soucier des espaces (remplissage, retrait, sauts de ligne) ou d'autres éléments qui peuvent être introduits (commentaires, PI) dans les zones PCDATA (texte de l'élément)
  • il ne peut y en avoir qu'un! vous n'avez pas à vous soucier du contenu enfant contenant plusieurs ageattributs.

J'ai passé beaucoup de temps à travailler avec XML et, à mon avis, pour la communication de données pure, les attributs doivent être utilisés dans la mesure du possible. Si le XML est susceptible d'être utilisé pour la présentation (XSLT, xhtml, etc.), il peut être préférable en tant que contenu texte (mais pas nécessairement).


2
Ne vaut rien: si vous allez utiliser XSLT, il n'y a littéralement aucune raison de NE PAS utiliser d'attributs. Peut-être que si vous deviez faire quelque chose XML + CSS, ou si vous alliez utiliser le XSLT de quelqu'un d'autre ...
DougM

J'ai ajouté quelques points pour rendre votre bonne réponse un peu plus équilibrée, j'espère que vous êtes d'accord que cela l'améliore.
Doc Brown

9

Principes de conception XML: quand utiliser les éléments par rapport aux attributs par Uche Ogbuji d'IBM est probablement l'une des meilleures ressources en la matière.

Au cœur de la décision est que les attributs sont des choses «faites». Vous ne pouvez pas les changer ou les modifier ou les imbriquer. Ils sont indépendants de l'ordre et distincts dans l'élément (vous ne pouvez pas en avoir deux de la même chose).

Si l'une de ces contraintes est susceptible de changer, faites des données un nœud enfant du XML.

Dans votre exemple, vous avez une personne qui a un nom et un âge. J'ai un prénom, un prénom et un nom ... et un surnom. Et certaines personnes ont des noms de jeune fille, plusieurs prénoms ou des titres honorifiques - comment mettriez-vous John Ronald Reuel Tolkien dans une telle structure?

Et donc nous avons quelqu'un qui a deux prénoms qui ont un ordre pour eux. Cela devrait clairement montrer que non, un attribut n'est pas le meilleur choix pour cela.

Je ne le trouve pas actuellement, mais dans le document lié ci-dessus, il y a une déclaration selon laquelle les noms sont des choses qui nécessitent un peu de réflexion menant à "J'espère développer le traitement des noms de personnes dans le balisage dans un futur article." Si quelqu'un a une piste à ce sujet, veuillez laisser un commentaire ou le modifier à cet endroit.

D'un autre côté, l'âge est quelque chose qui a une structure plutôt fixe (je suggère l'anniversaire plutôt qu'un entier). En tant que tel, la représentation de ces informations dans un format bien connu et compris a du sens dans un attribut. Une personne a un et un seul anniversaire et il n'y a pas de «commande» que vous souhaitez conserver.

Uche Ogbuji identifie trois principes de base pour concevoir correctement un format xml. Les citations suivantes sont abrégées du document lié ci-dessus.

  • Principe de l'information structurée
    Si l'information est exprimée sous une forme structurée, surtout si la structure peut être extensible, utilisez des éléments. D'un autre côté: si les informations sont exprimées sous forme de jeton atomique, utilisez des attributs
  • Principe de lisibilité
    Si les informations sont destinées à être lues et comprises par une personne, utilisez des éléments. Si les informations sont le plus facilement comprises et digérées par une machine, utilisez des attributs.
  • Principe de la liaison élément / attribut
    Utilisez un élément si vous avez besoin que sa valeur soit modifiée par un autre attribut

Et donc, les noms doivent être des éléments - ce sont des données structurées qui ne sont pas un jeton atomique, elles sont plus susceptibles d'être lues par un humain qu'un ordinateur et elles peuvent être modifiées par un autre attribut sur le nom lui-même.

Les dates doivent être des attributs - ce sont des données qui sont un jeton atomique, elles sont plus susceptibles d'être lues par un ordinateur qu'un humain (puis transformées au format préféré de l'homme si besoin est ), et enfin, il est peu probable qu'elles soient modifiées par d'autres attributs sur eux.


2

Une autre considération au-delà de celles de Rolfl est le nombre de champs.
Plus qu'un petit nombre d'attributs devient un gâchis et difficile à lire (c'est en supposant que vous voulez que votre xml soit lisible par l'homme, mais en tant que programmeur, vous voudrez le faire pour tester au moins).

De plus, si vous vous attendez à ce que la structure des données de l'un des champs change avec le temps, n'en faites pas un attribut.
Par exemple, votre champ de nom. Peut-être qu'à l'avenir, cela deviendrait

<name>
  <firstName>George</firstName>
  <lastName>Orwell</lastName>
  <maidenName></maidenName>
  <nickName>Robert</nickName>
</name>

Si vous vous attendez à ce que cela se produise, en faire un attribut signifierait plus de refactoring de code plus tard.


merci pour ce bon point. Et pourquoi "en faire un attribut signifie plus de refactoring de code plus tard"?
ZijingWu

2

Pour la balise Personnes, il est normal d'avoir plus de balises de Personne, cela a du sens, une liste de Personnes a des entités, pas des attributs.

L'histoire est différente pour Person et ses composants. Une personne ne contient pas de nom, le nom est un attribut de la personne, donc je resterais avec des attributs au lieu de nouvelles balises. Les balises sont utiles lorsque vous avez des choses répétitives comme des adresses, vous ne pouvez pas le faire avec des attributs.

Si nous pensons dans le contexte HTML, vous n'avez pas d'entrée avec une étiquette de nom avec une valeur, n'est-ce pas?

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.