XML, Daten in Attribute oder Elemente

[Tim T. (tim_taylor)]

Hallo,

ich brauche mal einen Rat wohin man am sinnvollsten die Daten in XML 
stecken sollte, in Attribute oder in Elemente.

Als Beispiel nehme ich einfach mal ein Dictionary (key/value-Elemente) 
das ich in XML speichern will, das kann ich entweder über Attribute 
machen:

<Dictionary>
      <item key="key1" value="value1" />
      <item key="key2" value="value2" />
      <item key="key3" value="value2" />
</Dictionary>

oder über Elemente:

<Dictionary>
      <item key="key1">value1</item>
      <item key="key2">value2</item>
      <item key="key3">value3</item>
</Dictionary>

oder exotisch als Elemente:

<Dictionary>
      <key1>value1</key1>
      <key2>value2</key2>
      <key3>value3</key3>
</Dictionary>

bzw. exotisch mit Attributen:

<Dictionary>
      <key1 value="value1" />
      <key2 value="value2" />
      <key3 value="value3" />
</Dictionary>

Von der Optik her würde ich eher zu Variante mit (normalen) Elementen 
tendieren.


Wobei das bei einfachen Variablen (z.B. Strings) auch wieder 
verschiedene Möglichkeiten aufwirft:

<string name="stringname" value="value" />

<string name="stringname">value</string>

<stringname>value</stringname>

<stringname value="value" />

Gibts da irgendwelche Best Practice Empfehlungen zu?

Danke schonmal.

[Jan H. (j_hansen)]

Wurscht

Ich mache es gerne mit Elementen, deine zweite Variante, aber erlaubt 
ist was gefällt.

[A. S. (rava)]

Enhalten deine Werte Anführungszeichen? Dan müsstest du sie "escapen", 
um Attribute verwenden zu können.

[re (Gast)]

Tim T. schrieb:
> in Attribute oder in Elemente.

Tja, best practice hängt davon ab.
In jedem Fall eine die ersten beiden Varianten, weil das am 
generischsten zu parsen ist.

Wenn "Value" noch weiter unterstrukturiert ist, dann bleibt nur die 
zweite Variante mit dem Element.

Aber wenn es das nicht ist, würde ich es vermeiden, beim Parsen mögliche 
Unterstrukturen im Input berücksichtigen oder abfangen zu müssen und 
bevorzuge ganz klar die erste Variante (Attribute).

Die Exoten verkomplizieren dagegen nur die generische Beschreibung. Tags 
sind dafür gedacht, Datenstrukturen zu unterscheiden, nicht Inhalte.

my2ct
(re)

[MaWin (Gast)]

In den Elementnamen <elementname> würde ich nichts nutzerdefiniertes 
stecken.
Das macht es schwieriger zu parsen und außerdem ist man nicht frei bei 
der Zeichenwahl.

[Tim T. (tim_taylor)]

A. S. schrieb:
> Enhalten deine Werte Anführungszeichen? Dan müsstest du sie "escapen",
> um Attribute verwenden zu können.

Das Escapen von allen Zeichen welche die XML Struktur stören, ist 
bereits berücksichtigt.

re schrieb:
> Tim T. schrieb:
>> in Attribute oder in Elemente.
>
> Tja, best practice hängt davon ab.
> In jedem Fall eine die ersten beiden Varianten, weil das am
> generischsten zu parsen ist.

Darum hatte ich die anderen Varianten auch als exotisch beschrieben, war 
eher der Vollständigkeit halber als wirkliche Umsetzung, eben wegen den 
damit verbundenen Einschränkungen und Komplexität beim Parsen. Es ist 
deutlich einfacher eine NodeList mittels SelectNodes("item") zu bekommen 
als wenn man sich blind drauf verlassen muss das alle Kindelemente genau 
eine Ebene tiefer dazu gehören.

> Wenn "Value" noch weiter unterstrukturiert ist, dann bleibt nur die
> zweite Variante mit dem Element.

Stimmt, das wäre ein Punkt für Elemente wenn man unbedingt einen 
allgemeinen Parser bauen will.

> Aber wenn es das nicht ist, würde ich es vermeiden, beim Parsen mögliche
> Unterstrukturen im Input berücksichtigen oder abfangen zu müssen und
> bevorzuge ganz klar die erste Variante (Attribute).

Und da ist dann der Einfachheitspunkt für die Attribute.^^

> Die Exoten verkomplizieren dagegen nur die generische Beschreibung. Tags
> sind dafür gedacht, Datenstrukturen zu unterscheiden, nicht Inhalte.

Logisch, wobei ich zugeben muss das ich davon bei einfachen Datentypen 
(Strings) da bislang nicht wirklich konsequent war (z.B. kam immer mal 
wieder sowas vor: <hostname>subdomain.domain.tld</hostname>).

