Attribut XML vs élément XML
https://stackoverflow.com/questions/33746
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Au travail, on nous demande de créer des fichiers XML pour transmettre des données à un autre en mode hors connexion de l'application qui va ensuite créer un deuxième fichier XML à transmettre dans le but de mettre à jour certaines de nos données.Au cours de ce processus, nous avons discuté avec l'équipe de l'application sur la structure du fichier XML.
L'exemple de je suis venu avec est essentiellement quelque chose comme:
<INVENTORY>
<ITEM serialNumber="something" location="something" barcode="something">
<TYPE modelNumber="something" vendor="something"/>
</ITEM>
</INVENTORY>
L'autre équipe a dit que ce n'était pas la norme de l'industrie et des attributs doit être utilisé uniquement pour les méta-données.Ils ont proposé:
<INVENTORY>
<ITEM>
<SERIALNUMBER>something</SERIALNUMBER>
<LOCATION>something</LOCATION>
<BARCODE>something</BARCODE>
<TYPE>
<MODELNUMBER>something</MODELNUMBER>
<VENDOR>something</VENDOR>
</TYPE>
</ITEM>
</INVENTORY>
La raison je suggère le premier est que la taille du fichier créé est beaucoup plus petite.Il y aura environ 80000 éléments qui seront dans le fichier en cours de transfert.Leur suggestion dans la réalité s'avère trois fois plus grand que celui que j'ai proposé.J'ai cherché le mystérieux "Standard de l'Industrie" qui a été mentionné, mais le plus proche que j'ai pu trouver est que les attributs XML doit être utilisé uniquement pour les méta-données, mais a déclaré que le débat sur ce qui a été meta-données.
Après de longue haleine explications (désolé) comment voulez-vous déterminer ce qui est méta-données, et lors de la conception de la structure d'un document XML, comment devriez-vous décider quand utiliser un attribut ou un élément?
La solution
J'utilise cette règle de base:
- Un Attribut est quelque chose qui est autonome, c'est à dire, une couleur, un ID, un nom.
- Un Élément est quelque chose qui fait ou pourrait avoir des attributs de ses propres services ou contenir d'autres éléments.
Si le vôtre est à proximité.J'aurais fait quelque chose comme:
MODIFIER:Mise à jour de l'exemple d'origine sur la base des commentaires ci-dessous.
<ITEM serialNumber="something">
<BARCODE encoding="Code39">something</BARCODE>
<LOCATION>XYX</LOCATION>
<TYPE modelNumber="something">
<VENDOR>YYZ</VENDOR>
</TYPE>
</ITEM>
Autres conseils
Certains des problèmes avec les attributs sont:
- les attributs ne peuvent pas contenir plusieurs valeurs de l'enfant (éléments)
- les attributs ne sont pas facilement extensible (pour de futures modifications)
- les attributs ne peuvent pas décrire les structures de l'enfant (éléments)
- les attributs sont plus difficiles à manipuler par le code de programme
- les valeurs d'attribut ne sont pas facile à tester contre une DTD
Si vous utilisez les attributs comme des conteneurs de données, vous vous retrouvez avec des documents qui sont difficiles à lire et à maintenir.Essayez d'utiliser ces éléments pour décrire les données.Utiliser des attributs uniquement à fournir des renseignements qui ne sont pas pertinents pour les données.
Ne pas finir comme ceci (ce n'est pas comment XML devrait être utilisé):
<note day="12" month="11" year="2002"
to="Tove" to2="John" from="Jani" heading="Reminder"
body="Don't forget me this weekend!">
</note>
"XML" est synonyme de "eXtensible Balisage La langue".Un langage de balisage implique que les données de texte, marqué avec des métadonnées sur la structure ou la mise en forme.
Le XHTML est un exemple de XML utilisées de la façon dont il a été conçu:
<p><span lang="es">El Jefe</span> insists that you
<em class="urgent">MUST</em> complete your project by Friday.</p>
Ici, la distinction entre les éléments et attributs est clair.Les éléments de texte sont affichés dans le navigateur, et les attributs sont des instructions sur la comment pour les afficher (bien qu'il existe quelques balises qui ne fonctionnent pas de cette façon).
La Confusion se pose lorsque le XML est utilisé non pas comme un langage de balisage, mais comme un de sérialisation de données la langue, la distinction entre les "données" et les "métadonnées" est plus vague.Donc, le choix entre les éléments et attributs est plus ou moins arbitraire, sauf pour les choses qui ne peut pas être représenté avec les attributs (voir feenster de réponse).
L'Élément XML vs Attribut XML
XML est tout au sujet de l'accord. D'abord reporter à aucun des schémas XML ou les conventions établies au sein de votre communauté ou de l'industrie.
Si vous êtes vraiment dans une situation à définir votre schéma à partir de la base, voici quelques considérations d'ordre général qui doit en informer le élément vs attribut de décision:
<versus>
<element attribute="Meta content">
Content
</element>
<element attribute="Flat">
<parent>
<child>Hierarchical</child>
</parent>
</element>
<element attribute="Unordered">
<ol>
<li>Has</li>
<li>order</li>
</ol>
</element>
<element attribute="Must copy to reuse">
Can reference to re-use
</element>
<element attribute="For software">
For humans
</element>
<element attribute="Extreme use leads to micro-parsing">
Extreme use leads to document bloat
</element>
<element attribute="Unique names">
Unique or non-unique names
</element>
<element attribute="SAX parse: read first">
SAX parse: read later
</element>
<element attribute="DTD: default value">
DTD: no default value
</element>
</versus>
Cela peut dépendre de votre utilisation.XML qui est utilisé pour représenter stuctured de données générées à partir d'une base de données peut bien travailler avec, finalement, les valeurs de champ d'être placé en tant qu'attributs.
Cependant XML utilisé comme transport de message serait souvent mieux à l'aide de plusieurs éléments.
Par exemple, disons que nous avons eu ce XML tel que proposé dans la réponse:-
<INVENTORY>
<ITEM serialNumber="something" barcode="something">
<Location>XYX</LOCATION>
<TYPE modelNumber="something">
<VENDOR>YYZ</VENDOR>
</TYPE>
</ITEM>
</INVENTORY>
Maintenant, nous voulons envoyer l'ÉLÉMENT de l'élément à un appareil pour imprimer il de codes à barres cependant, il ya un choix de types de codage.Comment pouvons-nous représenter le type de codage requis?Soudain, nous nous rendons compte, un peu tardivement, que le code-barres n'était pas un seul automic valeur, mais plutôt qu'il peut être qualifié avec le codage requis lors de l'impression.
<ITEM serialNumber="something">
<barcode encoding="Code39">something</barcode>
<Location>XYX</LOCATION>
<TYPE modelNumber="something">
<VENDOR>YYZ</VENDOR>
</TYPE>
</ITEM>
Le point est, à moins que vous construisez une sorte de XSD ou DTD avec un espace de noms pour fixer la structure en pierre, vous pourriez être mieux servis laisser vos options ouvertes.
OMI XML est à son niveau le plus utile lorsqu'il peut être plié sans casser le code existant de l'utiliser.
J'utilise les lignes directrices suivantes dans mon schéma de conception en ce qui concerne les attributs vséléments:
- Utiliser les éléments pour de longues texte (généralement ceux de la chaîne ou normalizedString types)
- Ne pas utiliser un attribut s'il s'agit du regroupement de deux valeurs (par ex.eventStartDate et eventEndDate) pour un élément.Dans l'exemple précédent, il devrait y avoir un élément nouveau pour la "événement" qui peut contenir la date de début et date de fin attributs.
- D'affaires Date, DateTime et les chiffres (p. ex.compte, montant et taux) devrait être éléments.
- Non-business éléments comme la dernière mise à jour, expire devrait être les attributs.
- Non-numéros d'entreprise tels que des codes de hachage et les indices devraient être des attributs.* Utiliser des éléments si le type sera complexe.
- Utiliser des attributs si la valeur est de type simple et ne se répète pas.
- xml:id et xml:lang doit avoir les attributs de référencement du schéma XML
- Préférez les attributs lorsque cela est techniquement possible.
La préférence pour les attributs est il fournit les services suivants:
- unique (l'attribut ne peut pas apparaître plusieurs fois)
- l'ordre n'a pas d'importance
- les propriétés ci-dessus sont héritables (c'est quelque chose que le "tout" du contenu du modèle ne prend pas en charge dans le schéma actuel de la langue)
- bonus, c'est qu'ils sont moins détaillées et d'utiliser moins de bande passante, mais ce n'est pas vraiment une raison de préférer les attributs d'éléments.
J'ai ajouté lorsque cela est techniquement possible parce qu'il y a des moments où l'utilisation d'attributs ne sont pas possibles.Par exemple, l'attribut choix.Par exemple, utiliser (startDate et endDate) xor (startTS et endTS) n'est pas possible avec le langage de schéma
Si le Schéma XML commence en permettant le "tout" modèle de contenu pour être restreinte ou élargie, alors je serais probablement tomber
Il n'y a pas de réponse universelle à cette question (j'ai été fortement impliqué dans la création du W3C spec).XML peut être utilisé à plusieurs fins - texte-comme les documents, les données et les code sont trois des plus communs.J'ai aussi beaucoup l'utiliser comme un modèle de données.Il y a des aspects de ces applications où les attributs sont plus fréquentes, et d'autres où les éléments enfants sont plus naturels.Il y a également les caractéristiques des différents outils qui font qu'il est plus facile ou plus difficile de les utiliser.
Le XHTML est un domaine où les attributs ont une utilisation naturelle (par ex.dans class='foo').Les attributs ne sont pas d'ordre et cela peut rendre plus facile pour certaines personnes de développer des outils.Otoh, que les attributs sont plus difficiles à taper sans un schéma.J'ai aussi trouver des espaces d'attributs (foo:bar="zork") sont souvent plus difficiles à gérer dans divers ensembles d'outils.Mais jetez un oeil à certains de la W3C langues de voir le mélange qui est commun.SVG, XSLT, XSD, MathML sont des exemples bien connus de langues et tous ont un riche apport des attributs et des éléments.Certains langages permettent même aux plus-que-un-moyen de le faire, par exemple
<foo title="bar"/>;
ou
<foo>
<title>bar</title>;
</foo>;
Notez que ce ne sont PAS équivalentes du point de vue syntaxique et nécessitent un soutien explicite dans les outils de traitement)
Mon conseil serait d'avoir un coup d'oeil à la pratique courante dans la zone la plus proche de votre demande et prendre également en compte ce que l'ensemble des outils que vous pouvez faire.
Enfin, assurez-vous que vous différencier des espaces de noms d'attributs.XML systèmes (par ex.Linq) représentent des espaces de noms en tant qu'attributs dans l'API.IMO c'est laid et potentiellement source de confusion.
En cas de doute, KISS -- pourquoi mélanger les attributs et les éléments lorsque vous n'avez pas de raison d'utiliser des attributs.Si vous décidez par la suite de définir un XSD, qui finira par être plus propre ainsi.Alors même si vous décidez par la suite de générer une structure de classe de votre XSD, qui sera plus simple ainsi.
la question à un million!
tout d'abord, ne vous inquiétez pas trop à propos de la performance, maintenant.vous serez étonné de voir comment rapidement un optimisée analyseur xml rip par le biais de votre xml.plus important encore, quelle est votre conception de l'avenir:comme le XML évolue, comment allez-vous maintenir le couplage et l'interopérabilité?
plus concrètement, vous pouvez faire le modèle de contenu d'un élément plus complexe, mais il est plus difficile de prolonger d'un attribut.
Utiliser des éléments de données et les attributs de méta-données (données sur l'élément de données).
Si un élément est un prédicat dans vos sélectionner des chaînes, vous avez un bon signe que ça doit être un attribut.De même, si un attribut n'est jamais utilisé comme un prédicat, alors peut-être il n'est pas utile de meta-données.
Rappelez-vous que XML est censé être lisible à la machine de ne pas lisibles par l'homme et pour les grands documents XML compresse très bien.
D'autres ont couvert comment faire la différence entre les attributs d'éléments, mais à partir d'un point de vue plus général de tout mettre en attributs, car il rend le XML résultant petit, c'est mal.
XML n'est pas conçu pour être compact, mais pour être portable et lisible par l'homme.Si vous voulez réduire la taille des données en transit ensuite utiliser quelque chose d'autre (comme google protocol buffers).
Il est défendable, mais vos collègues sont en droit, dans le sens que le XML doit être utilisé pour le "balisage" ou les méta-données sur les données réelles.Pour votre part, vous avez raison en ce qu'il est parfois difficile de décider de l'endroit où la ligne entre les méta-données et les données lors de la modélisation de votre domaine en XML.Dans la pratique, ce que je fais est de prétendre que rien dans le balisage est caché, et seules les données à l'extérieur de la majoration est lisible.Le document se faire un certain sens de cette façon?
XML est notoirement volumineux.Pour le transport et le stockage, la compression est fortement recommandé si vous pouvez vous permettre la puissance de traitement.XML compresse bien, parfois incroyablement bien, à cause de sa répétitivité.J'ai eu de gros fichiers compresser à moins de 5% de leur taille d'origine.
Un autre point à renforcer votre position est que tandis que l'autre équipe est de se disputer sur le style (dans la plupart des outils XML va gérer un attribut document tout aussi facilement comme un tout-#PCDATA document) vous faisant valoir les aspects pratiques.Alors que le style ne peut pas être totalement ignorée, les mérites techniques devraient avoir plus de poids.
Les deux méthodes pour stocker les propriétés de l'objet sont parfaitement valides.Vous devriez partent de considérations pragmatiques.Essayez de répondre aux questions suivantes:
- La représentation conduit à une accélération de l'analyse des données\génération?
- La représentation conduit à une accélération de transfert de données?
Ne lisibilité de la matière?
...
C'est en grande partie une question de préférence.J'ai utiliser les Éléments du regroupement et des attributs de données si possible que j'y vois plus compact que les autres.
Par exemple, je préfère.....
<?xml version="1.0" encoding="utf-8"?>
<data>
<people>
<person name="Rory" surname="Becker" age="30" />
<person name="Travis" surname="Illig" age="32" />
<person name="Scott" surname="Hanselman" age="34" />
</people>
</data>
...Au lieu de.....
<?xml version="1.0" encoding="utf-8"?>
<data>
<people>
<person>
<name>Rory</name>
<surname>Becker</surname>
<age>30</age>
</person>
<person>
<name>Travis</name>
<surname>Illig</surname>
<age>32</age>
</person>
<person>
<name>Scott</name>
<surname>Hanselman</surname>
<age>34</age>
</person>
</people>
</data>
Cependant, si j'ai des données qui ne représentent pas facilement à l'intérieur de dire de 20 à 30 caractères ou contient de nombreuses citations ou d'autres caractères qui ont besoin d'échapper alors je dirais qu'il est temps de sortir les éléments...éventuellement avec CData blocs.
<?xml version="1.0" encoding="utf-8"?>
<data>
<people>
<person name="Rory" surname="Becker" age="30" >
<comment>A programmer whose interested in all sorts of misc stuff. His Blog can be found at http://rorybecker.blogspot.com and he's on twitter as @RoryBecker</comment>
</person>
<person name="Travis" surname="Illig" age="32" >
<comment>A cool guy for who has helped me out with all sorts of SVn information</comment>
</person>
<person name="Scott" surname="Hanselman" age="34" >
<comment>Scott works for MS and has a great podcast available at http://www.hanselminutes.com </comment>
</person>
</people>
</data>
Comment au sujet de prendre avantage de notre dur gagné de l'orientation de l'objet de l'intuition?J'ai l'habitude de trouver, il est simple de penser qui est un objet, et qui est un attribut de l'objet ou de l'objet dont il est fait référence.
Selon intuitivement le sens comme objets doivent s'inscrire en tant qu'éléments.Ses attributs (ou propriétés) seraient les attributs de ces éléments xml ou de l'enfant de l'élément avec l'attribut.
Je pense que pour les cas les plus simples, comme dans l'exemple de l'orientation de l'objet analogie œuvres d'accord pour savoir qui est l'élément et qui est l'attribut d'un élément.
Juste quelques corrections à certaines mauvaises info:
@John Ballinger:Attributies peut contenir n'importe quel caractère de données.< > & "' doivent être échappés à <>&"et ', respectivement.Si vous utilisez une bibliothèque XML, il prendra soin de cela pour vous.
L'enfer, un attribut peut contenir des données binaires comme une image, si vous voulez vraiment, juste en base64-encodage et de rendre les données:URL.
@feenster:Les attributs peuvent contenir séparées par un espace de plusieurs éléments dans le cas de l'IDS ou les NOMS, qui pourrait inclure des numéros.Pinailleurs, mais cela peut finir par économiser de l'espace.
À l'aide d'attributs peut garder XML concurrentiel avec JSON.Voir La Graisse De Balisage:Coupez dans le Gras de Balisage Mythe des calories à un moment.
Je suis toujours surpris par les résultats de ces sortes de discussions.Pour moi il y a une règle très simple pour décider si les données appartient à un attribut ou comme contenu et qui est de savoir si les données ont navigables de la sous-structure.
Ainsi, par exemple, de la non-majoration de texte appartient toujours dans les attributs.Toujours.
Listes appartiennent à la sous-structure ou de contenu.Le texte qui pourraient comporter structuré sous-contenu appartiennent dans le contenu.(Dans mon expérience, il y a relativement peu de ce texte avec des balises - lors de l'utilisation de XML pour le stockage de données ou d'échange.)
Schéma XML écrit de cette manière concise.
Chaque fois que je vois des cas comme <car><make>Ford</make><color>Red</color></car>, Je pense à moi-même "gee a fait l'auteur pense qu'il n'y allaient être sous-éléments au sein de le faire élément?" <car make="Ford" color="Red" /> est nettement plus lisible, il n'y a aucune question à propos de la façon dont les espaces sont manipulés, etc.
Compte tenu mais la gestion des espaces blancs règles, je crois que c'était l'intention claire de l'XML concepteurs.
C'est très clair dans le code HTML où les différences d'attributs et de balisage peut être clairement vu:
- Toutes les données sont entre de balisage
- Les attributs sont utilisés pour caractériser ces données (par ex.formats)
Si vous avez juste pur des données en XML, il est moins nette différence.Les données pourraient se tenir entre le balisage ou en tant qu'attributs.
=> La plupart des données devrait se tenir entre le balisage.
Si vous souhaitez utiliser les attributs ici:Vous pouvez diviser les données en deux catégories:Les données et les "méta-données", où les méta-données ne fait pas partie de l'enregistrement, vous voulez présenter, mais des choses comme "format", "date de création", etc.
<customer format="">
<name></name>
...
</customer>
On pourrait aussi dire:"Utiliser des attributs pour caractériser la balise, d'utiliser des tags pour fournir des données lui-même."
Je suis d'accord avec feenster.Restez à l'écart à partir d'attributs si vous le pouvez.Les éléments sont des évolutions convivial et plus interopérables entre services web boîtes à outils.Vous n'auriez jamais trouver ces boîtes à outils de la sérialisation de vos messages de requête/réponse à l'aide d'attributs.Cela fait sens, parce que nos messages sont données (pas de métadonnées) pour un service web toolkit.
Les attributs peuvent facilement devenir difficile à gérer dans le temps de me faire confiance.j'ai toujours rester loin d'eux personnellement.Les éléments sont beaucoup plus explicite et lisible et utilisable par les deux analyseurs et des utilisateurs.
Seul le temps je n'ai jamais utilisé a été de définir l'extension de fichier d'un actif url:
<image type="gif">wank.jpg</image> ...etc etc
je suppose que si vous savez à 100% de l'attribut sera pas besoin d'être développé vous pourriez utiliser, mais combien de temps savez-vous que.
<image>
<url>wank.jpg</url>
<fileType>gif</fileType>
</image>
