XML - Wann was?
-
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?
-
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ötigtMich 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.