XML-Attribut vs XML-Element

253

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?

Jacob Schön
quelle
4
Ich fand diese wirklich gute Ressource: ibm.com/developerworks/xml/library/x-eleatt.html
Laurens Holst
5
+1 für „... war die Debatte über was war eigentlich Meta - Daten.“
Zurückgehalten
Bitte beachten Sie Kleinbuchstaben mit Bindestrichen: stackoverflow.com/questions/1074447/…
Ben

Antworten:

145

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>
Futter
quelle
22
Ich habe einige der Antworten durchgelesen und etwas, das meiner Erfahrung nach nicht genug betont wurde, ist, dass wenn Sie Daten in einem "Attribut" haben und plötzlich ein> oder <Ihr XML-Dokument kaputt geht, ich denke, es gibt fünf ASCII-Zeichen (>, <, &,?, ") das wird es töten. Wenn dieses Sonderzeichen in einem Element war, können Sie einfach einige CDATA-Tags um diese Daten hinzufügen. Ich würde sagen, verwenden Sie Attribute nur, wenn Sie 100% wissen, welche Werte gesetzt werden Dort, z. B. eine Ganzzahl oder ein Datum, wahrscheinlich alles, was computergeneriert ist. Wenn der Barcode von einem Menschen generiert wurde, sollte er kein Attribut sein.
John Ballinger
39
Wirklich spät zur Party, aber das spezielle ASCII-Zeichen-Argument ist falsch - dafür ist Escape gedacht, sowohl für Attribute als auch für Textdaten.
Micahtan
2
@donroby - Entschuldigung, das wäre mein Fehler bei der Kommunikation. Mit Escape meine ich XML-Codierung. '<' = & lt; usw. Es erscheint mir seltsam, sich zwischen einem Attribut oder Element zu entscheiden, das auf den Zeichen basiert, aus denen der Inhalt besteht, anstatt auf der Bedeutung des Inhalts.
Micahtan
3
@donroby: es ist falsch. Der Ersetzungstext von &lt;is &#60;ist eine Zeichenreferenz und keine Entitätsreferenz. &lt;ist in Attributen OK. Siehe: w3.org/TR/REC-xml/#sec-predefined-ent
porges
14
@ John: Wenn dies ein Problem ist, gibt es etwas in Ihrer Toolchain, das kein gültiges XML erzeugt. Ich denke nicht, dass dies ein Grund ist, zwischen Attributen oder Elementen zu wählen. (Außerdem können Sie nicht "nur CDATA-Tags" um Benutzereingaben hinzufügen, da diese möglicherweise enthalten ]]>!)
porges
48

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

user44350
quelle
2
Erster Punkt ist falsch, siehe: w3.org/TR/xmlschema-2/#derivation-by-list
porges
6
Ich würde sagen, dass der erste Punkt richtig ist und listeine teilweise Problemumgehung für dieses Problem darstellt. Es können nicht mehrere Attribute mit demselben Namen vorhanden sein. Mit listAttribut hat immer noch nur einen Wert, nämlich eine durch Leerzeichen getrennte Liste einiger Datentypen. Trennzeichen sind festgelegt, sodass Sie nicht mehrere Werte haben können, wenn ein einzelner Wert des gewünschten Datentyps Leerzeichen enthalten kann. Dies schließt die Wahrscheinlichkeit aus, dass beispielsweise mehrere Adressen in einem "Adress" -Attribut enthalten sind.
Jasso
7
'Attribute sind schwieriger durch Programmcode zu manipulieren' - Kann dem nicht zustimmen. Tatsächlich habe ich das Gegenteil festgestellt. Es ist nicht genug Unterschied, wirklich so oder so zu sagen.
Paul Alexander
4
Ich möchte auch hinzufügen, dass die Validierung anhand einer DTD mit XML-Schema, Schematron und Relax et al. Nicht mehr wirklich relevant ist. al. Alle bieten wesentlich leistungsfähigere und in einigen Fällen intuitivere Möglichkeiten zur Validierung von XML-Dokumenten. Außerdem ist W3Schools eine wirklich schlechte Referenz für alles
37

"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).

dan04
quelle
32

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>
kjhughes
quelle
23

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.

AnthonyWJones
quelle
Guter Punkt zum "Barcode", ich habe mein Beispiel überstürzt und hätte das definitiv in ein eigenes Element zerlegt. Auch ein guter Punkt auf der XSD / DTD.
Chuck
10

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

Archimedes Trajano
quelle
8

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.

Luke
quelle
8

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.

peter.murray.rust
quelle
6

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

Patrick
quelle
Kleinere XML-Texte sind besser lesbar, nur weil sie kleiner sind!
Nashev
5

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.

Adam
quelle
5

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?

    ...

aku
quelle
5

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.

Michael J.
quelle
4

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.

erickson
quelle
4

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>
Rory Becker
quelle
2
Ich fürchte, das ist völlig falsch - Sie sollten die W3C-Richtlinien befolgen: w3schools.com/DTD/dtd_el_vs_attr.asp - XML ​​sollte nicht nach Lesbarkeit oder "Kompaktheit" erstellt werden, sondern Elemente oder Attribute für diesen Zweck korrekt verwenden für die sie konzipiert wurden.
Vidar
24
Es tut mir leid, aber das ist irreführend. Die W3schools-Seite enthält keine W3C-Richtlinien. Die W3C-XML-Empfehlung (an der ich teilgenommen habe) ermöglicht die Verwendung von Elementen und Attributen entsprechend den Anforderungen und Stilen der Benutzer.
Peter.murray.rust
4

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.

rpattabi
quelle
2

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 .

brianary
quelle
Nicht nur IDs oder Namen. Sie können durch Leerzeichen getrennte Listen von fast allem enthalten.
John Saunders
@ JohnSaunders IDS oder NAMES sind spezifische DTD-Typen (auch XML-Schema, glaube ich), die von den meisten XML-Prozessoren auf niedriger Ebene unterstützt werden. Wenn sie von der Anwendungsschicht anstelle der XML-Bibliotheken verarbeitet werden, funktionieren alle Arten von Zeichendaten (getrennte Werte oder was auch immer).
Brian
Nur weil du kannst, heißt das nicht, dass du es solltest.
Lankymart
1
@Lankymart Wie gesagt, ich habe nur einige falsche Informationen korrigiert (die aus irgendeinem Grund hoch bewertet wurden). Binärdaten gehören normalerweise überhaupt nicht in XML.
Brian
1

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.

MGrier
quelle
eine der wenigen Erklärungen, die ich lesen kann. Ich habe keine Ahnung, ob es eine gute Idee ist oder nicht ... aber zumindest verstehe ich den Punkt;)
Thufir
0

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

Walter A. Jablonowski
quelle
-1

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.

ottodidakt
quelle
-1

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>
oh Topf
quelle