XML-Attribut vs XML-Element

Bei der Arbeit werden wir aufgefordert, XML-Dateien zu erstellen, um Daten an eine andere Offline-Anwendung zu übergeben. Diese erstellt dann eine zweite XML-Datei, die zurückgegeben werden muss, um einige unserer Daten zu aktualisieren. Während des Prozesses haben wir mit dem Team der anderen Anwendung über die Struktur der XML-Datei gesprochen.

Das Beispiel, das ich mir ausgedacht habe, ist im Wesentlichen so etwas wie:

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

Das andere Team sagte, dass dies kein Industriestandard sei und dass Attribute nur für Metadaten verwendet werden sollten. Sie schlugen vor:

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

Der Grund, warum ich den ersten vorgeschlagen habe, ist, dass die Größe der erstellten Datei viel kleiner ist. Während der Übertragung befinden sich ungefähr 80000 Elemente in der Datei. Ihr Vorschlag in Wirklichkeit ist dreimal so groß wie der von mir vorgeschlagene. Ich suchte nach dem mysteriösen "Industriestandard", der erwähnt wurde, aber am ehesten konnte ich feststellen, dass XML-Attribute nur für Metadaten verwendet werden sollten, sagte aber, dass es in der Debatte um Metadaten ging.

Wie bestimmen Sie nach der langwierigen Erklärung (sorry), was Metadaten sind, und wie sollten Sie beim Entwerfen der Struktur eines XML-Dokuments entscheiden, wann ein Attribut oder ein Element verwendet werden soll?

Ich benutze diese Faustregel:

1. Ein Attribut ist etwas, das in sich geschlossen ist, dh eine Farbe, eine ID, ein Name.
2. Ein Element ist etwas, das eigene Attribute hat oder haben könnte oder andere Elemente enthalten könnte.

Ihre ist also nah. Ich hätte so etwas gemacht wie:

BEARBEITEN : Das ursprüngliche Beispiel wurde basierend auf dem unten stehenden Feedback aktualisiert.

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

Einige der Probleme mit Attributen sind:

• Attribute können nicht mehrere Werte enthalten (untergeordnete Elemente können)
• Attribute sind nicht einfach zu erweitern (für zukünftige Änderungen)
• Attribute können keine Strukturen beschreiben (untergeordnete Elemente können)
• Attribute sind schwieriger durch Programmcode zu manipulieren
• Attributwerte sind nicht einfach mit einer DTD zu testen

Wenn Sie Attribute als Container für Daten verwenden, erhalten Sie Dokumente, die schwer zu lesen und zu pflegen sind. Versuchen Sie, Elemente zur Beschreibung von Daten zu verwenden. Verwenden Sie Attribute nur, um Informationen bereitzustellen, die für die Daten nicht relevant sind.

Beenden Sie nicht so (so sollte XML nicht verwendet werden):

<note day="12" month="11" year="2002" 
      to="Tove" to2="John" from="Jani" heading="Reminder"  
      body="Don't forget me this weekend!"> 
</note>

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

"XML" steht für "eXtensible Markup Language". Eine Auszeichnungssprache bedeutet, dass es sich bei den Daten um Text handelt, der mit Metadaten zur Struktur oder Formatierung gekennzeichnet ist.

XHTML ist ein Beispiel für XML, das so verwendet wurde, wie es beabsichtigt war:

<p><span lang="es">El Jefe</span> insists that you
    <em class="urgent">MUST</em> complete your project by Friday.</p>

Hier ist die Unterscheidung zwischen Elementen und Attributen klar. Textelemente werden im Browser angezeigt und Attribute sind Anweisungen , wie sie angezeigt werden (obwohl es ein paar Tags sind , die nicht auf diese Weise funktionieren).

