Attribut XML vs élément XML

Au travail, il nous est demandé de créer des fichiers XML pour transmettre des données à une autre application hors ligne qui créera ensuite un deuxième fichier XML à transmettre afin de mettre à jour certaines de nos données. Au cours du processus, nous avons discuté avec l'équipe de l'autre application de la structure du fichier XML.

L'échantillon que j'ai trouvé est essentiellement quelque chose comme:

<INVENTORY>
   <ITEM serialNumber="something" location="something" barcode="something">
      <TYPE modelNumber="something" vendor="something"/> 
   </ITEM>
</INVENTORY>

L'autre équipe a déclaré que ce n'était pas la norme de l'industrie et que les attributs ne devraient être utilisés que pour les métadonnées. Ils ont suggéré:

<INVENTORY>
   <ITEM>
      <SERIALNUMBER>something</SERIALNUMBER>
      <LOCATION>something</LOCATION>
      <BARCODE>something</BARCODE>
      <TYPE>
         <MODELNUMBER>something</MODELNUMBER>
         <VENDOR>something</VENDOR>
      </TYPE>
   </ITEM>
</INVENTORY>

La raison pour laquelle j'ai suggéré la première est que la taille du fichier créé est beaucoup plus petite. Il y aura environ 80000 éléments qui seront dans le fichier lors du transfert. Leur suggestion s'avère en réalité trois fois plus grande que celle que j'ai suggérée. J'ai recherché la mystérieuse "norme industrielle" qui a été mentionnée, mais le plus proche que j'ai pu trouver était que les attributs XML ne devraient être utilisés que pour les métadonnées, mais j'ai dit que le débat portait sur ce qui était réellement des métadonnées.

Après une longue explication (désolé) comment déterminez-vous ce que sont les métadonnées et lorsque vous concevez la structure d'un document XML, comment devez-vous décider quand utiliser un attribut ou un élément?

J'utilise cette règle d'or:

1. Un attribut est quelque chose qui est autonome, c'est-à-dire une couleur, un ID, un nom.
2. Un élément est quelque chose qui possède ou pourrait avoir ses propres attributs ou contenir d'autres éléments.

Le vôtre est donc proche. J'aurais fait quelque chose comme:

EDIT : mise à jour de l'exemple d'origine en fonction des commentaires ci-dessous.

  <ITEM serialNumber="something">
      <BARCODE encoding="Code39">something</BARCODE>
      <LOCATION>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

Certains des problèmes avec les attributs sont:

• les attributs ne peuvent pas contenir plusieurs valeurs (les éléments enfants le peuvent)
• les attributs ne sont pas facilement extensibles (pour les changements futurs)
• les attributs ne peuvent pas décrire les structures (les éléments enfants le peuvent)
• les attributs sont plus difficiles à manipuler par le code du programme
• les valeurs d'attribut ne sont pas faciles à tester par rapport à une DTD

Si vous utilisez des attributs comme conteneurs de données, vous vous retrouvez avec des documents difficiles à lire et à conserver. Essayez d'utiliser des éléments pour décrire les données. Utilisez des attributs uniquement pour fournir des informations qui ne sont pas pertinentes pour les données.

