Attribut XML vs élément XML

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 extensibles (pour les changements futurs)
• les attributs ne peuvent pas décrire les structures de l'enfant (éléments)
• les attributs sont plus difficiles à manipuler par code de programme
Les valeurs d'attribut
• ne sont pas faciles à tester par rapport à une DTD

si vous utilisez des attributs comme des conteneurs de données, vous vous retrouvez avec des documents qui sont difficiles à lire et à tenir à jour. Essayez d'utiliser ces éléments pour décrire les données. Utilisez les attributs uniquement pour fournir de l'information qui n'est pas pertinente aux données.

ne finissez pas comme ceci (ce N'est pas comme cela 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é avec des métadonnées sur la structure ou le formatage.

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 les éléments et les attributs est claire. Les éléments de texte sont affichés dans le navigateur, et les attributs sont des instructions sur 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 de la langue dans laquelle la distinction entre les "données" et les "métadonnées" est plus vague. Donc le choix entre les éléments et les attributs est plus ou moins arbitraire sauf pour les choses que ne peut pas être représenté avec des attributs (voir réponse.)

élément XML vs attribut XML

XML est tout au sujet de l'accord. reportez-vous D'abord à tout schéma XML existant ou à toute convention établie au sein de votre communauté ou de votre industrie.

si vous êtes vraiment dans une situation pour définir votre schéma à partir de la base, voici quelques considérations générales qui devraient informer le élément vs attribut 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 les données structurées générées à partir d'une base de données peut bien fonctionner avec des valeurs de champ en fin de Compte être placé comme attributs.

cependant XML utilisé comme un transport de message serait souvent mieux en utilisant 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 D'article à un appareil pour imprimer le code à barres cependant, il existe un choix de types d'encodage. Comment représenter le type d'encodage requis? Tout à coup, nous réalisons, un peu tardivement, que le code-barres n'était pas une seule valeur automatique, mais qu'il pouvait ê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-nom pour fixer la structure en pierre, vous pouvez être mieux servi en laissant vos options ouvertes.

IMO XML est à son plus utile quand il peut être fléchi sans briser le code existant en l'utilisant.

j'utilise les lignes directrices suivantes dans la conception de mon schéma en ce qui concerne les attributs et les éléments:

• utiliser des éléments pour le texte à long terme (généralement ceux de chaîne ou normalizedString types)
• N'utilisez pas d'attribut s'il y a un groupement de deux valeurs (par ex. eventStartDate et eventEndDate) pour un élément. Dans l'exemple précédent, il doit y avoir un nouvel élément pour "événement" qui peut contenir la date de début et date de fin attributs.
• la Date, L'heure et le numéro D'entreprise (p. ex. le nombre, le montant et le taux) doivent être élément.
• Non-business éléments comme la dernière mise à jour, expire devrait être attribut.
• les numéros Non commerciaux tels que les codes de hachage et les indices devraient être des attributs.* Utilisez des éléments si le type est complexe.
• utilise les attributs si la valeur est un type simple et ne se répète pas.
• xml: id et xml: lang doit être un attribut faisant référence au schéma XML
• préfère les attributs lorsque cela est techniquement possible.

la préférence pour les attributs est elle fournit les suivants:

• unique (l'attribut ne peut 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 supporte pas en le schéma actuel de la langue)
• bonus est qu'ils sont moins verbeux et utilisent moins de bande passante, mais ce n'est pas vraiment une raison de préférer les attributs aux éléments.

j'ai ajouté lorsque cela est techniquement possible parce qu'il y a des moments où l'utilisation des attributs n'est pas possible. Par exemple, l'attribut choix. Par exemple l'utilisation (startDate et endDate) xor (startTS et endTS) n'est pas possible avec le schéma courant langue

si le schéma XML commence à permettre au modèle de contenu" all "d'être restreint ou étendu, alors je l'abandonnerais probablement

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). Le 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 aussi 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 y a aussi des caractéristiques de divers outils qui le rendent plus facile ou plus difficile à utiliser.

XHTML est un domaine où les attributs ont une utilisation naturelle (par exemple dans class='foo'). Les attributs n'ont pas d'ordre, ce qui peut faciliter l'élaboration d'outils par certaines personnes. Les attributs OTOH sont plus difficiles à saisir sans schéma. Je trouve aussi que les attributs namespaced (foo:bar="zork") sont souvent plus difficiles à gérer dans divers ensembles d'outils. Mais jetez un coup d'oeil à quelques-uns des langages du W3C pour voir le mélange qui est commun. SVG, XSLT, xsd, MathML sont quelques exemples de langues bien connues et toutes ont une richesse fourniture 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>;

noter qu'ils ne sont pas syntaxiquement équivalents et nécessitent un support explicite dans les outils de traitement)

mon conseil serait de jeter un coup d'oeil à la pratique courante dans le domaine le plus proche de votre demande et aussi d'examiner les ensembles d'outils que vous pouvez vouloir appliquer.

enfin faire assurez-vous que vous différenciez les espaces de noms des attributs. Certains systèmes XML (par exemple Linq) représentent des espaces de noms comme attributs dans l'API. IMO c'est laid et potentiellement déroutant.

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

D'autres ont expliqué comment faire la différence entre les attributs et les éléments, mais d'un point de vue plus général, mettre tout dans les attributs parce que cela réduit le XML qui en résulte est une erreur.

XML n'est pas conçu pour être compact mais pour être portable et lisible par l'homme. Si vous voulez diminuer 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 pour la performance maintenant. vous serez étonnés de voir à quelle vitesse un analyseur XML optimisé vous permettra de déchiffrer votre xml. plus important encore, Quelle est votre conception pour l'avenir: au fur et à mesure que le XML évoluera, 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.

c'est discutable dans les deux cas, mais vos collègues ont raison dans le sens où le XML devrait être utilisé pour" markup " ou méta-données autour des données réelles. Pour votre part, vous avez raison sur le fait qu'il est parfois difficile de déterminer où se situe la ligne entre les méta-données et les données lors de la modélisation de votre domaine en XML. En pratique, ce que je fais, c'est prétendre que tout ce qui est dans le markup est caché, et que seules les données en dehors du markup sont lisibles. 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ée si vous pouvez vous permettre la puissance de traitement. XML compresse bien, parfois de façon phénoménale, à cause de son caractère répétitif. J'ai eu de gros fichiers compresser à moins de 5% de leur taille d'origine.

un autre point qui renforce votre position est que pendant que l'autre équipe se dispute sur le style (en ce que la plupart des outils XML manipuleront un document tout-attribut aussi facilement qu'un tous-#PCDATA document) vous faisant valoir les 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 grouper et des attributs pour les données dans la mesure du possible, car je considère que c'est 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>

...Plutôt....

<?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 contient de nombreuses citations ou d'autres caractères qui ont besoin d'échapper alors je dirais qu'il est temps pour décomposer 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>

utiliser 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 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 prédicat, il n'est peut-être pas utile comme méta-données.

rappelez-vous que le XML est censé être lisible par machine et non par l'homme et que pour les documents volumineux, le XML comprime très bien.

Que Diriez-vous de profiter de notre intuition d'orientation d'objet durement acquise? 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.

Tout ce qui a un sens intuitif en tant qu'objets doit s'insérer 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 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.

les deux méthodes pour stocker les propriétés de l'objet sont parfaitement valables. Vous devriez vous écarter des considérations pragmatiques. Essayez de répondre à la question suivante:

1. quelle représentation conduit à une analyse de données plus rapide\génération?
2. quelle représentation permet un transfert de données plus rapide?

3. la lisibilité est-elle importante?

   ...

Juste un couple des corrections à certaines mauvaises info:

@John Ballinger: les attributs peuvent contenir n'importe quel caractère. < > & "'doivent être échappés à < > & "et", respectivement. Si vous utilisez une bibliothèque XML, elle s'en chargera pour vous.

Hell, un attribut peut contenir des données binaires comme une image, si vous voulez vraiment, juste en base64-encodage et en faire une donnée: URL.

@feenster: les attributs peuvent contenir plusieurs éléments séparés par des espaces dans le cas d'ID ou de noms, qui comprendraient des numéros. Pinailleurs, mais cela peut finir par économiser de l'espace.

L'utilisation d'attributs peut maintenir XML concurrentiel avec JSON. Voir Fat Balisage: ajustement de la Graisse de Balisage Mythe des calories à un moment .

cela est très clair en HTML où les différences d'attributs et de balisage peuvent être clairement vues:

1. toutes les données se situent entre le markup
Les attributs
2. sont utilisés pour caractériser ces données (p. ex. formats)

si vous n'avez que des données pures en XML, la différence est moins évidente. Les données peuvent être placées entre des balises ou sous forme d'attributs.

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

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

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

on pourrait aussi dire:" utiliser des attributs pour caractériser l'étiquette, utiliser des étiquettes pour fournir des données elle-même."

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

ainsi, par exemple, le texte non markup appartient toujours aux attributs. Toujours.

appartiennent à la sous-structure ou au contenu. Les textes qui, au fil du temps, peuvent inclure du Sous-contenu structuré intégré appartiennent au contenu. (Dans mon expérience il y a relativement peu de cela - texte avec balisage - lors de L'utilisation du XML pour le stockage ou l'échange de données.)

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 me dis: "l'auteur a-t-il pensé qu'il y aurait des sous-éléments dans l'élément make?" <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.

Étant donné juste mais les règles de manipulation d'espace blanc, je crois que c'était l'intention claire des concepteurs de XML.

je suis d'accord avec feenster. Restez à l'écart des attributs si vous le pouvez. Les éléments sont évolutifs et plus interopérables entre les boîtes à outils des services web. Vous ne trouverez jamais ces boîtes à outils qui sérialisent vos messages de demande/réponse en utilisant des attributs. Cela est également logique puisque nos messages sont des données (et non des métadonnées) pour une boîte à outils de service web.

peuvent facilement devenir difficiles à gérer avec le temps, croyez-moi. je les évite toujours personnellement. Les éléments sont beaucoup plus explicites et lisibles/utilisables à la fois par les analyseurs et les utilisateurs.

la seule fois où je les ai utilisés a été 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 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>