Verwirrung entsteht, wenn XML nicht als Auszeichnungssprache, sondern als Datenserialisierungssprache verwendet wird, in der die Unterscheidung zwischen "Daten" und "Metadaten" vager ist. Die Wahl zwischen Elementen und Attributen ist also mehr oder weniger willkürlich, mit Ausnahme von Dingen, die nicht mit Attributen dargestellt werden können (siehe die Antwort von Feenster).

XML-Element gegen XML-Attribut

Bei XML dreht sich alles um Übereinstimmung. Wenden Sie sich zunächst an vorhandene XML-Schemas oder etablierte Konventionen in Ihrer Community oder Branche.

Wenn Sie wirklich in der Lage sind, Ihr Schema von Grund auf zu definieren, finden Sie hier einige allgemeine Überlegungen, die die Entscheidung zwischen Element und Attribut beeinflussen sollten :

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

Dies kann von Ihrer Verwendung abhängen. XML, das zur Darstellung strukturierter Daten verwendet wird, die aus einer Datenbank generiert wurden, funktioniert möglicherweise gut, wenn letztendlich Feldwerte als Attribute platziert werden.

XML, das als Nachrichtentransport verwendet wird, ist jedoch häufig besser, wenn mehr Elemente verwendet werden.

Nehmen wir zum Beispiel an, wir hätten dieses XML wie in der Antwort vorgeschlagen: -

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

Jetzt möchten wir das ITEM-Element an ein Gerät senden, um den Barcode zu drucken. Es gibt jedoch eine Auswahl an Codierungstypen. Wie stellen wir den erforderlichen Codierungstyp dar? Plötzlich stellen wir etwas verspätet fest, dass der Barcode kein einzelner automatischer Wert war, sondern möglicherweise mit der beim Drucken erforderlichen Codierung qualifiziert ist.

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

Der Punkt ist, wenn Sie nicht eine Art XSD oder DTD zusammen mit einem Namespace erstellen, um die Struktur in Stein zu fixieren, können Sie am besten Ihre Optionen offen lassen.

IMO XML ist am nützlichsten, wenn es gebogen werden kann, ohne vorhandenen Code damit zu beschädigen.

In meinem Schemaentwurf verwende ich die folgenden Richtlinien in Bezug auf Attribute und Elemente:

• Verwenden Sie Elemente für Text mit langer Laufzeit (normalerweise solche vom Typ string oder normalizedString).
• Verwenden Sie kein Attribut, wenn zwei Werte (z. B. eventStartDate und eventEndDate) für ein Element gruppiert sind. Im vorherigen Beispiel sollte es ein neues Element für "event" geben, das die Attribute startDate und endDate enthalten kann.
• Geschäftsdatum, DateTime und Zahlen (z. B. Anzahl, Betrag und Rate) sollten Elemente sein.
• Nicht geschäftliche Zeitelemente wie die letzte Aktualisierung, die abläuft, sollten Attribute sein.
• Nicht-Geschäftsnummern wie Hash-Codes und Indizes sollten Attribute sein. * Verwenden Sie Elemente, wenn der Typ komplex sein soll.
• Verwenden Sie Attribute, wenn der Wert ein einfacher Typ ist und sich nicht wiederholt.
• xml: id und xml: lang müssen Attribute sein, die auf das XML-Schema verweisen
• Bevorzugen Sie Attribute, wenn dies technisch möglich ist.

Die Präferenz für Attribute ist, dass sie Folgendes bietet:

• eindeutig (das Attribut kann nicht mehrmals angezeigt werden)
• Reihenfolge spielt keine Rolle
• Die oben genannten Eigenschaften sind vererbbar (dies wird vom Inhaltsmodell "all" in der aktuellen Schemasprache nicht unterstützt.)
• Der Bonus ist, dass sie weniger ausführlich sind und weniger Bandbreite verbrauchen, aber das ist nicht wirklich ein Grund, Attribute gegenüber Elementen zu bevorzugen.