Ne vous retrouvez pas comme ça (ce n'est pas ainsi que XML doit ê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>

Source: http://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp

"XML" signifie "eXtensible Markup Language". Un langage de balisage implique que les données sont du texte, marquées de métadonnées sur la structure ou la mise en forme.

XHTML est un exemple de XML utilisé comme prévu:

<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 éléments et attributs est claire. Les éléments de texte sont affichés dans le navigateur et les attributs sont des instructions sur la façon de les afficher (bien qu'il existe quelques balises qui ne fonctionnent pas de cette façon).

La confusion survient lorsque XML n'est pas utilisé comme langage de balisage, mais comme langage de sérialisation des données , dans lequel la distinction entre «données» et «métadonnées» est plus vague. Ainsi, le choix entre les éléments et les attributs est plus ou moins arbitraire, sauf pour les choses qui ne peuvent pas être représentées avec des attributs (voir la réponse de Feenster).

Élément XML vs attribut XML

XML est tout au sujet de l'accord. Reportez-vous d'abord aux schémas XML existants ou aux conventions établies au sein de votre communauté ou de votre industrie.

Si vous êtes vraiment dans une situation pour définir votre schéma à partir de zéro, voici quelques considérations générales qui devraient éclairer la décision élément vs attribut :

<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 les données structurées générées à partir d'une base de données peut bien fonctionner avec en fin de compte des valeurs de champ placées comme attributs.

Cependant, XML utilisé comme transport de messages serait souvent préférable d'utiliser plus d'éléments.

Par exemple, disons que nous avions ce XML comme 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 ITEM à un appareil pour imprimer le code à barres, mais il existe un choix de types d'encodage. Comment représentons-nous le type d'encodage requis? Soudain, nous nous rendons compte, quelque peu tardivement, que le code-barres n'était pas une valeur automique unique, mais qu'il peut plutôt être qualifié avec l'encodage requis lors de l'impression.

   <ITEM serialNumber="something">
      <barcode encoding="Code39">something</barcode>
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

À moins que vous ne construisiez une sorte de XSD ou DTD avec un espace de noms pour fixer la structure dans la pierre, vous pouvez être mieux servi en laissant vos options ouvertes.

IMO XML est le plus utile lorsqu'il peut être fléchi sans casser le code existant en l'utilisant.

J'utilise les directives suivantes dans ma conception de schéma en ce qui concerne les attributs et les éléments:

• Utiliser des éléments pour un texte de longue durée (généralement ceux de type chaîne ou normalizedString)
• N'utilisez pas d'attribut s'il existe un regroupement de deux valeurs (par exemple, eventStartDate et eventEndDate) pour un élément. Dans l'exemple précédent, il devrait y avoir un nouvel élément pour "event" qui peut contenir les attributs startDate et endDate.
• La date d'affaires, la date et l'heure et les nombres (par exemple, les nombres, le montant et le taux) doivent être des éléments.
• Les éléments de temps non commercial, tels que la dernière mise à jour, expirent le devraient être des attributs.
• Les numéros non commerciaux tels que les codes de hachage et les indices doivent être des attributs. * Utilisez des éléments si le type sera complexe.
• Utilisez des attributs si la valeur est de type simple et ne se répète pas.
• xml: id et xml: lang doivent être des attributs faisant référence au schéma XML
• Préférez les attributs lorsque cela est techniquement possible.

La préférence pour les attributs est qu'elle fournit les éléments 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 modèle de contenu «tout» ne prend pas en charge dans le langage de schéma actuel)
• le bonus est qu'ils sont moins verbeux et utilisent moins de bande passante, mais ce n'est pas vraiment une raison pour préférer les attributs aux éléments.

J'ai ajouté quand c'était techniquement possible car il y a des moments où l'utilisation d'attributs n'est pas possible. Par exemple, choix d'ensemble d'attributs. Par exemple, utiliser (startDate et endDate) xor (startTS et endTS) n'est pas possible avec le langage de schéma actuel

Si le schéma XML commence à autoriser la restriction ou l'extension du modèle de contenu «tout», je le laisserais probablement tomber

En cas de doute, KISS - pourquoi mélanger les attributs et les éléments lorsque vous n'avez pas de raison claire d'utiliser des attributs. Si vous décidez plus tard de définir un XSD, cela finira également par être plus propre. Ensuite, si vous décidez encore plus tard de générer une structure de classe à partir de votre XSD, ce sera aussi plus simple.

Il n'y a pas de réponse universelle à cette question (j'ai été fortement impliqué dans la création de la spécification W3C). XML peut être utilisé à de nombreuses fins - les documents de type texte, les données et le code déclaratif sont trois des plus courants. Je l'utilise également beaucoup comme modèle de données. Il y a des aspects de ces applications où les attributs sont plus communs et d'autres où les éléments enfants sont plus naturels. Il existe également des fonctionnalités de divers outils qui les rendent plus faciles ou plus difficiles à utiliser.

XHTML est un domaine où les attributs ont un usage naturel (par exemple dans class = 'foo'). Les attributs n'ont pas d'ordre et cela peut faciliter le développement d'outils par certaines personnes. Les attributs OTOH sont plus difficiles à taper sans schéma. Je trouve également que les attributs d'espaces de noms (foo: bar = "zork") sont souvent plus difficiles à gérer dans divers ensembles d'outils. Mais jetez un oeil à certains des langages du W3C pour voir le mélange qui est commun. SVG, XSLT, XSD, MathML sont quelques exemples de langages bien connus et ont tous une riche offre d'attributs et d'éléments. Certaines langues autorisent même plus d'une façon de le faire, par exemple

<foo title="bar"/>;

ou

<foo>
  <title>bar</title>;
</foo>;

Notez que ceux-ci ne sont PAS équivalents syntaxiquement et nécessitent un support explicite dans les outils de traitement)

