Schema-Variationen: Vor-/Nachteile?!

Hallo zusammen,

XML überfordert mich gerade ein wenig was das aufstellen einer Struktur betrifft… Möglichst ist ja vieles von der Struktur her. Einiges erscheint kurz und leserlich, anderes erscheint von der Struktur her besser. Eine richtige Regel habe ich nicht gefunden. Deshalb mal ein paar Beispiele mit der Frage nach eurer Meinung:

Beispiel 1:

[XML][/XML]

[XML]1/1/1[/XML]

[XML]
Dachgeschoss
1/1/1
[/XML]

Eigentlich gefällt mir 1) am besten. Einfach, übersichtlich. “Bedenken” hab ich wegen dem Attribut “address”, das die eigentliche Haupt-Information für diesen Knoten enthält (siehe 2)

Beispiel 2:

[XML]




[/XML]

[XML]

2</>


127


[/XML]

[XML]

0
2</>


1
127

[/XML]

Variante 1 gefällt mir wieder am besten. Kurz und übersichtlich. Aber auch hier die gleichen Bedenken wie im Beispiel 1. “Value” ist das worum es eigentlich geht.

Wenn ich mir anschaue wie z.B. Maven seine XMLs strukturiert, dann fällt das eher in Richtung Variante 3. Variante 1 finde ich am übersichtlichsten. Ist auch mit Java Bordmitteln am geschicktesten zu parsen (Attribute holen ist einfacher wie weitere Kind-Knoten abklappern). Eventuell geht das mit 3rd Party Libs noch besser. Aber ich würde gerne bei den Bordmitteln bleiben.

Was sagt ihr dazu? Ist Variante 1 “okay” oder eher ein “schlechter Stil”?! Welche der drei Varianten würdet ihr bevorzugen? Oder hat noch jemand eine weitere Variante?!

Gruß
Alex

Bei der Definition von XML-Strukturen orientiere ich mich immer ein bischen daran, wie man es in Java modellieren würde, also:

  • Primitive (Integer, Boolean, String etc.) als Attribut. Einzige Ausnahme: “Lange” Strings, z.B. Texte (in der DB-Welt CLOBs) dafür ein extra Text-Element
  • Komplexe Objekte (alles, was man in Java als eigene Klasse modellieren würde, plus Collections) als Element.
  • Namenskonvention genauso wie in Java, sprich Attribute klein-CamelCase, Elemente groß-Camelcase

Die XML-Definitionen von Maven oder bspw. web.xml halte ich in Stellen für missglückt, weil viel zu verbos.

P.S. Address ist so ein Grenzfall. Vordergründig lässt sich das als primitives Attribut darstellen. Langfristig wird sich dieses aber evtl. zu einem komplexen Typen weiterentwickeln (kann man aus der Ferne nicht sagen). Hier ist die Herausforderung eine ähnliche wie beim Normalisieren von DB-Schemata.

the million dollar question!

Du bist wahrscheinlich nicht erstaunt, wenn ich dir sage, dass diese Design-Frage seit der Erfindung von XML ohne abschließende Antwort diskutiert wird:

@nillehammer
Address: Da “address” eine Hardwareadresse abbildet, ist es äußerst unwahrscheintlich dass sich das nochmal ändert (hat es in den letzten 23 Jahren nicht) und der “Typ” komplexer wird. Wenn dieser Fall doch mal eintritt, werde ich wohl so oder so Version 2.0 der Struktur brauchen.
@Bleiglanz
Ja, das habe ich befürchtet bzw. gehofft. Denn dann könnte ich ruhigen Gewissens bei Variante 1 bleiben. Oder hat noch jemand einen guten Grund in der Schublade unbedingt Variante 2 oder 3 zu verwenden?!

[QUOTE=tuxedo]@nillehammer
Address: Da “address” eine Hardwareadresse abbildet, ist es äußerst unwahrscheintlich dass sich das nochmal ändert (hat es in den letzten 23 Jahren nicht) und der “Typ” komplexer wird. Wenn dieser Fall doch mal eintritt, werde ich wohl so oder so Version 2.0 der Struktur brauchen.
@Bleiglanz
Ja, das habe ich befürchtet bzw. gehofft. Denn dann könnte ich ruhigen Gewissens bei Variante 1 bleiben. Oder hat noch jemand einen guten Grund in der Schublade unbedingt Variante 2 oder 3 zu verwenden?![/QUOTE]

Wenn du für alle Zukunft ausschließen kannst, dass z.B. mal zwei oder Adressen da sind - und du das mal erweitern musst und schon “Bestandsdokumente” da sind (WÜRG), dann ist 1 schon ok.

3 ist halt am flexibelsten, wenn mal irgendwann Änderungen kommen die rückwärtskompatibel abgehandelt werden sollen.

Übrigens nimmt heutzutage scheinbar eh jeder Hinz einfach JSON für Konfigurationsdateien, wenn er kann.

Ja, das kann ich bis auf weiteres ausschließen. Ein Gerät kann nur eine gültige Adresse haben. Das war die letzten Jahrzehnte so, und wird allein schon aus kompatibilitätsgründen auch die nächsten Jahrzehnte so bleiben. Wenn es jemals ein Update des Protokolls das die Geräte sprechen gibt, dann wird eh ein neues Format fällig.

Das XML-Format ist auc nur für Konfigurationsdateien gedacht die geparst, interpretiert und sehr rudimentär und hardwarenah auf Mikrocontroller geschrieben werden. Gleich nach dem parsen ist das Format irrelevant für das Zielsystem. Ich hab also keine weiteren Abhängigkeiten. Von daher bin ich da recht frei im Design des Formats.