Bin nur am überlegen wie ich das dann am besten mit den Tags für die 
Dictionarys löse. Bislang habe ich immer den Elementnamen als Namen/Art 
des Dictionarys benutzt, müsste da dann konsequenterweise ja auch 
generisch bei <dictionary> bleiben und den Namen als Attribut ins 
Element reinsetzen, was dann aber das Parsen etwas umständlicher macht.

MaWin schrieb:
> In den Elementnamen <elementname> würde ich nichts nutzerdefiniertes
> stecken.
> Das macht es schwieriger zu parsen und außerdem ist man nicht frei bei
> der Zeichenwahl.

Jop, hatte ich auch so gesehen.

Also bislang stehts 1:1 wobei ich selber noch immer nicht schlüssig bin 
wie herum ich es ab jetzt baue.

[MaWin (Gast)]

Tim T. schrieb:
> Also bislang stehts 1:1 wobei ich selber noch immer nicht schlüssig bin
> wie herum ich es ab jetzt baue.

Es hat auch etwas mit Vernunft zu tun, wie man sich entscheidet. Man 
muss ein vernünftiges Mittel zwischen Attributen und Subtags finden.
Wenn du mal absolut schreckliche Beispiele sehen willst, also so wie man 
es nicht macht, dann schaue dir mal Autosar-XML-Dateien (.arxml) an. Da 
ist praktisch alles mit Subtags gelöst und alles in Großbuchstaben.
Absolut unlesbarer Quatsch.

[Experte (Gast)]

1.) XML ist kacke.
2.) Wenn doch XML, dann daran orientieren, wie man den Kram weiter 
verarbeiten will, also wie man per XPath etc. gut drauf zugreifen kann.

[re (Gast)]

MaWin schrieb:
> Man muss ein vernünftiges Mittel zwischen Attributen und Subtags finden.

Als brauchbares Kriterium habe ich bisher empfunden: "Wenn es sich um 
einen primitiven Datentyp handelt und das Datum höchsteńs einmal im 
Knoten vorkommt (m.a.W. eindeutig sein muss), dann sollte es als 
Attribut formuliert werden. Sonst als Subtag."

Das führt manchmal zu einer länglichen Attributliste, aber ansonsten 
kommt man eben zu solchen Negativbeispielen wie:

> Wenn du mal absolut schreckliche Beispiele sehen willst, also so wie man
> es nicht macht, dann schaue dir mal Autosar-XML-Dateien (.arxml) an. Da
> ist praktisch alles mit Subtags gelöst und alles in Großbuchstaben.
> Absolut unlesbarer Quatsch.

(re)

[Tim T. (tim_taylor)]

Experte schrieb:
> 1.) XML ist kacke.

Absolut, für den Datenaustausch benutze auch lieber JSON nur brauche ich 
dafür immer extra Libs und die Lesbarkeit ist noch schlechter.

> 2.) Wenn doch XML, dann daran orientieren, wie man den Kram weiter
> verarbeiten will, also wie man per XPath etc. gut drauf zugreifen kann.

Aktuell geht es mir erstmal um einen Ersatz für ini-Dateien der nicht 
komplett selber gestrickt ist und dabei auch noch annehmbar zu lesen 
ist. Will aber jetzt schon einen Standard haben der auch auf zukünftige 
Zwecke übertragbar ist.

re schrieb:
> MaWin schrieb:
>> Man muss ein vernünftiges Mittel zwischen Attributen und Subtags finden.
>
> Als brauchbares Kriterium habe ich bisher empfunden: "Wenn es sich um
> einen primitiven Datentyp handelt und das Datum höchsteńs einmal im
> Knoten vorkommt (m.a.W. eindeutig sein muss), dann sollte es als
> Attribut formuliert werden. Sonst als Subtag."

Also praktisch alle primitiven Datentypen in Attributschreibweise weil 
es im Grunde ja nicht möglich ist zwei Variablen mit gleichem Namen (und 
Werten) an der gleichen Stelle in der Hierarchie zu haben.

[re (Gast)]

Tim T. schrieb:
> Also praktisch alle primitiven Datentypen in Attributschreibweise weil
> es im Grunde ja nicht möglich ist zwei Variablen mit gleichem Namen
> an der gleichen Stelle in der Hierarchie zu haben.

Im Extremfall ja. Aber:

(1) In realen Programmen könnte man auf die Idee kommen, seine Variablen 
in hierarchischen Strukturen/Klassen strukturieren zu wollen oder auch 
mal Listen oder eben Arrays Dictionaries (ach ja, da war was...) haben 
zu wollen. Dann kommen natürlich doch wieder Subtags ins Spiel. Wie Du 
ja eingangs schon demonstriert hast.