Ich habe hinzugefügt, wenn dies technisch möglich ist, da es Zeiten gibt, in denen die Verwendung von Attributen nicht möglich ist. Zum Beispiel Attributsatzauswahl. Beispielsweise ist die Verwendung von (startDate und endDate) xor (startTS und endTS) mit der aktuellen Schemasprache nicht möglich

Wenn das XML-Schema zulässt, dass das Inhaltsmodell "Alle" eingeschränkt oder erweitert wird, würde ich es wahrscheinlich löschen

Im Zweifelsfall KISS - warum Attribute und Elemente mischen, wenn Sie keinen klaren Grund haben, Attribute zu verwenden. Wenn Sie sich später für die Definition einer XSD entscheiden, wird diese ebenfalls sauberer. Wenn Sie sich dann noch später dazu entschließen, eine Klassenstruktur aus Ihrer XSD zu generieren, ist dies ebenfalls einfacher.

Es gibt keine universelle Antwort auf diese Frage (ich war stark an der Erstellung der W3C-Spezifikation beteiligt). XML kann für viele Zwecke verwendet werden - textähnliche Dokumente, Daten und deklarativer Code sind drei der häufigsten. Ich benutze es auch oft als Datenmodell. Es gibt Aspekte dieser Anwendungen, bei denen Attribute häufiger vorkommen, und andere, bei denen untergeordnete Elemente natürlicher sind. Es gibt auch Funktionen verschiedener Tools, die die Verwendung einfacher oder schwieriger machen.

XHTML ist ein Bereich, in dem Attribute eine natürliche Verwendung haben (z. B. in class = 'foo'). Attribute haben keine Reihenfolge und dies kann es einigen Leuten erleichtern, Werkzeuge zu entwickeln. OTOH-Attribute sind ohne Schema schwerer einzugeben. Ich finde auch, dass Namespace-Attribute (foo: bar = "zork") in verschiedenen Toolsets oft schwieriger zu verwalten sind. Schauen Sie sich jedoch einige der W3C-Sprachen an, um die übliche Mischung zu sehen. SVG, XSLT, XSD, MathML sind einige Beispiele für bekannte Sprachen und alle verfügen über ein reichhaltiges Angebot an Attributen und Elementen. Einige Sprachen erlauben sogar mehr als eine Möglichkeit, dies zu tun, z

<foo title="bar"/>;

oder

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

Beachten Sie, dass diese syntaktisch NICHT gleichwertig sind und explizite Unterstützung in Verarbeitungswerkzeugen erfordern.

Mein Rat wäre, einen Blick auf die gängige Praxis in dem Bereich zu werfen, der Ihrer Anwendung am nächsten liegt, und zu überlegen, welche Toolsets Sie möglicherweise anwenden möchten.

Stellen Sie schließlich sicher, dass Sie Namespaces von Attributen unterscheiden. Einige XML-Systeme (z. B. Linq) repräsentieren Namespaces als Attribute in der API. IMO das ist hässlich und möglicherweise verwirrend.

Andere haben behandelt, wie man Attribute von Elementen unterscheidet, aber aus einer allgemeineren Perspektive ist es falsch, alles in Attribute zu setzen, weil dadurch das resultierende XML kleiner wird.

XML ist nicht kompakt, sondern portabel und für den Menschen lesbar. Wenn Sie die Größe der übertragenen Daten verringern möchten, verwenden Sie etwas anderes (z. B. die Protokollpuffer von Google ).

die Millionen-Dollar-Frage!

Machen Sie sich jetzt zunächst keine allzu großen Sorgen um die Leistung. Sie werden erstaunt sein, wie schnell ein optimierter XML-Parser Ihre XML-Datei durchsucht. Was ist Ihr Design für die Zukunft? Wie werden Sie im Zuge der Weiterentwicklung des XML die lose Kopplung und Interoperabilität aufrechterhalten?

Konkreter können Sie das Inhaltsmodell eines Elements komplexer gestalten, es ist jedoch schwieriger, ein Attribut zu erweitern.