Mon conseil serait de jeter un coup d'œil aux pratiques courantes dans le domaine le plus proche de votre application et de considérer également les jeux d'outils que vous souhaitez appliquer.

Enfin, assurez-vous de différencier les espaces de noms des attributs. Certains systèmes XML (par exemple Linq) représentent des espaces de noms en tant qu'attributs dans l'API. OMI, c'est moche et potentiellement déroutant.

D'autres ont couvert comment différencier les attributs des éléments, mais dans une perspective plus générale, tout mettre dans les attributs, car cela rend le XML résultant plus petit est faux.

XML n'est pas conçu pour être compact mais pour être portable et lisible par l'homme. Si vous souhaitez réduire la taille des données en transit, utilisez autre chose (comme les tampons de protocole de Google ).

la question à un million de dollars!

Tout d'abord, ne vous inquiétez pas trop des performances maintenant. vous serez étonné de la rapidité avec laquelle un analyseur xml optimisé déchirera votre xml. plus important encore, quelle est votre conception pour l'avenir: à mesure que le XML évolue, comment maintiendrez-vous le couplage et l'interopérabilité?

plus concrètement, vous pouvez rendre le modèle de contenu d'un élément plus complexe mais il est plus difficile d'étendre un attribut.

Les deux méthodes de stockage des propriétés d'un objet sont parfaitement valides. Vous devez vous éloigner de considérations pragmatiques. Essayez de répondre à la question suivante:

1. Quelle représentation permet une analyse / génération de données plus rapide?

2. Quelle représentation permet un transfert de données plus rapide?

3. La lisibilité est-elle importante?

   ...

