XML - Wann was?



  • Tach,
    ich habe gerade ein paar XML Files vor mir die alle relevanten Daten in Attribute gepackt haben.
    Irgendwie wirkt das ziemlich falsch. Man kann es zwar benutzen, aber ich glaube nicht das dies der ideale Weg ist.
    bspl.: <Artikel preis="2.80" name="Bohrmaschiene" typ="werkzeug"/>

    Ich packe Daten in Elemente:
    <artikel>
    <typ>Werkzeug</typ>
    <name>Bohrmaschine</name>
    <preis>2.80</preis>
    </artikel>

    Vielleicht kann mir jemand erklären wie man ein XML richtig aufbaut... beides kann nicht richtig sein... soll doch wohl nicht richtig sein.



  • Generell packt man alle wichtigen Daten in die Tags und nicht in die Attribute. Als Grundregel kannst du dir das wie HTML vorstellen. Die wichtigen Dinge, also das, worauf es wirklich ankommt, sieht man auch wenn man alle Attribute ignoriert.

    Speicher das hier:

    <Artikel preis="2.80" name="Bohrmaschiene" typ="werkzeug"/>
    

    mal als test.html ab und öffne es im Browser.

    Dann speicher das hier:

    <artikel> 
    <typ>Werkzeug</typ> 
    <name>Bohrmaschine</name> 
    <preis>2.80</preis> 
    </artikel>
    

    dagegen ergibt:

    Werkzeug Bohrmaschine 2.80
    

    als test.html ab und öffne es im Browser.

    Der Unterschied ist klar. Das Prinzip ist, dass ich als Maschine, auch wenn ich keine Ahnung habe vom verwendeten Schema habe, dennoch davon ausgehen kann, dass in den Tags das wichtige Zeug steht. Die Attribute aber - mit denen kann man nichts anfangen, wenn man nicht genau weiß, was sie eigentlich bedeuten. Deshalb ist letzteres Beispiel gutes Design während ersteres böse ist.



  • Vielen Dank für die Bestätigung.
    Das habe ich auch vermutet.
    Naja, sowas haben wir von einer "professionellen" Firma erhalten. Das hat mich ein wenig verunsichert.



  • ich finde die erste methode ist wesentlich lesbarer (vom quelltext) und kompakter

    für den datenaustausch würde ich es bevorzugen,
    da die daten mir am wie die member einer klasse vorkommen, und nicht wie der inhalt eines containers

    das browser das dann evtl nicht so darstellen wie man sich das wünscht ist ein unschöner nebeneffekt, aber es gibt ja xslt



  • Natürlich ist es kompakter alles in Attribute zu packen. Nur ist das wenig sinnvoll. Browser sind nicht der Grund sondern lediglich eine Veranschaulichung. Attribute sind eben Zusatzinformationen aber nicht die Informationen selbst. Deswegen kann es beliebig viele Attribute geben - auf die kommt es ja schließlich eigentlich nicht an. Das ist der Grundgedanke.
    Es ist ohnehin sinnfrei für den Datenaustausch eine Form zu verwenden, die dir als Mensch toll erscheint. Da schreibst du besser gleich einen Brief oder rufst an. Normalerweise ist Datenaustausch aber eine maschinelle Angelegenheit, die ein Mensch als Bonus verstehen können soll. Das ist XML. Und dafür sollte man es so machen, wie ich sagte.



  • Und du meinst, der Preis eines Artikels (gemäß dem Beispiel) ist eher ein Unterelement des Artikels als ein Attribut desselben?



  • Reyx schrieb:

    Und du meinst, der Preis eines Artikels (gemäß dem Beispiel) ist eher ein Unterelement des Artikels als ein Attribut desselben?

    Hältst du Knotenebenen in XML tatsächlich für objektorientierte Vererbungshierarchien oder was willst du mir damit sagen?



  • Das, was ich gesagt habe:
    Attribute würde ich attributiv verwenden, Unterelemente als Unterelemente.

    Der Preis eines Objektes (nicht das "Objekt" in der Informatik sondern das "Objekt" als irgendetwas) ist für mich ein Attribut, nicht jedoch ein Element des Objektes.

    Mit Vererbungshierarchien hat das imho gar nichts zu tun; wie auch immer du darauf kommst, ich könnte das meinen 😉



  • Also ist deine Aussage einfach eine typische Null-Aussage in der die verwendeten Begriffe willkürlich und undefiniert sind?
    "Ein Attribut ist attributiv und ein Unterelement ist ein Unterelement" ist eine wunderbare Defintion die überhaupt nichts definiert und einen Aussagewert von ziemlich genau gar nichts hat ... zur Vererbung komme ich also weil ich deiner Aussage Sinn zugebilligt habe 😉



  • minhen schrieb:

    Die Attribute aber - mit denen kann man nichts anfangen, wenn man nicht genau weiß, was sie eigentlich bedeuten. Deshalb ist letzteres Beispiel gutes Design während ersteres böse ist.

    Huh?

    Wenn nun Typ und Preis "das wichtig Zeug" sind, dann müssen sie doch nach Deiner Regel im Tag stehen. Wieso ist dann absolut gesehen (zumindest formulierst Du es so absolut) das erste Beispiel böse?

    Abseit davon, wenn man Preis als Unterelement zulässt, wäre es dann nicht möglich mehrere Preise anzugeben? - Was ist wenn ich das nicht will.



  • Jester schrieb:

    Wenn nun Typ und Preis "das wichtig Zeug" sind, dann müssen sie doch nach Deiner Regel im Tag stehen. Wieso ist dann absolut gesehen (zumindest formulierst Du es so absolut) das erste Beispiel böse?

    Weil mit "im Tag stehen" der Inhalt des Elements gemeint ist (um W3C-Sprache zu verwenden). Was eigentlich auch schon alleine deshalb sonnenklar ist, da der Gegensatz zu Attributen sonst keinen Sinn machen würde: <tag Attribute>Inhalt</tag>

    Abseit davon, wenn man Preis als Unterelement zulässt, wäre es dann nicht möglich mehrere Preise anzugeben? - Was ist wenn ich das nicht will.

    Document Type Definition, XML Schema.



  • minhen schrieb:

    Also ist deine Aussage einfach eine typische Null-Aussage in der die verwendeten Begriffe willkürlich und undefiniert sind?

    http://de.wikipedia.org/wiki/Attribut



  • Der interessante Punkt ist das Unterelement. Aber lass gut sein, ich kann mir denken was du meinst und weshalb das ein völlig unbrauchares Prinzip für die Datenorganisation ist, aber vermuten darf ich's ja nicht und du sagst es nicht...



  • imho sollten daten kompakt organisiert sein

    xml ist da recht nutzlos da es dafür komzipiert worden ist alles mögliche irgendwie auszutauschen

    für die daten aus dem beispiel ist technisch gesehen csv am geeignetsten,
    da es keine der extra features, die xml mit mehr und/oder redundanten daten erkauft benötigt



  • Sonderzeichen/Umlaute im Attribut gehen sowieso nicht



  • es gibt die &foo; notation, und ich denke das festgelegte encoding hat auch einen gewissen einfluss



  • Ursprünglich wollte ich noch schreiben, dass man an der Art der Verwendung von Attributen auch sieht, ob jemand XML verstanden hat - oder ob er es nur verwendet, weil er es verwenden "muss". Das hab ich dann aber für zu streitlustig befunden und sein lassen. Ändert aber natürlich nichts daran, dass es stimmt.

    r0nny schrieb:

    für die daten aus dem beispiel ist technisch gesehen csv am geeignetsten,
    da es keine der extra features, die xml mit mehr und/oder redundanten daten erkauft benötigt

    Mich beeindruckt zwar, wie du das mit so wenig Informationen diagnostizieren kannst, aber ich frage trotzdem. Warum genau ist hier CSV "technisch gesehen" besser geeignet? Und warum benötigt es keine "Extra-Features" von XML?



  • edit: ah okay, nach ein paarmal lesen hab ich's dann doch noch verstanden was Du sagen willst.

    Kannst Du mal ein Beispiel angeben bei dem Attribute sinnvoll ist?



  • Na idealerweise bei Metadaten. Also die eigentlichen Daten in den Inhalt der Elemente und Informationen über diesen Inhalt in die Attribute. Gute Beispiele dafür wären z.B. IDs, welche die gespeicherten Elemente eindeutig identifizieren, oder Sprachinformationen für den Inhalt des Elements. Hängt aber immer davon ab, was Metadaten und was Daten sind.


Anmelden zum Antworten