Das habe ich nie behauptet! Es war nur ein Beispiel für eine bessere Struktur als der Mist, den iTunes produziert.
Ds ist das Problem. Du hast bereits in deinem ersten Beitrag ziemlich auf den Putz gehauen und nichts Alternatives genannt. Weil ich wenigstens etwas herausziehen wollte, habe ich dieses Beispiel genommen. Hier sehe ich nur keinen Vorteil.
Du kannst ihn immer noch konkret nennen:
_______________________
Aber nenne ihn doch einfach mal. Irgendwas, was über "ist mir jetzt zu kompliziert", "Das ist nur ein Beispiel, welches nichts belegen soll" oder "mach doch selbst" hinaus geht. Ich meine, dass wenn ich mir etwas anlese, was ich zunächst für blödsinnig halte (und bei Dictionarys ging es mir auch so, weil ich auch so etwas wie <item key="blablabla">wert</item> erwartet hätte), dann denke ich nach, ob ich wirklich so viel schlauer bin als eine Horde von Programmierern bei Apple. Und dann lese ich die Doku aufmerksam, mache mir meine Gedanken, spiele damit herum usw. Am Ende ist es fast immer so, dass ich weiß, warum es so ist, wie es ist und waru das so gut ist. Wenn ich nicht zu diesem Schluss komme, weiß ich wenigstens genau, was mich konkret stört und wie ich es konkret anders gemacht hätte.
Ehrliche Frage: Hast du jemals mit Property-Lists gearbeitet?
Zudem ist daran nichts "logisch falsch". iTunes knallt Dir, dank plist, einfach einen Haufen unstrukturierter Trackdaten um die Ohren.
Das ist ungefähr so, als würde man in einer relationalen Datenbank eine Tabelle anlegen, in die man einfach alle Trackinformationen reinhaut. Sinnvoller wäre es, und ich hoffe, wenigstens da stimmst Du mir zu, es über mehrere Tabellen aufzubauen:
Eine Tabelle für die Interpreten
Eine für die Alben
Eine für die Tracks
Dazwischen gibt es dann die Relationen, die alles in eine ordentliche Struktur bringen.
iTunes mischt außerdem Strukturinformationen ("Artist", "Album"...) mit Daten.
Wie du die Daten strukturierst und in Beziehung setzt, hat weder etwas mit Property-Lists noch etwas mit XML / Property Lists zu tun. Du kannst beides in beiden machen. Sogar mit CVS.
Ich habe mich darüber auch zunächst gewundert, zumal man das sogar in der UI von iTunes hat. Da kannst du nämlich einzelnen Titeln verschiedene Album-Covers geben, zumindest ging das früher. Mit etwas WEITERDENKEN kommt man allerdings darauf, warum das so ist (siehe auch oben): Lieder werden trackweise ausgeliefert. Dementsprechend befindet sich die Albuminformation in den einzelnen Liedern. Man könnte jetzt nur raten, welche Leider ein Album bilden. Das Ganze ließe sich nur dann vernünftig und sicher normalisieren, wenn man eine Album-UID hätte, ebenso eine Künstler-UID. Das würde aber eine internationale und offizielle Datenbank bedingen, die zentral gepflegt wird und vor allem von den Usern in den Tracks gepflegt wird. Spätestens hier ist zappenduster. Die meisten bekommen ja nicht einmal den Albumtitel richtig geschrieben, geschweige denn den Namen des Künstlers. Was willst du da normalisieren? NSKristallkugel als Subklasse von NSWünschelrute?
Mit anderen Worten: Die von dir erwarteten Beziehungen kann ein Musikverwaltungsprogramm gar nicht liefern, ohne den Hass von irgendwelchen Freaks zu bekommen, die wissen, dass es von dem gleichen Album mehrere Versionen gibt. Da hat man sich wohl einfach bei Apple gedacht: Geben wir die Originaldaten aus, wie sie in den Files sind. Und die sind nun einmal ohne Beziehung.
Ich halte das aus den vorgenannten Gründen für richtig. Alles andere wäre Rate mal mit Rosenthal und ei schreckliches Datengepansche. Das kannst du, wenigstens das hoffe ich doch sehr, nicht wirklich wollen.
Ich verstehe aber wie gesagt nicht, was das mit der Diskussion Property-Lists einerseits XML / Property List andererseits zu tun hat. Das eine Betrifft die Formatierung der Daten, das andere die Struktur der Daten. Dein "dank plist" ist daher sicherlich nicht zutreffend.
Aber weißte was: Langsam habe ich keinen Bock mehr, hier den Don Quijote zu geben. Macht doch was ihr wollt.
Das ohnehin.
Oder drücke ich mich tatsächlich so undeutlich aus?