XML-Attribut vs. XML-Element
https://stackoverflow.com/questions/33746
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Bei der Arbeit werden wir gebeten, XML-Dateien zu erstellen, um Daten an eine andere Offline-Anwendung weiterzuleiten, die dann eine zweite XML-Datei erstellt, die wir zurückgeben, 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, sieht im Wesentlichen so aus:
<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 das erste vorgeschlagen habe, ist, dass die Größe der erstellten Datei viel kleiner ist.Während der Übertragung befinden sich etwa 80.000 Elemente in der Datei.Ihr Vorschlag ist in Wirklichkeit dreimal größer als der, den ich vorgeschlagen habe.Ich suchte nach dem mysteriösen „Industriestandard“, der erwähnt wurde, konnte aber am ehesten finden, dass XML-Attribute nur für Metadaten verwendet werden sollten, sagte aber, dass es bei der Debatte darum gehe, was eigentlich Metadaten seien.
Nach der langwierigen Erklärung (tut mir leid) wie bestimmen Sie, was Metadaten sind, und wie sollten Sie beim Entwerfen der Struktur eines XML-Dokuments entscheiden, wann ein Attribut oder ein Element verwendet werden soll?
Lösung
Ich verwende diese Faustregel:
- Ein Attribut ist etwas, das in sich geschlossen ist, also eine Farbe, eine ID, ein Name.
- Ein Element ist etwas, das eigene Attribute hat oder haben könnte oder andere Elemente enthalten könnte.
Deines liegt also in der Nähe.Ich hätte so etwas getan:
BEARBEITEN:Das ursprüngliche Beispiel wurde basierend auf dem Feedback unten aktualisiert.
<ITEM serialNumber="something">
<BARCODE encoding="Code39">something</BARCODE>
<LOCATION>XYX</LOCATION>
<TYPE modelNumber="something">
<VENDOR>YYZ</VENDOR>
</TYPE>
</ITEM>
Andere Tipps
Einige der Probleme mit Attributen sind:
- Attribute können nicht mehrere Werte enthalten (untergeordnete Elemente können)
- Attribute sind nicht einfach erweiterbar (für zukünftige Änderungen)
- Attribute können keine Strukturen beschreiben (untergeordnete Elemente können dies)
- Attribute sind durch Programmcode schwieriger 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 verwalten 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.
Enden 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>
„XML“ steht für „eXtensible“. Markup Sprache".Eine Auszeichnungssprache impliziert, dass es sich bei den Daten um Text handelt. markiert mit Metadaten zur Struktur oder Formatierung.
XHTML ist ein Beispiel für die beabsichtigte Verwendung von XML:
<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 dazu Wie um sie anzuzeigen (obwohl es einige Tags gibt, die auf diese Weise nicht funktionieren).
Verwirrung entsteht, wenn XML nicht als Auszeichnungssprache, sondern als verwendet wird Datenserialisierung Sprache, in der die Unterscheidung zwischen „Daten“ und „Metadaten“ vager ist.Die Wahl zwischen Elementen und Attributen ist also mehr oder weniger willkürlich, außer bei Dingen, die dies tun kippen mit Attributen dargestellt werden (siehe Feensters Antwort).
XML-Element vs. XML-Attribut
Bei XML dreht sich alles um Übereinstimmung. Orientieren Sie sich zunächst an allen vorhandenen XML-Schemas oder etablierten 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 Ihnen als Orientierung dienen sollten Entscheidung zwischen Element und 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>
Es kann von Ihrer Nutzung abhängen.XML, das zur Darstellung strukturierter Daten verwendet wird, die aus einer Datenbank generiert werden, funktioniert möglicherweise gut, wenn letztendlich Feldwerte als Attribute platziert werden.
Bei der Verwendung von XML als Nachrichtentransport wäre es jedoch oft besser, mehr Elemente zu verwenden.
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 Kodierungstypen.Wie stellen wir den erforderlichen Kodierungstyp dar?Plötzlich wird uns, etwas verspätet, klar, dass es sich bei dem Barcode nicht um einen einzelnen automatischen Wert handelte, sondern dass er möglicherweise mit der beim Drucken erforderlichen Codierung qualifiziert wurde.
<ITEM serialNumber="something">
<barcode encoding="Code39">something</barcode>
<Location>XYX</LOCATION>
<TYPE modelNumber="something">
<VENDOR>YYZ</VENDOR>
</TYPE>
</ITEM>
Der Punkt ist: Sofern Sie nicht eine Art XSD oder DTD zusammen mit einem Namespace erstellen, um die Struktur in Stein zu fixieren, ist es möglicherweise am besten, wenn Sie Ihre Optionen offen lassen.
Meiner Meinung nach ist XML am nützlichsten, wenn es erweitert werden kann, ohne dass vorhandener Code beschädigt wird.
Ich verwende in meinem Schemaentwurf die folgenden Richtlinien in Bezug auf Attribute vs.Elemente:
- Verwenden Sie Elemente für Langzeittext (normalerweise die von String- oder Normalisierungsstring -Typen)
- Verwenden Sie kein Attribut, wenn zwei Werte gruppiert sind (z. B.eventStartDate und eventEndDate) für ein Element.Im vorherigen Beispiel sollte es ein neues Element für "Ereignis" geben, das die Attribute für Startdate und Enddate enthalten kann.
- Geschäftsdatum, DateTime und Zahlen (z. B.Zählungen, Betrag und Rate) sollten Elemente sein.
- Nicht-Business-Zeitelemente wie zuletzt aktualisiert, die abgelaufen sind, sollten Attribute sein.
- Nicht geschäftliche Zahlen wie Hash-Codes und Indizes sollten Attribute sein.* Verwenden Sie Elemente, wenn der Typ komplex ist.
- 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 besteht darin, dass sie Folgendes bietet:
- eindeutig (das Attribut darf nicht mehrfach vorkommen)
- Reihenfolge spielt keine Rolle
- Die oben genannten Eigenschaften sind vererbbar (dies ist etwas, das das „all“-Inhaltsmodell in der aktuellen Schemasprache nicht unterstützt)
- Der Vorteil besteht darin, dass sie weniger ausführlich sind und weniger Bandbreite verbrauchen, aber das ist kein wirklicher Grund, Attribute gegenüber Elementen zu bevorzugen.
Ich fügte hinzu wenn technisch möglich weil es Zeiten gibt, in denen die Verwendung von Attributen nicht möglich ist.Zum Beispiel Auswahlmöglichkeiten für Attributsätze.Beispielsweise ist die Verwendung von (startDate und endDate) xor (startTS und endTS) mit der aktuellen Schemasprache nicht möglich
Wenn XML Schema anfängt, das „all“-Inhaltsmodell einzuschränken oder zu erweitern, würde ich es wahrscheinlich fallen lassen
Auf diese Frage gibt es keine allgemeingültige Antwort (ich war maßgeblich 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 gebräuchlichsten.Ich verwende es auch häufig 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 ihre Verwendung erleichtern oder erschweren.
XHTML ist ein Bereich, in dem Attribute eine natürliche Verwendung haben (z. B.in class='foo').Attribute haben keine Reihenfolge und dies kann für einige Leute die Entwicklung von Werkzeugen erleichtern.OTOH-Attribute sind ohne Schema schwieriger einzugeben.Ich finde auch, dass Namespace-Attribute (foo:bar="zork") in verschiedenen Toolsets oft schwieriger zu verwalten sind.Aber werfen Sie einen Blick auf einige der W3C-Sprachen, um die häufige Mischung zu erkennen.SVG, XSLT, XSD, MathML sind einige Beispiele bekannter 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 eine explizite Unterstützung in Verarbeitungstools 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 auch zu überlegen, welche Toolsets Sie möglicherweise anwenden möchten.
Stellen Sie abschließend sicher, dass Sie Namespaces von Attributen unterscheiden.Einige XML-Systeme (z.B.Linq) stellen Namespaces als Attribute in der API dar.Meiner Meinung nach ist das hässlich und möglicherweise verwirrend.
Im Zweifel, KUSS – Warum Attribute und Elemente mischen, wenn es keinen klaren Grund für die Verwendung von Attributen gibt?Wenn Sie sich später dazu entschließen, eine XSD zu definieren, wird auch diese sauberer.Wenn Sie sich dann noch später dazu entschließen, eine Klassenstruktur aus Ihrer XSD zu generieren, wird das auch einfacher sein.
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 durchforstet.Was noch wichtiger ist: Was ist Ihr Entwurf für die Zukunft?Wie können Sie bei der Weiterentwicklung von XML die lose Kopplung und Interoperabilität aufrechterhalten?
Konkreter gesagt: Sie können das Inhaltsmodell eines Elements komplexer gestalten, es ist jedoch schwieriger, ein Attribut zu erweitern.
Verwenden Sie Elemente für Daten und Attribute für Metadaten (Daten über die Daten des Elements).
Wenn in Ihren Auswahlzeichenfolgen ein Element als Prädikat angezeigt wird, ist das ein gutes Zeichen dafür, dass es sich um ein Attribut handeln sollte.Wenn ein Attribut niemals als Prädikat verwendet wird, handelt es sich möglicherweise ebenfalls um keine nützlichen Metadaten.
Denken Sie daran, dass XML maschinenlesbar und nicht für Menschen lesbar sein soll und dass sich XML bei großen Dokumenten sehr gut komprimieren lässt.
Andere haben beschrieben, wie man zwischen Attributen und Elementen unterscheiden kann, aber aus einer allgemeineren Perspektive ist es falsch, alles in Attribute zu packen, weil dadurch das resultierende XML kleiner wird.
XML ist nicht darauf ausgelegt, kompakt zu sein, sondern portabel und für Menschen lesbar zu sein.Wenn Sie die Größe der übertragenen Daten verringern möchten, verwenden Sie etwas anderes (z. B Protokollpuffer von Google).
Darüber lässt sich so oder so streiten, aber Ihre Kollegen haben Recht in dem Sinne, dass XML für „Markup“ oder Metadaten rund um die eigentlichen Daten verwendet werden sollte.Sie haben Ihrerseits Recht damit, dass es manchmal schwierig ist, bei der Modellierung Ihrer Domain in XML zu entscheiden, wo die Grenze zwischen Metadaten und Daten verläuft.In der Praxis tue ich so, als ob alles im Markup verborgen wäre und nur die Daten außerhalb des Markups lesbar wären.Ergibt das Dokument in dieser Hinsicht irgendeinen Sinn?
XML ist notorisch umfangreich.Für Transport und Lagerung ist die Komprimierung dringend zu empfehlen, wenn Sie sich die Rechenleistung leisten können.XML lässt sich aufgrund seiner Wiederholbarkeit gut, manchmal sogar phänomenal gut komprimieren.Ich habe erlebt, dass große Dateien auf weniger als 5 % ihrer ursprünglichen Größe komprimiert wurden.
Ein weiterer Punkt zur Stärkung Ihrer Position besteht darin, dass Sie, während das andere Team über den Stil streitet (da die meisten XML-Tools ein All-Attribute-Dokument genauso einfach verarbeiten wie ein All-#PCDATA-Dokument), Sie über praktische Aspekte streiten.Während der Stil nicht völlig außer Acht gelassen werden kann, sollten technische Vorzüge mehr Gewicht haben.
Beide Methoden zum Speichern von Objekteigenschaften sind vollkommen gültig.Von pragmatischen Überlegungen sollte man abrücken.Versuchen Sie, die folgende Frage zu beantworten:
- Welche Darstellung führt zu einer schnelleren Datenanalyse/-generierung?
- Welche Darstellung führt zu einer schnelleren Datenübertragung?
Ist Lesbarkeit wichtig?
...
Es ist größtenteils eine Frage der Präferenz.Ich verwende nach Möglichkeit Elemente zum Gruppieren und Attribute für Daten, da ich dies für kompakter halte als die Alternative.
Ich bevorzuge zum Beispiel.....
<?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 nicht einfach innerhalb von beispielsweise 20 bis 30 Zeichen dargestellt werden können oder viele Anführungszeichen oder andere Zeichen enthalten, die maskiert werden müssen, dann würde ich sagen, dass es an der Zeit ist, die Elemente herauszubrechen ...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 wir uns unsere hart erarbeitete Intuition zur Objektorientierung zunutze machen?Normalerweise finde ich es einfach, darüber nachzudenken, was ein Objekt und was ein Attribut des Objekts ist oder auf welches Objekt es sich bezieht.
Was auch immer als Objekte intuitiv Sinn macht, soll als Elemente hineinpassen.Seine Attribute (oder Eigenschaften) wären Attribute für diese Elemente in XML oder untergeordnete Elemente mit Attribut.
Ich denke, dass in einfacheren Fällen wie im Beispiel die Objektorientierungsanalogie gut funktioniert, um herauszufinden, welches Element und welches Attribut eines Elements ist.
Nur ein paar Korrekturen zu einigen schlechten Informationen:
@John Ballinger:Attribute können beliebige Zeichendaten enthalten.< > & " ' müssen in < maskiert werden>&"Und ', jeweils.Wenn Sie eine XML-Bibliothek verwenden, übernimmt diese dies für Sie.
Verdammt, ein Attribut kann binäre Daten wie ein Bild enthalten, wenn Sie es wirklich wollen, indem Sie es einfach base64 kodieren und daraus Daten machen:URL.
@feenster:Attribute können im Fall von IDS oder NAMES mehrere durch Leerzeichen getrennte Elemente enthalten, zu denen auch Zahlen gehören würden.Kleinlich, aber das kann am Ende Platz sparen.
Durch die Verwendung von Attributen kann XML gegenüber JSON konkurrenzfähig bleiben.Sehen Fettaufschlag:Den Fat-Markup-Mythos um eine Kalorie nach der anderen reduzieren.
Ich bin immer wieder überrascht von den Ergebnissen solcher Diskussionen.Für mich gibt es eine sehr einfache Regel für die Entscheidung, ob Daten in ein Attribut oder als Inhalt gehören, nämlich ob die Daten eine navigierbare Unterstruktur haben.
So gehört beispielsweise Nicht-Markup-Text immer zu den Attributen.Stets.
Listen gehören in die Unterstruktur oder den Inhalt.Texte, die im Laufe der Zeit eingebettete strukturierte Unterinhalte enthalten können, gehören zum Inhalt.(Meiner Erfahrung nach gibt es davon – Text mit Markup – relativ wenig, wenn XML zur Datenspeicherung oder zum Datenaustausch verwendet wird.)
Das auf diese Weise geschriebene XML-Schema ist prägnant.
Immer wenn ich Fälle sehe wie <car><make>Ford</make><color>Red</color></car>, denke ich mir: „Mensch, hat der Autor gedacht, dass es Unterelemente innerhalb des make-Elements geben würde?“ <car make="Ford" color="Red" /> ist wesentlich besser lesbar, es besteht kein Zweifel daran, wie mit Leerzeichen umgegangen wird usw.
Angesichts der Regeln für den Umgang mit Leerzeichen glaube ich, dass dies die klare Absicht der XML-Designer war.
Dies wird in HTML sehr deutlich, wo die Unterschiede zwischen Attributen und Markup deutlich zu erkennen sind:
- Alle Daten liegen zwischen Markup
- Zur Charakterisierung dieser Daten werden Attribute verwendet (z.B.Formate)
Wenn Sie nur reine Daten als XML haben, ist der Unterschied weniger deutlich.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, sondern Dinge wie „Formatversion“, „Erstellungsdatum“ usw.
<customer format="">
<name></name>
...
</customer>
Man könnte auch sagen:„Verwenden Sie Attribute, um das Tag zu charakterisieren, und verwenden Sie Tags, um Daten selbst bereitzustellen.“
Ich stimme Feenster zu.Halten Sie sich, wenn möglich, von Attributen fern.Elemente sind entwicklungsfreundlich und interoperabler zwischen Webdienst-Toolkits.Sie würden nie finden, dass diese Toolkits Ihre Anfrage-/Antwortnachrichten mithilfe von Attributen serialisieren.Dies ist auch sinnvoll, da es sich bei unseren Nachrichten um Daten (keine Metadaten) für ein Webservice-Toolkit handelt.
Mit der Zeit kann es leicht schwierig werden, Attribute zu verwalten, vertrauen Sie mir.Ich persönlich halte mich immer von ihnen fern.Elemente sind weitaus expliziter und sowohl für Parser als auch für Benutzer lesbar/verwendbar.
Ich habe sie nur einmal verwendet, um die Dateierweiterung einer Asset-URL zu definieren:
<image type="gif">wank.jpg</image> ...etc etc
Ich denke, wenn Sie zu 100 % wissen, dass das Attribut nicht erweitert werden muss, könnten Sie sie verwenden, aber wie oft wissen Sie das?
<image>
<url>wank.jpg</url>
<fileType>gif</fileType>
</image>
