Devrais-je utiliser des éléments ou des attributs en XML?
J'apprends/ Attributs XML de W3Schools .
L'auteur mentionne ce qui suit (c'est moi qui souligne):
Éléments XML vs attributs
<person sex="female"> <firstname>Anna</firstname> <lastname>Smith</lastname> </person><person> <sex>female</sex> <firstname>Anna</firstname> <lastname>Smith</lastname> </person>Dans le premier exemple, le sexe est un attribut. Dans le dernier, le sexe est un élément. Les deux exemples fournissent les mêmes informations.
Il n'y a pas de règles concernant le moment d'utiliser les attributs et le moment d'utiliser les éléments. Les attributs sont pratiques en HTML. En XML, mon conseil est de les éviter. Utilisez des éléments à la place.
Éviter les attributs XML?
Certains des problèmes d'utilisation des attributs sont les suivants:
- les attributs ne peuvent pas contenir plusieurs valeurs (les éléments peuvent)
- les attributs ne peuvent pas contenir d'arborescence (les éléments peuvent)
- les attributs ne sont pas facilement extensibles (pour les modifications futures)
Les attributs sont difficiles à lire et à maintenir. Utilisez des éléments pour les données. Utilisez des attributs pour les informations qui ne sont pas pertinentes pour les données.
La vue de l'auteur est-elle donc célèbre ou s'agit-il de la meilleure pratique en XML?
Les attributs en XML doivent-ils être évités?
W3Schools a également mentionné ce qui suit (c'est moi qui souligne):
Attributs XML pour les métadonnées
Parfois, les références ID sont attribuées à des éléments. Ces identifiants peuvent être utilisés pour identifier des éléments XML de la même manière que l'attribut ID en HTML. Cet exemple montre ceci:
<messages> <note id="501"> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note> <note id="502"> <to>Jani</to> <from>Tove</from> <heading>Re: Reminder</heading> <body>I will not</body> </note> </messages>L'ID ci-dessus n'est qu'un identifiant permettant d'identifier les différentes notes. Ce n'est pas une partie de la note elle-même.
Ce que j'essaie de dire ici, c'est que les métadonnées (données sur les données) doivent être stockées sous forme d'attributs et que les données elles-mêmes doivent être stockées sous forme d'éléments.
L'utilisation des attributs ou des éléments est généralement décidée par les données que vous essayez de modéliser.
Par exemple, si une certaine entité estUNE PARTIEdes données, il est conseillé d'en faire un élément. Par exemple, le nom de l'employé est une partie essentielle de ses données.
Maintenant, si vous voulez transmettreM&EACUTE;TADONN&EACUTE;ESà propos de données (quelque chose qui fournit des informations supplémentaires sur les données) mais ne fait pas vraiment partie des données, il vaut mieux en faire un attribut . Supposons que chaque employé dispose d'un GUID nécessaire pour le traitement final, ce qui en fait un attribut est préférable.
Aucune règle en tant que telle stipule que quelque chose doit être un attribut ou un élément.
Il n’est pas nécessaire d’éviter à tout prix les attributs. Ils sont parfois plus faciles à modéliser que les éléments. Cela dépend vraiment des données que vous essayez de représenter.
Le moins important est que le fait de placer des éléments dans des attributs permet d’obtenir un XML moins détaillé.
Comparer
<person name="John" age="23" sex="m"/>
Contre
<person>
<name>
John
</name>
<age>
<years>
23
</years>
</age>
<sex>
m
</sex>
</person>
Oui, c'était un peu partial et exagéré, mais vous comprenez le point
Mon 0.02 cinq ans après le PO est exactement le contraire. Laisse-moi expliquer.
- Utilisez des éléments lorsque vous regroupez des données similaires et des attributs de Ces données.
- N'utilisez pas d'éléments pour tout.
- Si les données se répètent (1 à plusieurs), c'est probablement un élément
- Si les données ne se répètent jamais et n'ont de sens que lorsqu'elles sont corrélées à , C'est un attribut.
- Si les données n'ont pas d'autres attributs (c'est-à-dire un nom), alors c'est un attribut
- Regroupez les éléments similaires pour prendre en charge l'analyse de collection (c'est-à-dire/xml/character)
- Réutilisez des noms d'éléments similaires pour prendre en charge l'analyse des données
- Jamais, jamais , utilisez des nombres dans les noms d'éléments pour afficher la position. (c'est-à-dire caractère1, caractère2) Cette pratique rend très difficile l'analyse (voir n ° 6, le code d'analyse doit/caractère1,/caractère2, etc. pas simplement/caractère.
Considéré d'une autre manière:
- Commencez par considérer tout vos données comme un attribut.
- Regroupez logiquement les attributs en éléments. Si vous connaissez vos données, vous aurez rarement besoin de convertir un attribut en élément. Vous savez probablement déjà quand un élément (collection ou données répétées) est nécessaire
- Regrouper logiquement les éléments
- Lorsque vous rencontrez le cas, vous devez développer, ajouter de nouveaux éléments/attributs en fonction de la structure logique du processus ci-dessus. L'ajout d'une nouvelle collection d'éléments enfants ne "brisera" pas votre conception et sera plus facile à lire au fil du temps.
Par exemple, en regardant une simple collection de livres et de personnages principaux, le titre n'aura jamais "enfants", c'est un élément simple. Chaque personnage a un nom et un âge.
<book title='Hitchhiker's Guide to the Galaxy' author='Douglas Adams'>
<character name='Zaphod Beeblebrox' age='100'/>
<character name='Arthur Dent' age='42'/>
<character name='Ford Prefect' age='182'/>
</book>
<book title='On the Road' author='Jack Kerouac'>
<character name='Dean Moriarty' age='30'/>
<character name='Old Bull Lee' age='42'/>
<character name='Sal Paradise' age='42'/>
</book>
Vous pourriez soutenir qu'un livre pourrait avoir plusieurs auteurs. OK, développez-le simplement en ajoutant de nouveaux éléments d’auteur (supprimez éventuellement le @author original). Bien sûr, vous avez cassé la structure d'origine, mais dans la pratique, c'est assez rare et facile à contourner. Tout consommateur de votre code XML original qui suppose un seul auteur devra quand même changer (ils sont probablement en train de changer leur base de données pour déplacer l'auteur d'une colonne du tableau "livre" vers un tableau "auteur").
<book title='Hitchhiker's Guide to the Galaxy'>
<author name='Douglas Adams'/>
<author name='Some Other Guy'/>
<character name='Zaphod Beeblebrox' age='100'/>
<character name='Arthur Dent' age='42'>
<character name='Ford Prefect' age='182'/>
</book>
J'ai utilisé Google pour rechercher la question exacte. J'ai d'abord abordé cet article, http://www.ibm.com/developerworks/library/x-eleatt/index.html . Bien que cela ait semblé trop long pour une simple question en tant que telle. Quoi qu'il en soit, j'ai lu toutes les réponses à ce sujet et je n'ai pas trouvé de résumé satisfaisant. En tant que tel, je suis revenu à ce dernier article. Voici un résumé:
Quand est-ce que j'utilise des éléments et quand est-ce que j'utilise des attributs pour présenter des informations?
- Si les informations en question peuvent être elles-mêmes marquées avec des éléments, mettez-les dans un élément.
- Si les informations conviennent à la forme d'attributs, mais peuvent se retrouver sous la forme d'attributs multiples du même nom sur le même élément, utilisez plutôt des éléments enfants.
- Si les informations doivent appartenir à un type d'attribut standard de type DTD, tel que ID, IDREF ou ENTITY, utilisez un attribut.
- Si les informations ne doivent pas être normalisées pour les espaces, utilisez des éléments. ( Les processeurs XML normalisent les attributs de manière à pouvoir modifier le texte brut de la valeur de l'attribut.)
Principe du contenu de base
Si vous estimez que les informations en question font partie de la matériel essentiel exprimé ou communiqué dans le XML, mettez-le dans un élément. Si vous considérez que les informations sont périphériques ou accessoire à la communication principale, ou purement destiné à aider les applications traitent la communication principale, utilisent des attributs.
Principe de l'information structurée
Si les informations sont exprimées sous une forme structurée, en particulier si la structure peut être extensible, utiliser des éléments. Si l'information est exprimé comme un jeton atomique, utilisez des attributs.
Principe de lisibilité
Si les informations sont destinées à être lues et comprises par une personne, utiliser des éléments. Si l’information est plus facilement comprise et digéré par une machine, utilise des attributs.
Principe de liaison élément/attribut
Utilisez un élément si vous avez besoin que sa valeur soit modifiée par un autre attribut. [..] c'est presque toujours une idée terrible de laisser un attribut en modifier un autre.
Ceci est un bref résumé des éléments importants de l'article. Si vous souhaitez voir des exemples et une description complète de chaque cas, reportez-vous à l'article original.
Mappage de modèle d'attributs. Un ensemble d'attributs sur un élément est isomorphisé directement sur une carte nom/valeur dans laquelle les valeurs sont du texte ou tout type de valeur sérialisable. En C #, par exemple, tout objet Dictionary<string, string> peut être représenté sous forme de liste d'attributs XML, et inversement.
Ce n'est absolument pas le cas avec les éléments. Bien que vous puissiez toujours transformer une carte nom/valeur en un ensemble d’éléments, l’inverse n’est pas le cas, par exemple:
<map>
<key1>value</key1>
<key1>another value</key1>
<key2>a third value</key2>
</map>
Si vous transformez cela en une carte, vous perdrez deux choses: les multiples valeurs associées à key1 et le fait que key1 apparaisse avant key2.
La signification de ceci devient beaucoup plus claire si vous regardez le code DOM utilisé pour mettre à jour des informations dans un format comme celui-ci. Par exemple, il est trivial d’écrire ceci:
foreach (string key in map.Keys)
{
mapElement.SetAttribute(key, map[key]);
}
Ce code est concis et sans ambiguïté. Contrastez-le avec, dites:
foreach (string key in map.Keys)
{
keyElement = mapElement.SelectSingleNode(key);
if (keyElement == null)
{
keyElement = mapElement.OwnerDocument.CreateElement(key);
mapElement.AppendChild(keyElement);
}
keyElement.InnerText = value;
}
Vous ne pouvez pas mettre un CDATA dans un attribut. D'après mon expérience, tôt ou tard, vous voudrez mettre des guillemets simples, des guillemets doubles et/ou des documents XML entiers dans un "membre". Si c'est un attribut, vous maudirez la personne qui les a utilisés. des éléments.
Remarque: mon expérience avec XML concernait principalement le nettoyage des autres utilisateurs. Ces personnes semblaient suivre le vieil adage "XML, c'est comme la violence. Si son utilisation n'a pas résolu votre problème, vous n'en avez pas suffisamment utilisé".
Tout dépend de ce que XML est utilisé pour. Lorsqu'il s'agit principalement d'interopérabilité logiciel/machine, tels que les services Web, il est plus facile d'utiliser tous les éléments, ne serait-ce que par souci de cohérence (et certains frameworks le préfèrent, par exemple WCF). Si elle est destinée à la consommation humaine - c’est-à-dire créée et/ou lue principalement par des personnes -, une utilisation judicieuse des attributs peut considérablement améliorer la lisibilité; XHTML est un exemple raisonnable de cela, ainsi que XSLT et XML Schema.
Je travaille généralement sur la base que les attributs sont métadonnées - c'est-à-dire des données sur les données. Une chose que j'évite, c'est de mettre des listes dans les attributs. par exemple.
attribute="1 2 3 7 20"
Sinon, vous disposez d'un niveau d'analyse supplémentaire pour extraire chaque élément. Si XML fournit la structure et les outils pour les listes, pourquoi en imposer un autre vous-même.
Un scénario dans lequel vous pouvez préférer coder pour des attributs concerne la vitesse de traitement via un analyseur SAX. En utilisant un analyseur SAX, vous obtiendrez un rappel d’élément contenant le nom de l’élément et la liste des attributs. Si vous aviez utilisé plusieurs éléments à la place, vous obtiendrez plusieurs rappels (un pour chaque élément). Le fardeau/temps qui en découle fait l’objet d’un débat bien sûr, mais mérite peut-être d’être examiné.
Ceci est un exemple où les attributs sont des données sur des données.
Les bases de données sont nommées par leur attribut ID.
L'attribut "type" de la base de données indique ce que l'on s'attend à trouver dans la balise de base de données.
<databases>
<database id='human_resources' type='mysql'>
<Host>localhost</Host>
<user>usrhr</user>
<pass>jobby</pass>
<name>consol_hr</name>
</database>
<database id='products' type='my_bespoke'>
<filename>/home/anthony/products.adb</filename>
</database>
</databases>
Les points de l'auteur sont corrects (sauf que les attributs peuvent contenir une liste de valeurs). La question est de savoir si vous vous souciez de ses points.
C'est à vous.
C'est à cause de ce genre de déchets que vous devriez éviter les écoles de cinéma. En réalité, c'est encore pire que le matériel épouvantable qu'ils ont sur JavaScript.
En règle générale, je suggérerais que le contenu, c'est-à-dire les données qui devraient être consommées par un utilisateur final (qu'il s'agisse d'une lecture humaine ou d'une machine recevant des informations à traiter), est mieux contenu dans un élément. Les métadonnées (par exemple, un identifiant associé à un élément de contenu mais uniquement de valeur pour un usage interne plutôt que pour un affichage à l'utilisateur final) doivent figurer dans un attribut.
Vous pourriez probablement voir le problème de manière sémantique.
Si les données sont plus étroitement liées à l'élément, il s'agira d'un attribut.
c'est-à-dire: un identifiant d'élément, je le mettrais comme attribut de l'élément.
Mais il est vrai que lors de l'analyse syntaxique d'un document, les attributs peuvent causer plus de maux de tête que d'éléments.
Tout dépend de vous et de la manière dont vous concevez votre schéma.
Voici un autre élément à garder à l’esprit lorsque vous choisissez un format XML: Si je me souviens bien, les valeurs des attributs "id" ne doivent pas être toutes numériques, elles doivent respecter les règles de nom XML. Et bien sûr, les valeurs doivent être uniques. J'ai un projet qui doit traiter des fichiers qui ne répondent pas à ces exigences (bien qu'ils soient propres à XML à d'autres égards), ce qui a rendu le traitement des fichiers plus compliqué.