Beide Methoden zum Speichern der Objekteigenschaften sind vollkommen gültig. Sie sollten von pragmatischen Überlegungen abweichen. Versuchen Sie folgende Frage zu beantworten:

1. Welche Darstellung führt zu einer schnelleren Datenanalyse / -generierung?

2. Welche Darstellung führt zu einer schnelleren Datenübertragung?

3. Ist Lesbarkeit wichtig?

   ...

Verwenden Sie Elemente für Daten und Attribute für Metadaten (Daten zu den Daten des Elements).

Wenn ein Element in Ihren ausgewählten Zeichenfolgen als Prädikat angezeigt wird, haben Sie ein gutes Zeichen dafür, dass es ein Attribut sein sollte. Wenn ein Attribut niemals als Prädikat verwendet wird, sind es möglicherweise keine nützlichen Metadaten.

Denken Sie daran, dass XML maschinenlesbar und nicht von Menschen lesbar sein soll und dass XML für große Dokumente sehr gut komprimiert wird.

Es ist so oder so fraglich, aber Ihre Kollegen haben Recht in dem Sinne, dass das XML für "Markup" oder Metadaten um die tatsächlichen Daten verwendet werden sollte. Sie haben Recht, dass es manchmal schwierig ist zu entscheiden, wo die Grenze zwischen Metadaten und Daten liegt, wenn Sie Ihre Domain in XML modellieren. In der Praxis tue ich so, als ob alles im Markup versteckt wäre und nur die Daten außerhalb des Markups lesbar sind. Ist das Dokument auf diese Weise sinnvoll?

XML ist notorisch sperrig. Für Transport und Lagerung wird die Komprimierung dringend empfohlen, wenn Sie sich die Rechenleistung leisten können. XML wird aufgrund seiner Wiederholbarkeit gut, manchmal phänomenal gut komprimiert. Ich habe große Dateien auf weniger als 5% ihrer ursprünglichen Größe komprimieren lassen.

