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:
1
<Dictionary>
2
<itemkey="key1"value="value1"/>
3
<itemkey="key2"value="value2"/>
4
<itemkey="key3"value="value2"/>
5
</Dictionary>
oder über Elemente:
1
<Dictionary>
2
<itemkey="key1">value1</item>
3
<itemkey="key2">value2</item>
4
<itemkey="key3">value3</item>
5
</Dictionary>
oder exotisch als Elemente:
1
<Dictionary>
2
<key1>value1</key1>
3
<key2>value2</key2>
4
<key3>value3</key3>
5
</Dictionary>
bzw. exotisch mit Attributen:
1
<Dictionary>
2
<key1value="value1"/>
3
<key2value="value2"/>
4
<key3value="value3"/>
5
</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:
1
<stringname="stringname"value="value"/>
1
<stringname="stringname">value</string>
1
<stringname>value</stringname>
1
<stringnamevalue="value"/>
Gibts da irgendwelche Best Practice Empfehlungen zu?
Danke schonmal.
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)
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.
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.
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.
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.
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)
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.
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)
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.
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
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.
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.
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)