Json hab ich mir auch überlegt. Aber XML in dieser einfachen Struktur bekommt auch ein Nicht-Entwickler zusammengebastelt/editiert.

Beispiel 1.3 ist ja interessanterweise eher nicht 2.1, nicht 2.2, nicht 2.3, sondern noch neues 2.4:
[xml]
2
127
2
127

[/xml]

die ganze Aufteilung von Beispiel 2 passt zum ersten Beispiel sowieso nicht besonders,
willst du/ betrachtest du generische Parameter-Tags mit Id oder individuell benannte Tags wie userdescription

außerdem ist alles Beispiel 2 sauber auf einzelne Informationspaare ausgelegt, während in Beispiel 1.1 mehrere Attribute zusammenstehen, unterschiedlicher gehts ja kaum,
eine besondere Empfehlung habe ich leider nicht, aber nochmal diese Anomalie aufzeigend wäre
[xml]



[/xml]
ein noch nicht geposteter Schnippel der es zu betrachten wert ist,
kombininiert das präferierte 2.1 mit der Macht individueller Tags (spart id),
vermeidet die Attributansammlung, welche allerdings nicht direkt schlecht sein muss

ist quasi 1.3, nur besser in 2.1 gelernt :wink:

ab 100.000facher Verwendung empfehle ich v statt value → 100.000x 5 Zeichen eingespart

Ich würde mir dazu mal richtige Objekte/Typen inkl. Wertebereiche definieren. z.B.: … description hört sich für mich nach einem potentiell längeren Text an. Das würde ich dann als CDATA in ein eigenen Tag packen:
[xml]


[/xml]

Als Attribute würde ich glaub nur wichtige Sachen packen, die z.B. für einen Konstruktor interessant sein würden (z.B. address oder ne id). Setter könnten dann wiederrum als eigene Tags dienen:
[xml]

Karl Heiner

[/xml]

Das letzte mal, als ich eine XML-Datei für unser Produkt definiert habe, hat da auch viel vom beabsichtigten Verarbeitungsweg eine Rolle gespielt (+ die Tatsache, dass diese einfach erweiterbar sein soll).

[QUOTE=SlaterB][xml]
2
127
2
127

[/xml]
[/quote]

Hmm, interessant. Gefällt mir auch recht gut. Das würde passen, wenn es tatsächlich bei einem einzigen Wert pro Parameter bleibt.

willst du/ betrachtest du generische Parameter-Tags mit Id oder individuell benannte Tags wie userdescription

In gezeigtem Parameter-Beispiel. referenziert “id” einen anderen knoten irgendwo im XML Baum. Kurz gefasst:
Ein Abschnitt beschreibt ein Gerät mit möglichen Parametern, und der andere Abschnitt “konfiguriert” diese Parameter. Die Trennung in knoten ist beabsichtigt und gewollt.
Aber du hast recht: so richtig getrennt zwischen Dingen die quasi fest vorgegeben sind, und dingen die individuell sind, hab ich nicht. Wenn nur jeweils ein Wert individuell ist, dann passt dein 2.5 Beispiel jedenfalls.

außerdem ist alles Beispiel 2 sauber auf einzelne Informationspaare ausgelegt, während in Beispiel 1.1 mehrere Attribute zusammenstehen, unterschiedlicher gehts ja kaum,

Dein Text liest sich irgendwie schwer?! Warst du in Eile?

Bei Beispiel 1 geht es um das Ding namens “PA”. In Java würde man das wohl so abbilden


    String userdescription;
    String address;

}

Eine ID gibt es nicht. PA hält auch keine Referenzen auf anderes.
Mein naiver Ansatz war (damit es übersichtlich bleibt): Beide vom Benutzer beeinflussbaren Werte des PA in je ein Attribut fassen.
Deshalb stehen da mehrere Attribute zusammen. Beide Beschreiben PA.

eine besondere Empfehlung habe ich leider nicht, aber nochmal diese Anomalie aufzeigend wäre
[xml]



[/xml]
ein noch nicht geposteter Schnippel der es zu betrachten wert ist,

In Anbetracht der Einfachheit von PA (Ein Ding mit 2 Werten) sieht das etwas nach Overkill aus.

Parameter ist übrigens ähnlich einfach aufgebaut. Könnte man so abbilden:


    int id;
    byte value;

}

es ist nur deine selber aufgeworfene Variante 1.3 verbessert auf 2.1 :wink:

wenn PA wirklich so klein und endgültig ist, dann sieht
[xml]1/1/1[/xml]
sparsamer aus, oder als Overkill in die andere Richtung, meinetwegen Underkill:
[xml][/xml]
aber beliebige Parameter als Attributnamen zu nehmen ist wohl nicht besonders klug, Leerzeichen etwa Problem,

1.1 mit den zwei Attributen ist sicherlich das Beste (falls nicht konkrete Probleme dagegen sprechen, ich habe nichts)
und dabei noch erweiterbar, drei oder mehr Attribute gingen auch


na, soviel noch als Rückmeldung, und mein Schreibstil sollte zumindest einem langjährigen Mitglied wie dir doch eigentlich bekannt, wenn nicht geläufig sein, hätte ich vermutet :wink:

[OT]Ich mag SlaterBs Schreibstil. Den erkenne ich auch sofort, ohne auf den Benutzer links zu schauen.[/OT]

Zum Thema: Ich habe mich in einer ähnlichen Situation für Variante 3 entschieden, da die Dateien vom Programm geschrieben und gelesen werden und so robust Änderungen gegenüber sind.