Utilisez des éléments pour les données et des attributs pour les métadonnées (données sur les données de l'élément).

Si un élément apparaît comme un prédicat dans vos chaînes de sélection, vous avez un bon signe qu'il doit s'agir d'un attribut. De même, si un attribut n'est jamais utilisé comme prédicat, il ne s'agit peut-être pas de métadonnées utiles.

N'oubliez pas que XML est censé être lisible par machine et non lisible par l'homme et pour les gros documents, XML se comprime très bien.

C'est discutable dans les deux cas, mais vos collègues ont raison en ce sens que le XML doit être utilisé pour le «balisage» ou les métadonnées autour des données réelles. Pour votre part, vous avez raison en ce qu'il est parfois difficile de décider où se situe la ligne entre les métadonnées et les données lors de la modélisation de votre domaine en XML. En pratique, ce que je fais, c'est faire semblant que tout ce qui se trouve dans le balisage est caché et que seules les données en dehors du balisage sont lisibles. Le document a-t-il un sens dans ce sens?

XML est notoirement volumineux. Pour le transport et le stockage, la compression est fortement recommandée si vous pouvez vous permettre la puissance de traitement. XML se comprime bien, parfois de façon phénoménale, en raison de sa répétitivité. J'ai eu des fichiers volumineux compressés à moins de 5% de leur taille d'origine.

Un autre point pour renforcer votre position est que pendant que l'autre équipe discute du style (dans la mesure où la plupart des outils XML traiteront un document tout attribut aussi facilement qu'un document tout-# PCDATA), vous discutez des aspects pratiques. Bien que le style ne puisse pas être totalement ignoré, les mérites techniques devraient avoir plus de poids.

C'est en grande partie une question de préférence. J'utilise des éléments pour le regroupement et des attributs pour les données lorsque cela est possible, car je vois cela comme plus compact que l'alternative.

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 disons 20-30 caractères ou contiennent de nombreuses citations ou autres caractères qui doivent être échappés, je dirais qu'il est temps de décomposer les éléments ... éventuellement avec des blocs CData.

<?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>

Que diriez-vous de profiter de notre intuition orientée objet durement gagnée? Je trouve généralement qu'il est simple de penser à un objet et à un attribut de l'objet ou à quel objet il se réfère.

Tout ce qui a un sens intuitif en tant qu'objets doit s'intégrer en tant qu'éléments. Ses attributs (ou propriétés) seraient des attributs pour ces éléments en xml ou un élément enfant avec attribut.

Je pense que pour des cas plus simples comme dans l'exemple, l'analogie de l'orientation d'objet fonctionne bien pour déterminer quel est l'élément et quel est l'attribut d'un élément.

Juste quelques corrections à de mauvaises informations:

@John Ballinger: les attributs peuvent contenir n'importe quelle donnée de caractère. <> & "'doivent être échappés vers & lt; & gt; & amp;" et & apos;, respectivement. Si vous utilisez une bibliothèque XML, elle s'en chargera pour vous.

Enfer, un attribut peut contenir des données binaires telles qu'une image, si vous voulez vraiment, juste en l'encodant en base64 et en en faisant une donnée: URL.

@feenster: les attributs peuvent contenir plusieurs éléments séparés par des espaces dans le cas d'IDS ou de NOMS, qui incluraient des nombres. Nitpicky, mais cela peut finir par économiser de l'espace.

L'utilisation d'attributs peut garder XML compétitif avec JSON. Voir Fat Markup: Trimming the Fat Markup Myth une calorie à la fois .

Je suis toujours surpris par les résultats de ce type de discussions. Pour moi, il existe une règle très simple pour décider si les données appartiennent à un attribut ou en tant que contenu et c'est si les données ont une sous-structure navigable.

Ainsi, par exemple, le texte non balisé appartient toujours aux attributs. Toujours.

Les listes appartiennent à la sous-structure ou au contenu. Le texte qui peut au fil du temps inclure un sous-contenu structuré intégré appartient au contenu. (D'après mon expérience, il y a relativement peu de cela - texte avec balisage - lors de l'utilisation de XML pour le stockage ou l'échange de données.)

Le schéma XML écrit de cette façon est concis.

Chaque fois que je vois des cas comme <car><make>Ford</make><color>Red</color></car>, je pense à moi-même "est-ce que l'auteur pensait qu'il y aurait des sous-éléments dans l'élément make?" <car make="Ford" color="Red" />est beaucoup plus lisible, il n'y a aucun doute sur la façon dont les espaces blancs seraient traités, etc.

Étant donné uniquement les règles de gestion des espaces blancs, je pense que c'était l'intention claire des concepteurs XML.

Ceci est très clair en HTML où les différences d'attributs et de balisage sont clairement visibles:

1. Toutes les données se trouvent entre le balisage
2. Les attributs sont utilisés pour caractériser ces données (par exemple les formats)

Si vous n'avez que des données pures en XML, il y a une différence moins claire. Les données peuvent se trouver entre le balisage ou en tant qu'attributs.

=> La plupart des données doivent se situer entre les balises.

Si vous souhaitez utiliser des attributs ici: vous pouvez diviser les données en deux catégories: les données et les "métadonnées", où les métadonnées ne font pas partie de l'enregistrement, que vous souhaitez présenter, mais des éléments tels que "version du format", "date de création" , etc.

<customer format="">
     <name></name>
     ...
</customer>

On pourrait également dire: "Utilisez des attributs pour caractériser la balise, utilisez des balises pour fournir les données elles-mêmes."

Je suis d'accord avec Feenster. Éloignez-vous des attributs si vous le pouvez. Les éléments sont évolutifs et plus interopérables entre les kits d'outils de service Web. Vous ne trouverez jamais ces boîtes à outils sérialisant vos messages de demande / réponse à l'aide d'attributs. Cela est également logique puisque nos messages sont des données (pas des métadonnées) pour une boîte à outils de service Web.

Les attributs peuvent facilement devenir difficiles à gérer avec le temps, croyez-moi. je reste toujours loin d'eux personnellement. Les éléments sont beaucoup plus explicites et lisibles / utilisables par les analyseurs et les utilisateurs.

Le seul moment où je les ai utilisés était de définir l'extension de fichier d'une URL d'actif:

<image type="gif">wank.jpg</image> ...etc etc

je suppose que si vous connaissez 100% l'attribut n'aura pas besoin d'être développé, vous pouvez les utiliser, mais combien de fois le savez-vous.

<image>
  <url>wank.jpg</url>
  <fileType>gif</fileType>
</image>