Ein weiterer Punkt, um Ihre Position zu stärken, ist, dass Sie, während das andere Team über den Stil argumentiert (da die meisten XML-Tools ein Dokument mit allen Attributen genauso einfach handhaben wie ein Dokument mit allen # PCDATA-Dokumenten), über praktische Aspekte streiten. Während Stil nicht völlig ignoriert werden kann, sollten technische Vorzüge mehr Gewicht haben.

Es ist größtenteils eine Frage der Präferenz. Ich verwende Elemente zum Gruppieren und Attribute für Daten, wo dies möglich ist, da ich dies als kompakter als die Alternative betrachte.

Zum Beispiel bevorzuge ich .....

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

...Anstatt....

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

Wenn ich jedoch Daten habe, die sich nicht leicht innerhalb von beispielsweise 20 bis 30 Zeichen darstellen lassen oder viele Anführungszeichen oder andere Zeichen enthalten, die maskiert werden müssen, würde ich sagen, dass es Zeit ist, die Elemente aufzubrechen ... möglicherweise mit CData-Blöcken.

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

Wie wäre es, wenn Sie unsere hart erarbeitete Intuition zur Objektorientierung nutzen? Normalerweise finde ich es einfach zu denken, welches ein Objekt und welches ein Attribut des Objekts ist oder auf welches Objekt es sich bezieht.

Was als Objekte intuitiv sinnvoll ist, soll als Element passen. Seine Attribute (oder Eigenschaften) wären Attribute für diese Elemente in XML oder ein untergeordnetes Element mit Attribut.

Ich denke, für einfachere Fälle wie im Beispiel funktioniert die Objektorientierungsanalogie in Ordnung, um herauszufinden, welches Element und welches Attribut eines Elements ist.

Nur ein paar Korrekturen an einigen schlechten Informationen:

@ John Ballinger: Attribute können beliebige Zeichendaten enthalten. <> & "'muss in & lt; & gt; & amp; & quot; bzw. & apos; maskiert werden. Wenn Sie eine XML-Bibliothek verwenden, wird dies für Sie erledigt.

Zum Teufel, ein Attribut kann Binärdaten wie ein Bild enthalten, wenn Sie es wirklich wollen, indem Sie es einfach mit base64 codieren und zu einer Daten-URL machen.

@feenster: Attribute können bei IDS oder NAMES durch Leerzeichen getrennte mehrere Elemente enthalten, die Zahlen enthalten würden. Nitpicky, aber das kann Platz sparen.

Durch die Verwendung von Attributen kann XML mit JSON konkurrenzfähig bleiben. Siehe Fat Markup: Den Fat Markup-Mythos kalorienreduzieren .

Ich bin immer wieder überrascht über die Ergebnisse dieser Art von Diskussionen. Für mich gibt es eine sehr einfache Regel, um zu entscheiden, ob Daten zu einem Attribut oder als Inhalt gehören und ob die Daten eine navigierbare Unterstruktur haben.

So gehört beispielsweise Nicht-Markup-Text immer zu Attributen. Immer.

Listen gehören in Unterstruktur oder Inhalt. Text, der im Laufe der Zeit eingebettete strukturierte Unterinhalte enthalten kann, gehört zum Inhalt. (Nach meiner Erfahrung gibt es relativ wenig davon - Text mit Markup -, wenn XML zum Speichern oder Austauschen von Daten verwendet wird.)

Das so geschriebene XML-Schema ist prägnant.

Wann immer ich Fälle wie <car><make>Ford</make><color>Red</color></car>sehe, denke ich mir: "Hat der Autor gedacht, dass es Unterelemente innerhalb des make-Elements geben würde?" <car make="Ford" color="Red" />ist deutlich besser lesbar, es gibt keine Frage, wie Leerzeichen behandelt werden würden usw.

Angesichts der Regeln für die Behandlung von Leerzeichen glaube ich, dass dies die klare Absicht der XML-Designer war.

Dies ist in HTML sehr deutlich, wo die Unterschiede zwischen Attributen und Markups deutlich erkennbar sind:

1. Alle Daten befinden sich zwischen Markup
2. Zur Charakterisierung dieser Daten werden Attribute verwendet (z. B. Formate).

Wenn Sie nur reine Daten als XML haben, gibt es einen weniger deutlichen Unterschied. Daten können zwischen Markup oder als Attribute stehen.

=> Die meisten Daten sollten zwischen Markup stehen.

Wenn Sie hier Attribute verwenden möchten: Sie können Daten in zwei Kategorien einteilen: Daten und "Metadaten", wobei Metadaten nicht Teil des Datensatzes sind, den Sie präsentieren möchten, aber Dinge wie "Formatversion", "Erstellungsdatum". , etc.

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

Man könnte auch sagen: "Verwenden Sie Attribute, um das Tag zu charakterisieren, verwenden Sie Tags, um Daten selbst bereitzustellen."

Ich stimme Feenster zu. Halte dich von Attributen fern, wenn du kannst. Elemente sind evolutionär und interoperabler zwischen Web-Service-Toolkits. Sie würden diese Toolkits niemals finden, die Ihre Anforderungs- / Antwortnachrichten mithilfe von Attributen serialisieren. Dies ist auch sinnvoll, da unsere Nachrichten Daten (keine Metadaten) für ein Webdienst-Toolkit sind.

Attribute können im Laufe der Zeit leicht schwierig zu verwalten sein. Vertrauen Sie mir. Ich halte mich immer persönlich von ihnen fern. Elemente sind viel expliziter und sowohl für Parser als auch für Benutzer lesbar / verwendbar.

Ich habe sie nur verwendet, um die Dateierweiterung einer Asset-URL zu definieren:

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

Ich denke, wenn Sie 100% wissen, dass das Attribut nicht erweitert werden muss, können Sie sie verwenden, aber wie oft wissen Sie das.

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