(2) Und wenn Du vorhast, in einer INI-Datei sowohl primitive Typen als 
auch strukturierte Typen zu mischen und trotzdem generisch zu parsen, 
kann es wiederum Vorteile haben, generell für beides die unform zweite 
Variante zu benutzten.

(re)

[Tim T. (tim_taylor)]

re schrieb:
> Tim T. schrieb:
>> Also praktisch alle primitiven Datentypen in Attributschreibweise weil
>> es im Grunde ja nicht möglich ist zwei Variablen mit gleichem Namen
>> an der gleichen Stelle in der Hierarchie zu haben.
>
> Im Extremfall ja. Aber:
>
> (1) In realen Programmen könnte man auf die Idee kommen, seine Variablen
> in hierarchischen Strukturen/Klassen strukturieren zu wollen oder auch
> mal Listen oder eben Arrays Dictionaries (ach ja, da war was...) haben
> zu wollen. Dann kommen natürlich doch wieder Subtags ins Spiel. Wie Du
> ja eingangs schon demonstriert hast.

Womit wie aber wieder bei nicht primitiven Datentypen wären die ja 
ausgenommen waren.

> (2) Und wenn Du vorhast, in einer INI-Datei sowohl primitive Typen als
> auch strukturierte Typen zu mischen und trotzdem generisch zu parsen,
> kann es wiederum Vorteile haben, generell für beides die unform zweite
> Variante zu benutzten.

Tja, schlechte Karten für jemanden wie mich der eine vernünftige 
Universallösung sucht.

[quotendepp (Gast)]

Tim T. schrieb:
> Ersatz für ini-Dateien der nicht komplett selber gestrickt ist

yaml? kann auch komplexere datentypen, ist lesbar, hat nicht so viel 
overhead wie xml

Experte schrieb:
> 1.) XML ist kacke

can't agree more

[Rolf M. (rmagnus)]

MaWin schrieb:
> Wenn du mal absolut schreckliche Beispiele sehen willst, also so wie man
> es nicht macht, dann schaue dir mal Autosar-XML-Dateien (.arxml) an. Da
> ist praktisch alles mit Subtags gelöst und alles in Großbuchstaben.
> Absolut unlesbarer Quatsch.

Ja, Autosar XML ist wirklich das beste Beispiel dafür, wie man es nicht 
macht. Das gibt ja mittlerweile auch ziemliche Probleme bei aktuellen 
Dateien, deren Größe dann Richtung 1 GB geht. Wie viel das an Zeit und 
RAM beim Parsen kostet, kann man sich vorstellen.
Ich fand aber auch schon xmlrpc recht furchtbar, wenn auch da die 
Tagnamen etwas maßvoller benutzt werden.

<params><param><value><int>5</int></value></param></params>

Tim T. schrieb:
> Experte schrieb:
>> 1.) XML ist kacke.
>
> Absolut, für den Datenaustausch benutze auch lieber JSON nur brauche ich
> dafür immer extra Libs und die Lesbarkeit ist noch schlechter.

Außerdem haben sie vergessen, Kommentare zu unterstützen.

[Proktologe (Gast)]

Rolf M. schrieb:
> Außerdem haben sie vergessen, Kommentare zu unterstützen.

{
....
"comment": "bla sülz";
....
}

[re (Gast)]

Tim T. schrieb:
> Tja, schlechte Karten für jemanden wie mich der eine vernünftige
> Universallösung sucht.

Tja, einen Tod muss man am Ende immer sterben.

Aber soooo tragisch ist es am Ende auch wieder nicht:
Beispiel: Eine Datenstruktur wird als XML-Knoten abgebildet.

(1) Alle primitiven Membervariablen landen in den Attributen des Knotens 
und welchen Typ die jeweils haben weißt Du vorher anhand des 
Programmcodes und musst es also nicht im Knoten mit abspeichern. Nur 
serialisieren und deserialisieren.

(2) Alle nicht-primitiven Membervariablen werden als Sub-Knoten 
abgebildet (rekursiv). Deren Tag gibt den Typen an, ein besonderes 
Magic-Attribut den Variablennamen, falls nötig. (Und ja: ich weiß dass 
das inkonsequent zu Fall (1) ist, siehe Eingangssatz.)

Nebenbei: Für anständig balancierte Konfigurationsdaten stehen die 
Chancen recht gut, dass für einen Knoten jeweils entweder nur Fall (1) 
oder nur Fall (2) in Reinkultur auftreten.

Nur so als Beispiel, jeder hat da wohl seine eigenen Design-Patterns.



JSON macht die Sache hier in imho übrigens nicht besser sondern 
bestenfalls anders. Zwar kommt man dort deutlich schwerer auf die 
Idee, eine solch ... unachtsame ... Ressourcenverschwendung à la
|
|  <params><param><value><int>5</int></value></param></params>
|
zu betreiben, aber sowas ist auch in XML nicht notwendig.



(re)