Die Welt von XML erlösen

[Matti]

XML ist ein sehr schlechtes Container-Format: es ist unübersichtlich zu lesen, unzumutbar zu schreiben und hat einen großen Speicher-Overhead. Die Alternativen JSON und Protobuf sind zwar nicht ganz so schlecht, aber auch nicht gut. Das habe ich als Anlass genommen, ein besseres Format zu entwickeln: jedes Element in einer Baum-Struktur hat Name, Typ und Wert und die Struktur wird mit Tab-Einrückungen realisiert. Jede Zeile hat die Syntax Name^Typ=Wert, wobei alle Elemente optional sind, d.h. man kann auch Name=Wert schreiben, wenn man keine Typ-Informationen braucht. Hier ein Beispiel:

^Person
firstName=Anton
lastName=Anders
birthday^Date
day=25
month=11
year=1982
citizenship=German

Abgesehen von der deutlich besseren Les- & Schreibbarkeit ist auch der Speicherbedarf nur halb so groß wie bei XML.

Hier gibt es weitere Informationen und eine C++ Library zum Download: http://sourceforge.net/p/tab-structured-file/wiki/Tab Structured File/

Was haltet ihr von diesem Format?

[Monger]

Jetzt mal unter der irrwitzigen Annahme dass der Beitrag ernst gemeint ist und kein Trollversuch: skizzieren wir mal ein paar Anforderungen, und schauen dann wie gut dein Format diese erfüllt.

* Lesbarkeit durch Menschen: gut. Das Format wurde offensichtlich darauf optimiert, ist relativ nah an csv dran. Schwierigkeiten dürften führende und nachfolgende Leerzeichen machen, tiefe Strukturen dürften schnell unleserlich werden.
* Schreibbarkeit durch Menschen: mittel. Tabs werden nicht von jedem Editor gleichermaßen gut verstanden. Leerzeichen statt Tabs werden vermutlich zu Syntaxfehlern führen, die aber schwer diagnostizierbar sein werden.
* Lesbarkeit durch Maschinen: mies. Menschen sind auf Metainformationen nicht so angewiesen, aber für den Rechner ist das meist ziemlich relevant. Leerzeichen, Gleichheitszeichen oder Tabs als Steuerzeichen zu verwenden ist ungeschickt, weil die in der natürlichen Sprache relativ häufig vorkommen. Die müssen also alle aufwändig escaped werden. Auch programmatisch sind Metadaten dringend notwendig um Informationen zu filtern und zu finden.

Moderne XML Parser sind aufgrund der extrem homogenen Datenstruktur unfassbar schnell - schneller als die meisten anderen vergleichbaren Textparser. XML ist auch kein Format was sich nur auf Dateien beschränkt - XML lässt sich auch super streamen, dort fallen Formatierungen üblicherweise weg. XML lässt sich zur Laufzeit sehr schnell und einfach komprimieren und dekomprimieren, damit erreicht man nicht selten Dateigrößen die deutlich geringer sind als vergleichbare Binärformate (wer es nicht glaubt, der speichere mal in Office einmal als xls und dann als xlsx).

XML ist in erster Linie als transparentes Datenformat für eine Maschine-zu-Maschine Kommunikation gedacht. Dass Menschen dort auch reinschauen können ist erwünscht, aber bei weitem nicht die wichtigste Eigenschaft.

[No.3]

...damit erreicht man nicht selten Dateigrößen die deutlich geringer sind als vergleichbare Binärformate (wer es nicht glaubt, der speichere mal in Office einmal als xls und dann als xlsx)...

LOL, das meinst Du doch wohl nicht ernst ?! Kann eine xls Datei etwa nicht auch noch komprimiert werden z.B. zippen?

Ist aber auch gar nicht nötig, es gibt schliesslich auch noch das xlsb Format d.h. xls aber von Excel schon komprimiert. Beispieldatei von mir:

xls: 1272 kb
xlsm: 354 kb
xlsb: 286 kb
xls als zip: 250 kb


Aber zum Thema, XML mag ich persönlich auch nicht, ggf. verstehe ich das Konzept einfach nur nicht, aber wie Monger schon richtig schreibt, Dein Format ist u.a. schwierig zu parsen und eben die Problematik der Steuerzeichen.

[Matti]

* Lesbarkeit durch Menschen: gut. Das Format wurde offensichtlich darauf optimiert, ist relativ nah an csv dran. Schwierigkeiten dürften führende und nachfolgende Leerzeichen machen, tiefe Strukturen dürften schnell unleserlich werden.
Leerzeichen im Wert führen zu gar keinen Problemen. Führende Leerzeichen im Namen können die Struktur unübersichtlich machen, allerdings sind Namen, die mit Leerzeichen beginnen, sowieso unüblich. In XML darf ein Tag-Name gar kein Leerzeichen enthalten. Eventuell könnte man es bei TSF genauso machen. Strukturen mit mehr als 20 Ebenen könnten tatsächlich wegen der Bildschirmbreite unübersichtlich werden. Aber wann hat man das schon? Außerdem möchte ich auch kein XML mit 20 Ebenen lesen.

* Schreibbarkeit durch Menschen: mittel. Tabs werden nicht von jedem Editor gleichermaßen gut verstanden. Leerzeichen statt Tabs werden vermutlich zu Syntaxfehlern führen, die aber schwer diagnostizierbar sein werden
Stimmt. Trotzdem bin ich der Meinung, dass die Vorteile von TSF überwiegen.

* Lesbarkeit durch Maschinen: mies. Menschen sind auf Metainformationen nicht so angewiesen, aber für den Rechner ist das meist ziemlich relevant. Leerzeichen, Gleichheitszeichen oder Tabs als Steuerzeichen zu verwenden ist ungeschickt, weil die in der natürlichen Sprache relativ häufig vorkommen. Die müssen also alle aufwändig escaped werden. Auch programmatisch sind Metadaten dringend notwendig um Informationen zu filtern und zu finden.
In XML müssen noch viel mehr Zeichen escaped werden. Und Meta-Informationen kann man in TSF auch unterbringen, z.B. im Typ oder als Child des betreffenden Knotens. Außerdem ist TSF performanter zu parsen. Also ist die Maschinenlesbarkeit noch etwas besser als bei XML.

Moderne XML Parser sind aufgrund der extrem homogenen Datenstruktur unfassbar schnell - schneller als die meisten anderen vergleichbaren Textparser. XML ist auch kein Format was sich nur auf Dateien beschränkt - XML lässt sich auch super streamen, dort fallen Formatierungen üblicherweise weg. XML lässt sich zur Laufzeit sehr schnell und einfach komprimieren und dekomprimieren, damit erreicht man nicht selten Dateigrößen die deutlich geringer sind als vergleichbare Binärformate (wer es nicht glaubt, der speichere mal in Office einmal als xls und dann als xlsx).
TSF ist im Durchschnitt halb so groß wie formatiertes XML und immernoch 40% kleiner als unformatiertes. Und komprimieren kann man TSF ja auch noch.

[EPIC_FAIL]

Hast du dir schon zwecks "Usability" eine Encoding Rule für TSF für ASN.1 überlegt?

[Watson007]

untauglich. Möchte gar nicht wissen wie schnell bei Hand-Bearbeitung solcher Dateien sich da Fehler einschleusen wie Leerzeichen statt Tab und ähnliches

benutz doch einfach XML-Tools für Bearbeitung solcher Dateien.
Also nicht unbedingt solche Tools wie Altova XMLSpy welche bei der Installation ein Loch in die Firewall bohren und nach Hause telefonieren...

[RattuS]

In deinem Beispiel ist ein namenloser Key mit dem Datentyp "Person"? Ein namenloser Key? Wie greift man denn auf einen namenlosen Key zu?

Wozu gibt es überhaupt Datentypen? Gibt es eine Schema-Definition?

Wie funktionieren Listen/Arrays? Scheinbar ist der einzige Unterschied zwischen Object/Struktur und Array ein "=" in der selben Zeile + Umbruch? Verwirrend. Das könnte ich früher oder später wahrscheinlich nicht mehr auseinanderhalten.

Zeilenumbrüche nur als "|"... und schon geht die Lesbarkeit flöten, weil es keine Absätze mehr geben kann.


Insgesamt erscheint mir dieses Format überflüssig und schlechter lesbar als die üblichen Standards. Nein, ich verzichte.


Nur mal so zum Vergleich (JSON vs. "TSF" vs. XML):

http://i.imgur.com/QPlzyzq.jpg

Wie man sehen kann, bietet XML dank Attribute mehr Flexibilität bei der Beschreibung der Daten. Bei deinem TSF lässt sich bei "books"/"book" sowie "authors"/"published" übrigens die potenzielle Fehleranfälligkeit zwischen object und array schon ganz gut erkennen.

Bekomme ich jetzt einen Keks für meine Bemühungen? ;D

[Leonidas]

Wenn man schon ein neues Format ersinnt, sollte 2 Dinge da dringend vorkommen:

1. Die Verschachtelung sollte derart erfolgen, daß es auch bei tiefen Verschachtelungen noch Menschen-lesbar bleibt.

2. Alle in natürlicher Sprache vorkommende Sonderzeichen dürfen nicht als Steuerzeichen verwendet werden. Insbesondere Anführungs- und Leerzeichen nicht. Trotzdem müssen die Steuerzeichen absolut eindeutig sein, um Syntaxfehler zu vermeiden.

[Ectoplasma]

Tabs als Teil der Syntax ... vergiss es. Das ist schon bei "make" beschissen.

[Sven77]

Bei Python ist es klasse. Aber wo das Problem bei XML liegt verstehe ich nicht, die bearbeitet man seltenst von Hand. Dafür ist das Parsing solide, ich greife gerne darauf zurück.

[Matti]

In Version 1.2 der C++ Library werde ich verbieten, dass Namen mit Leerzeichen beginnen (Werte können natürlich weiterhin mit Leerzeichen beginnen). Damit würde ich 2 Probleme lösen:

1. Man kann mit führenden Leerzeichen keine verwirrenden Strukturen mehr erzeugen.
2. Der Parser würde erkennen, wenn man die Einrückungen versehentlich mit Leerzeichen anstatt Tabs macht. Dann könnte eine aussagekräftige Fehlermeldung kommen und umständliche Fehlersuche (wie von Monger angemerkt) würde entfallen.

2. Alle in natürlicher Sprache vorkommende Sonderzeichen dürfen nicht als Steuerzeichen verwendet werden. Insbesondere Anführungs- und Leerzeichen nicht. Trotzdem müssen die Steuerzeichen absolut eindeutig sein, um Syntaxfehler zu vermeiden.
XML verwendet " < > & als Steuerzeichen und ist in der Hinsicht schlechter als TSF.

[Matti]

In deinem Beispiel ist ein namenloser Key mit dem Datentyp "Person"? Ein namenloser Key? Wie greift man denn auf einen namenlosen Key zu?

Wozu gibt es überhaupt Datentypen? Gibt es eine Schema-Definition?

Wie funktionieren Listen/Arrays? Scheinbar ist der einzige Unterschied zwischen Object/Struktur und Array ein "=" in der selben Zeile + Umbruch? Verwirrend. Das könnte ich früher oder später wahrscheinlich nicht mehr auseinanderhalten.

Zeilenumbrüche nur als "|"... und schon geht die Lesbarkeit flöten, weil es keine Absätze mehr geben kann.

Es gibt in TSF keine spezielle Syntax für Listen, sondern es gibt nur das Prinzip, dass Objekte Children haben können. Also kann man Listen als Objekt mit namenlosen Children betrachten. Und zugreifen kann man darauf, indem man über die Elemente eines Knotens (oder des virtuellen Root-Knotens) iteriert.

Datentypen sind nötig, wenn man TSF zur Serialisierung beliebiger Daten verwenden will. Wenn man C++ Daten serialisiert, würde man da eben den C++ Datentyp reinschreiben.

TSF ist keine Text-Markup-Sprache. Ich will nicht HTML ersetzen, sondern XML in den Fällen ablösen, wo es als Datencontainer benutzt wird. Insofern ist es imo kein Problem, wenn Zeilenumbrüche escaped werden.

[Monger]

LOL, das meinst Du doch wohl nicht ernst ?! Kann eine xls Datei etwa nicht auch noch komprimiert werden z.B. zippen?

Ist aber auch gar nicht nötig, es gibt schliesslich auch noch das xlsb Format d.h. xls aber von Excel schon komprimiert. Beispieldatei von mir:

xls: 1272 kb
xlsm: 354 kb
xlsb: 286 kb
xls als zip: 250 kb

Beispiel von einer Excel Datei die ich grad auf Arbeit hier rumliegen habe. Einmal "Speichern unter" eben als xls und dann als xlsx.

xls: 508kb
xls zipped: 434kb
xlsx: 219kb
xlsx zipped: 189kb

xlsx ist bereits ein Zip Container, daher ist es sinnlos das nochmal zu zippen. Ich hab das hier nur der Anschauung halber gemacht.

Kommt natürlich auf den Inhalt an. Die hier ließ sich jetzt relativ schlecht komprimieren.

In meinem alten Projekt hatten wir zehntausende an Excel Dateien rumliegen - das ging in die Gigabyte hinein. Wir sind eigentlich nur auf xlsx umgestiegen weil wir OpenXML nutzen wollten, aber anschließend waren die Dateien durchschnittlich noch ein Drittel so groß.

Zip ist halt selber bis zum Umfallen auf die Kompression von Klartext optimiert. Ganz allgemein sind Kompressionsalgorithmen für Inhalte die semantisch erfassbar sind sehr gut erforscht. Da Binärformate für den Kompressionsalgorithmus in aller Regel nicht oder schlecht verständlich sind, tut der sich mit Optimierungen auch schwer.

tl;dr: Zip und wohlstrukturierter Klartext ist eine sehr wirkungsvolle Kombination.

[Argo Zero]

Ich kenne xml nur als Sitemap. Wo wird das denn noch gebraucht?

[Ectoplasma]

Ich kenne xml nur als Sitemap. Wo wird das denn noch gebraucht?

Die Frage war ein Witz oder?

[Gohan]

Die Frage war ein Witz oder?

Ich war auch schon versucht zu Antworten, habe es mir dann aber verkniffen, da zu offensichtlich :biggrin:

[HajottV]

Ich kenne xml nur als Sitemap. Wo wird das denn noch gebraucht?

http://i3.kym-cdn.com/photos/images/original/000/207/234/you-must-be-new-here-willy-wonka.jpg

[Ganon]

Und wieder, wie bei allen "XML Alternativen", fehlt die Validierung xD

Ja, XML ist etwas bloatig und wurde längere Zeit etwas "zu oft" verwendet, an Stellen wo es nicht unbedingt nötig war. Aber durch JSON hat sich das eh schon wieder relativiert.

Aber gerade wenn man mit mehreren Firmen zusammenarbeitet und man eine gemeinsame Schnittstelle zwischen den Anwendungen aufbauen will, dann ist XML ein Segen. Man schreibt einfach eine vernünftige XSD auf beiden Seiten und gut ist. Macht der eine Mist, dann fliegt dem das schon beim Erzeugen um die Ohren...

Und wenn du dann kein XML in einer Anwendung verarbeiten willst, klemmst du noch ein XSLT dran und machst dein Lieblingsformat draus. Kann man, muss man aber nicht. Ist schon etwas eklig, aber wenigstens vorhanden. Optionen zu haben schadet ja nicht.

[ShadowXX]

Es gibt in TSF keine spezielle Syntax für Listen, sondern es gibt nur das Prinzip, dass Objekte Children haben können. Also kann man Listen als Objekt mit namenlosen Children betrachten. Und zugreifen kann man darauf, indem man über die Elemente eines Knotens (oder des virtuellen Root-Knotens) iteriert.

Datentypen sind nötig, wenn man TSF zur Serialisierung beliebiger Daten verwenden will. Wenn man C++ Daten serialisiert, würde man da eben den C++ Datentyp reinschreiben.

TSF ist keine Text-Markup-Sprache. Ich will nicht HTML ersetzen, sondern XML in den Fällen ablösen, wo es als Datencontainer benutzt wird. Insofern ist es imo kein Problem, wenn Zeilenumbrüche escaped werden.
Ehrlich gesagt habe ich eher das Gefühl das du den Sinn und Zweck von XML nicht wirklich verstanden hast (ist völlig OK, ich hab auch länger gebraucht um das "Konzept" so weit zu verinnerlichen, das man sich nicht mehr fragt warum das ganze so Bloatartig ist und warum es für vieles verwendet wird....und ja, es wird oft zu oft benutzt).

Dazu kommt das XML rausschreiben/einlesen unter C#/Mono (und anderen höheren Sprachen) so simpel und einfach ist, dass du keinen finden wirst der extra was benutzt was nicht "Standard" ist.
Und selbst unter C++ ist das rausschreiben/einlesen von XML inzwischen nicht mehr soooooooo kompliziert (selbst wenn man nur Boardmittel nutzt).

Ein Denkfehler den du begehst ist IMHO das du meinst das das ganze von Menschen lesbar sein soll....das ist nicht die Intention von XML, höchstens ein (gerne) mitgenommener Nebeneffekt.

[Capt'N Coax]

Ich bin nicht in der Webentwicklung tätig, aber ist nicht einer der Vorteile von Json, dass es valides JScript darstellt?

Das war vielleicht einer der Gründe für seine Verbreitung angesichts Web Punkt Version drölfzig (enter fancy Bezeichner hier).

[Matrix316]

Ich kenne xml nur als Sitemap. Wo wird das denn noch gebraucht?
Datenaustausch oder auch als Vorlage für Reports zum Beispiel.

[Gast]

Typisches NIH-Syndrom. Verstehe ich nicht, ich kanns besser als alle anderen.

[Argo Zero]

Datenaustausch oder auch als Vorlage für Reports zum Beispiel.

Dann exportiert bzw. importiert das entsprechende Programm und stellt die Daten anschaulich dar. Warum ist XML dann so böse?

[Gast]

Weiterer derzeit typischer Verwendungszweck: AJAX.Dann exportiert bzw. importiert das entsprechende Programm und stellt die Daten anschaulich dar.Wenn es überhaupt darzustellende Daten sind - ja.Warum ist XML dann so böse?Ist es nicht. Typische Kritikpunkte sind aber: Es ist einfach vielen zu "verbos" (durch die zwingende Schliessung der Elemente wird Text wiederholt), und nicht so hübsch mit den Klammern und dazu kommt die fehlende Festlegung, wann Attribute und wann Werte zu verwenden sind.

[No.3]

xls: 508kb
xls zipped: 434kb
xlsx: 219kb
xlsx zipped: 189kb

und was kommt bei xlsb raus?

Enthält die Tabelle viel Text oder viele Berechnungsformeln?

Kernstücke meiner Datei sind 80*160 Zellen die Daten aus einer anderen Excel-Datei holen und das eigentliche Herzstück ist ein 150*150 Zellen Berechnungsmonster d.h. insgesamt also wenig Text und hauptsächlich Excel-Formeln.

[Marscel]

Zum Topic: Nutz YAML, wenn dir JSON noch zu boilerplatig ist.

Ich kenne xml nur als Sitemap. Wo wird das denn noch gebraucht?

Jegliches moderne Office-Format, in der Finanzverwaltung und Controlling, vermutlich Apples halbe OS-Konfiguration, SOAP-Schnittstellen, jede XHTML-Seite, OpenStreetMaps, Feeds, SVG ...

[Ectoplasma]

Zum Topic: Nutz YAML, wenn dir JSON noch zu boilerplatig ist.



Jegliches moderne Office-Format, in der Finanzverwaltung und Controlling, vermutlich Apples halbe OS-Konfiguration, SOAP-Schnittstellen, jede XHTML-Seite, OpenStreetMaps, Feeds, SVG ...

Vergiss nicht, dass jeder Java Web Server und jeglich darauf laufende App, vollgestopft ist mit XML Konfigurationen. Java hat soweit ich weiss, den größten Marktanteil. XML wird man bestimmt nicht los.

[Gast]

Vergiss nicht, dass jeder Java Web Server und jeglich darauf laufende App, vollgestopft ist mit XML Konfigurationen. Java hat soweit ich weiss, den größten Marktanteil. XML wird man bestimmt nicht los.

Das kann man generell aber auch nicht mehr sagen. Bei JavaEE und selbst bei Spring braucht man fast keine XML Konfiguration mehr.

Application Server haben ihre Admin Console für Web/CLI

[Ectoplasma]

Bei JavaEE und selbst bei Spring braucht man fast keine XML Konfiguration mehr.

Das geht ja nur, wenn du dich strikt an Namenskonvention hältst und nur noch mit Annotations arbeitest. Das geht dann vielleicht bei neuen Projekten. Leider ist das bei alten Projekten nicht so und die haben oft eine lange, lange Lebenszeit.

[Gast]

Das geht ja nur, wenn du dich strikt an Namenskonvention hältst und nur noch mit Annotations arbeitest. Das geht dann vielleicht bei neuen Projekten. Leider ist das bei alten Projekten nicht so und die haben oft eine lange, lange Lebenszeit.

Was meinst du mit strikten Namenskonventionen?

[Ectoplasma]

Was meinst du mit strikten Namenskonventionen?

Als Beispiel fällt mir da z.B. die View-Auflösung mit Spring WEB Views ein. Eine explizite Benennung des Views im Controller ist nötig. Dennoch läuft das Mapping des View Namens zur JSP nach wie vor über eine XML Konfiguration.

Ein anderes Beispiel findet man bei Hibernate. Solange der Name einer Entity Klasse zu einem Tabellenname passt und die Namen der Getter-Methoden einer Entitiy Klasse ebenfalls zu den Spaltennamen eine Tabelle passen, dann braucht man weder Annotations noch eine XML Konfiguration. Naja im Minimum muss man so einer Klasse wenigstens die Annotation @Entity geben.

Trotzdem hat eine Hibernate und Spring Konfiguration immer irgendwo eine XML Konfigurationsdatei.

[Unfug]

Finde es gut, dass Du Dir Gedanken machst. Auch dein Ansatz ist eigentlich richtig.

Bei uns kommt im professionellen Bereich auch immer weniger XML zum Einsatz wegen deinen genannten Nachteilen. Aber auch weil die Smartphone Welt dafür nicht optimiert ist. Es ist so schön einfach alles über JSON Objekte hin und her zu senden. Jede Programmiersprache beherrscht das inzwischen (ein Serializer/Deserializer).

XML spielt eigentlich nur noch bei SOAP/SAML, Digitale Signaturen eine Rolle. Es gibt allerdings auch "Klassen" die so komplex sind, dessen Datenaustausch über JSON nicht menschenlesbar wären und man daher auf XML/XSD/Schemata/Schematron setzt, weil man Datentypen mit angeben kann.

Mich würde interessieren was Dir an JSON nicht gefällt?

[Gast]

Mich würde interessieren was Dir an JSON nicht gefällt?

Und warum YAML nicht passt?

[Exxtreme]

Typisches NIH-Syndrom. Verstehe ich nicht, ich kanns besser als alle anderen.
Naja, Xml ist IMHO tatsächlich eine Krankheit. Es funktioniert nur dann brauchbar wenn man das Ding ja nicht irgendwie per Hand editieren muss. Ich hatte auch schon öfter Fälle wo eine per Hand editierte Xml-Datei nicht mehr valide war obwohl sie optisch gestimmt hat. Wahrscheinlich irgendwo ein Leerzeichen zu viel oder so. Und ich würde so ein Projekt nicht starten, Json ist echt brauchbar. Vielleicht bissl geschwätziger aber wayne.

[Monger]

Bei uns kommt im professionellen Bereich auch immer weniger XML zum Einsatz wegen deinen genannten Nachteilen. Aber auch weil die Smartphone Welt dafür nicht optimiert ist. Es ist so schön einfach alles über JSON Objekte hin und her zu senden.

Das ist jetzt halt eine Eigenart von Javascript: eine so schwach typisierte Sprache profitiert halt nicht von einem stark typisierten Datencontainer. Und SOAP hat aufgrund mieser Implementierungen (mMn zu Unrecht) einen miesen Ruf.
Warten wir mal fünf Jahre ab, und schauen dann wie die Weblandschaft aussieht. Ich prophezeie, dass JSON nicht das Ende der Fahnenstange ist.



XML spielt eigentlich nur noch bei SOAP/SAML, Digitale Signaturen eine Rolle.

Kommt wohl wirklich sehr darauf an wo man hinschaut. In .NET ist XML ziemlich omnipräsent: in MSBuild, in MVVM Frameworks, als Container für Programm- und Benutzerkonfigurationen, als Zwischensprache für Resourcenassemblies, als Datencontainer für... naja, überall dort wo man keine schwergewichtige Datenbank braucht...

In Java sieht es meines Wissens ähnlich aus.

[PHuV]

Ich kann mich noch gut daran erinnern, als die ersten XML-Dateien, welche aus EDI-Nachrichten wie EDIfact, VDA, ANSI X12 und Co generiert wurden, mal aus einer kleinen Nachricht plötzlich 5 MB machten, und bei den ersten Java-Programmen die DOM-Struktur den Ram-Speicher zum Platzen brachte. :lol:

Das ist heute bedeutend besser geworden, nur die große Hoffnung von XML, alle anderen Übertragungsdaten als universelles Format abzulösen, hat sich absolut nicht erfüllt. Zum einen, weil es jede Datei enorm in der Größe aufbläht, zum anderen, weil zig XML-Dateien überhaupt nicht die W3C-Anforderungen erfüllen. Da sind so ganz triviale Dinge dabei, wie zum Beispiel einen korrekten Dateiheader mit dem Encoding oder einer korrekten BOM in der Datei. :rolleyes: Mir kommen bis heute XML-Dateien vor die Nase, die eine UTF-8-Enconding haben sollen, und dann sind Umlaute drin, oder ISO-8859-1(5), welche dann UFT-8-Zeichen drin haben. Und das teilweise von sehr renommierten Firmen und SW-Herstellern.

Von den ganzen Strukturproblemen und -varianten mal ganz zu schweigen. Was mich immer total genervt hatte, daß die meisten Leute und Entwickler, die Datenformate entwickeln, überhaupt nicht gepeilt haben, was XML genau ist. Und dann werden zig verschiedene veränderbare Parameter als Attribute definiert, die so eigentlich in Tags gehören. Das sieht man bei den ganzen Config-Dateien in den diversen Engines der Spiele. :facepalm:

Grauenvoll, sag ich da nur. Die Grundidee von XML war und ist an sich nicht schlecht. Nur das ganze Chaos, was es teilweise hervorgerufen hatte, weil die W3C-Definition anfangs sehr viele offene Fragen und Interpretationen zuließ, war extrem anstrengend. Es wurde ein Wildwuchs produziert, der bis heute leider nicht in Griff zu bekommen ist.

[samm]

Mir kommen bis heute XML-Dateien vor die Nase, die eine UTF-8-Enconding haben sollen, und dann sind Umlaute drinWas auch vollkommen in Ordnung ist :P

Den Rest des Postings kann ich unterschreiben. Hinzuzufügen wäre, dass es in vielen Kontexten sehr präsent ist und es keine (z.B.) JSON-Alternative im Angebot gibt - in meinem derzeitigen Arbeitsumfeld sind das Konfigurationsdateien, die ohne extra Bibliothek eingelesen werden können sollen, ISO 20022, XBRL, Ebics, serialisierte .net-Objekte, odt/docx, usw. Jedenfalls alles Gebiete, in denen ein Ersatz des Formates nicht ohne sehr grossen Einfluss auf sehr grosse Gremien/Firmen in Frage kommt.

[Gast]

war von anfang an auch nie ein besonderer fan von xml

allerdings ist es den alternativen durch die bessren verschachtelungsmöglichkeiten in kombination mit metadaten relativ überlegen, da man auf diese art und weise bedeutend mehr daten speichern kann und bedeutend mehr über diese daten aussagen kann.

für alles andere gibt es sql und datenbanken. die kann aber halt nicht jedermann bedienen wenn es mal notwendig ist, eine konfigurationsdatei hingegen schon. in bezug auf die reine datenspeicherung großer mengen kommt xml freilich irgendwo an grenzen, hat dafür aber vorteile bei layout und kompatiblität

[PHuV]

Was auch vollkommen in Ordnung ist :P
:| Ist es nach Standard nicht :nono:, da meckern einige Parser berechtigt rum. Oder anders formuliert, es sind in UTF-8 nur codierte Umlaute erlaubt.

Sprich

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
:
<Tag>Das ist ein Text mit ÄäÖöÜüß</Tag>

<?xml version="1.0" encoding="ISO-8859-15" standalone="yes"?>
:
<Tag>Das ist ein Text mit ÄäÖöÜüß</Tag>


ist tabu. Es muß nach Standard so lauten:
<?xml version="1.0" encoding="ISO-8859-15" standalone="yes"?>
:
<Tag>Das ist ein Text mit ÄäÖöÜüß</Tag>

oder

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
:
<Tag>Das ist ein Text mit ÄäÖöÜüß</Tag>

Sonst hast Du das schicke Problem, womit ich mich permanent bei Kunden rumschlagen muß, wenn der DB-Client dann falsch codiert und die Zeichen dann entsprechen falsch in der Datenbank landen. Und ich muß den Kunden wieder mal erklären, was ein Zeichensatz ist, und welche Standards es gibt.

[nalye]

[x] This!

UTF-8 ist bei vielen Dingen grauenhaft implementiert. Bei uns in der Firma wurde neulich von SOAP auf REST umgestellt und da kamen Dinge zum Vorschein... Mit JSON geht'S ja noch so halbwegs, aber die Standards von UTF-8 und XML sind irgendwie, nun ja, weit gefasst ind der großen Welt?

[Ganon]

Mit JSON geht'S ja noch so halbwegs

JSON hat gar keine Metadaten. Dort hat man in dem Fall immer verloren. Du kannst das Encoding nur extra erfragen, es steht nicht in den Daten selbst. Das mag in den meisten Anwendungsfällen von JSON nicht tragisch sein, ist aber bei manuellem Datenaustausch, wie er bei XML oft geschieht, relativ kritisch.

Aber Encoding-Probleme werden uns noch eine ganze Weile begleiten, unabhängig vom Dateiformat. Solange die ganzen Betriebssysteme alle ihre eigenen Süppchen und Erweiterungen kochen...

Und dann noch das Standard-Verhalten von Java... setzt man das Dateiformat nicht, schreibt er unter Windows win1252 raus, unter Linux das was im Locale steht (meist UTF8) und unter OS X MacRoman... dito MySQL mit seinem "UTF8 ist zu langsam, wir machen da was halbes"

[RattuS]

Von den ganzen Strukturproblemen und -varianten mal ganz zu schweigen. Was mich immer total genervt hatte, daß die meisten Leute und Entwickler, die Datenformate entwickeln, überhaupt nicht gepeilt haben, was XML genau ist. Und dann werden zig verschiedene veränderbare Parameter als Attribute definiert, die so eigentlich in Tags gehören. Das sieht man bei den ganzen Config-Dateien in den diversen Engines der Spiele. :facepalm:
Das klingt eher danach, dass du den Zweck von XML nicht gepeilt hast. Es gibt keinerlei Vorgaben vom W3C, welche (semantischen) Strukturen einzuhalten sind. Das Markup darf so flexibel verwendet werden, wie die individuellen Ziele es erfordern. Das ist die große Stärke von XML.

[RattuS]

Du kannst das Encoding nur extra erfragen, es steht nicht in den Daten selbst. Das mag in den meisten Anwendungsfällen von JSON nicht tragisch sein, ist aber bei manuellem Datenaustausch, wie er bei XML oft geschieht, relativ kritisch.
Das Standard-Encoding bei JSON ist UTF-8 per Spezifikation. Wenn das Encoding abweicht (UTF-16 oder UTF-32), muss das auch so übertragen werden im Header. JSON ist eben für die Kommunikation via Transport (z.B. HTTP) gedacht, nicht als persistenter Daten-Container wie XML.

[Marscel]

JSON hat gar keine Metadaten. Dort hat man in dem Fall immer verloren. Du kannst das Encoding nur extra erfragen, es steht nicht in den Daten selbst. Das mag in den meisten Anwendungsfällen von JSON nicht tragisch sein, ist aber bei manuellem Datenaustausch, wie er bei XML oft geschieht, relativ kritisch.

Naja, fail-safe approach ist dabei, alles jenseits des ASCII-Subsets als "\uABCD" innerhalb eines Strings zu codieren.

Aber Encoding-Probleme werden uns noch eine ganze Weile begleiten, unabhängig vom Dateiformat. Solange die ganzen Betriebssysteme alle ihre eigenen Süppchen und Erweiterungen kochen...

Ja. Milliardenmarkt Encoding-Issues.

[Coda]

XML ist zwar eher meh, aber es war zuerst da und es funktioniert gut genug. Ich sehe da keine große Notwendigkeit noch mehr Standards zu erfinden.

Was aber wirklich verbrannt gehört ist die DOM-API. WTF. Aber die muss man zum Glück ja nicht benutzen.

Und wenn du dann kein XML in einer Anwendung verarbeiten willst, klemmst du noch ein XSLT dran und machst dein Lieblingsformat draus. Kann man, muss man aber nicht. Ist schon etwas eklig, aber wenigstens vorhanden. Optionen zu haben schadet ja nicht.
Man kann sich auch die Glöten an einem Kaktus reiben.

[Matti]

JSON ist zwar wesentlich besser zu lesen als XML, aber es ist mit den ganzen Klammern und Anführungszeichen umständlich zu schreiben und auch langsamer zu parsen als TSF. Außerdem kann man in JSON keine beliebigen Typ-Informationen unterbringen, was mit TSF möglich ist.

YAML hat die Nachteile, dass es auch hier keine Typ-Informationen gibt und sehr viele Steuerzeichen escaped werden müssen. Außerdem ist das Handling von Leerzeichen problematisch: Leerzeichen in der Mitte des Wertes können direkt geschrieben werden, aber Leerzeichen am Anfang des Wertes müssen escaped werden.

[RattuS]

Außerdem kann man in JSON keine beliebigen Typ-Informationen unterbringen...
Gängige Praxis ist da z.B. ein Wrapper bei der Serialisierung:

{
"year": 2015,
"month": 3,
"day": 22,

"-type": "date"
}

[PHuV]

Das klingt eher danach, dass du den Zweck von XML nicht gepeilt hast.
Wenn Du das so sagst... :rolleyes:
Es gibt keinerlei Vorgaben vom W3C, welche (semantischen) Strukturen einzuhalten sind. Das Markup darf so flexibel verwendet werden, wie die individuellen Ziele es erfordern. Das ist die große Stärke von XML.
Das ist keine Stärke, sondern die Schwäche. Oder erklär mit doch mal bitte, was an einer Struktur wie
<Gruppe>Wert1
<Tag>Wert</Tag>
</Gruppe>

<Gruppe>
<Tag>Wert</Tag>Wert1
</Gruppe>

sinnvoll sein soll? Ganz zu schweigen, daß dann jeder Parser anders darauf reagiert, und teilweise abenteuerliche Konstrukte rauskommen. Das ist ja noch schlimmer als zu den Anfangszeiten von EDIfact und Co. Das führt dann dazu, daß Du XML-Dateien für diverse Anwendungen umbauen mußt. Und das war ja an sich nicht so gedacht. Ziel war zu den Anfangzeiten, alle anderen Nicht-Lesbaren Nachrichtenformate überflüssig zu machen. Das geht nur, wenn Du Interpretationsspielräume ausschließt oder vermeidest.

[RattuS]

Ziel war zu den Anfangzeiten, alle anderen Nicht-Lesbaren Nachrichtenformate überflüssig zu machen. Das geht nur, wenn Du Interpretationsspielräume ausschließt oder vermeidest.
Und genau für diesen Zweck gibt es DTD und XSD. Keiner muss, jeder kann.

Das führt dann dazu, daß Du XML-Dateien für diverse Anwendungen umbauen mußt.
Und was musst du da denn umbauen? Wo liegt denn dein Problem bei dem aufgeführten Beispiel? XPath?

[Watson007]

der Titel des Threads ist ein wenig lächerlich, ich wüsste nicht wann mich xml-Dateien bei der Bearbeitung schonmal gestört hätten... außerdem nehmen Profis ohnehin XML-Editoren

[PHuV]

Und genau für diesen Zweck gibt es DTD und XSD. Keiner muss, jeder kann.
Mag ja sein, aber DTD und XSD machen die Sache noch komplexer und komplizierter.
Und was musst du da denn umbauen? Wo liegt denn dein Problem bei dem aufgeführten Beispiel? XPath?

Wie unterscheidest Du dann, welcher Wert was ist, wenn der da so mittendrin auftaucht? Oder als was er genau interpretiert wird?

[RattuS]

Wie unterscheidest Du dann, welcher Wert was ist, wenn der da so mittendrin auftaucht? Oder als was er genau interpretiert wird?
Es wird so behandelt, wie XML es zulässt und so interpretiert, wie der Datenlieferant es vorsieht.

Dein Beispiel:
<Gruppe>
Wert1
<Tag>Wert</Tag>
Wert2
</Gruppe>
wäre [Gruppe] mit dem Inhalt "Wert1Wert2" und [Gruppe/Tag] mit dem Inhalt "Wert".

Wenn der Datenlieferant aber beabsichtigt, dass du unter Gruppe die Inhalte "Wert1", "Wert" und "Wert2" separat ausliest, dann gibt es hier schon ein rein technisch bedingtes Problem, das du gar nicht zu lösen hast, weil XML per Spezifikation so nicht funktioniert.

Dein Beispiel war sicherlich exemplarisch, weil ich mir eine derartige Ausgabe maschinengeneriert kaum vorstellen kann. Andernfalls gebe ich dir Recht und würde den Datenlieferant auf diese Diskrepanz hinweisen.

[Ectoplasma]

... außerdem nehmen Profis ohnehin XML-Editoren

Nö, nehmen sie nicht. Es sei denn du willst abartiger Weise, ein Excel-XML Woorkbook direkt bearbeiten. Aber das macht man dann sowieso mit POI.

[Ectoplasma]

Wie unterscheidest Du dann, welcher Wert was ist, wenn der da so mittendrin auftaucht? Oder als was er genau interpretiert wird?

Mal was anderes. Wieviel von solch mißglückten XML-Formaten, sind dir denn bisher untergekommen? Ich denke hier wird aus eine Mücke wieder ein Elefant gemacht.

[Marscel]

Mal was anderes. Wieviel von solch mißglückten XML-Formaten, sind dir denn bisher untergekommen? Ich denke hier wird aus eine Mücke wieder ein Elefant gemacht.

Mal ohne Witz: Ich hab hier ein kumuliert 65kB großes Ruby-Script, das zu 95% Edge-Case-Handling enthält, damit wir die knapp 2GB großen XML-Pakete einer Bundesinstitution einigermaßen vernünftig handeln können. Da ist so unglaublich viel Müll drin. Syntaktisch ist schon ca. 1% kaputt, semantisch ist es eine absolute Vollkatastrophe, ähnlich wie das Beispiel von PHuV. DTD zur Hölle.

Natürlich spricht das nun nicht für/gegen XML, nur eben als Beispiel für kaputtes XML.

[Ectoplasma]

Ich hab hier ein kumuliert 65kB großes Ruby-Script, das zu 95% Edge-Case-Handling enthält, damit wir die knapp 2GB großen XML-Pakete einer Bundesinstitution einigermaßen vernünftig handeln können. Da ist so unglaublich viel Müll drin. Syntaktisch ist schon ca. 1% kaputt, semantisch ist es eine absolute Vollkatastrophe, ähnlich wie das Beispiel von PHuV. DTD zur Hölle.

Natürlich spricht das nun nicht für/gegen XML, nur eben als Beispiel für kaputtes XML.

Du meine Fresse. Ok, ich habe mit soetwas zum Glück noch nicht gearbeitet. Aber ähm, was zur Hölle ... 2GB? Ist das von Hand geschrieben? Wer kommt auf so bescheuerte Ideen? Nicht zufällig SAP? :D. Mit einem ordentlichen Format, spielt die Größe ja keine Rolle. Sagen wir mal so, da hätte man in der Tat mit einer DTD arbeiten müssen. XML kann da eigentlich, wie du schon sagtest, nichts dafür.

[Gast_samm]

:| Ist es nach Standard nicht :nono:, da meckern einige Parser berechtigt rum. Oder anders formuliert, es sind in UTF-8 nur codierte Umlaute erlaubt.Dann sag doch, dass die fehlende Encodierung das Problem ist, statt die Verwednung von Umlauten an sich ;) Darauf sollte mein Kommentar hinweisen.

Übrigens müsste mal wohl die entsprechenden Characters hier im Forum auch innerhalb der [ code]-Tags escapen:
http://abload.de/thumb/mlus9utw.png (http://abload.de/image.php?img=mlus9utw.png)

[Gast]

Du meine Fresse. Ok, ich habe mit soetwas zum Glück noch nicht gearbeitet. Aber ähm, was zur Hölle ... 2GB? Ist das von Hand geschrieben? Wer kommt auf so bescheuerte Ideen? Nicht zufällig SAP? :D. Mit einem ordentlichen Format, spielt die Größe ja keine Rolle. Sagen wir mal so, da hätte man in der Tat mit einer DTD arbeiten müssen. XML kann da eigentlich, wie du schon sagtest, nichts dafür.

Keiner schreibt so große XML Dateien von Hand.

Zum Beispiel das VLB Sortiment wird im ONIX Format zur Verfügung gestellt.
Für den Initialimport von etwa 1,2 Millionen Produkten gab es 13-15 XML Dateien mit einer Gesamtgröße um die 13 GB. Gepackt als zip war es deutlich kleiner, ich glaube nicht mehr als 2 GB.

[PHuV]

Dein Beispiel war sicherlich exemplarisch, weil ich mir eine derartige Ausgabe maschinengeneriert kaum vorstellen kann. Andernfalls gebe ich dir Recht und würde den Datenlieferant auf diese Diskrepanz hinweisen.
Nein, genau so kommt es leider sehr oft in der Praxis vor, das ist kein Witz. Ich habe mir leider nicht jedes Beispiel gemerkt, sorry. Wenn ich wieder mal eines habe, poste ich es gerne mal hier. ;)
Mal was anderes. Wieviel von solch mißglückten XML-Formaten, sind dir denn bisher untergekommen? Ich denke hier wird aus eine Mücke wieder ein Elefant gemacht.
Sehr viele, und kämpfe immer wieder mit den Kunden oder SW-Häuser, die so was verbrechen. Gerade in Behörden, wo teilweise Leute sitzen, die eigentlich Verwaltungsmenschen sind, dann von den Vorgesetzten auf "Java"-Kurse geschickt werden, die dann wirklich allen ernstes Programme entwickeln. :facepalm: Nein, das ist nicht "Vorsicht Kamera", sondern traurige Realität. Entsprechend sehen dann auch Datenbeschreibungen und Programme auch aus.
Natürlich spricht das nun nicht für/gegen XML, nur eben als Beispiel für kaputtes XML.
Und vor allen gegen nicht durchdachte Datenstrukturen. Viele haben ja den Irrglauben, daß mit XML alles so einfach sei, und sich die Datenstruktur von selbst ergeben würde. Nein, liebe Leute, man muß hier genau so mitdenken :rolleyes: (hier Anwesende sind natürlich von dieser Rüge ausgeschlossen ;) ).
Keiner schreibt so große XML Dateien von Hand.

Zum Beispiel das VLB Sortiment wird im ONIX Format zur Verfügung gestellt.
Für den Initialimport von etwa 1,2 Millionen Produkten gab es 13-15 XML Dateien mit einer Gesamtgröße um die 13 GB. Gepackt als zip war es deutlich kleiner, ich glaube nicht mehr als 2 GB.
Genau das hat IMHO auch XML als universelles Datenformat das Genick gebrochen. Es gibt ja so abartige Strukturen, wo noch komplette Namespaces mit riesigen URLs aufgeführt werden. Das kann kann kein Mensch mehr lesen. Lustigerweise haben die meisten Parser das Problem, daß man nicht mal (obwohl in der Spezifikation so möglich) unterschiedliche Namespaces verwenden darf, ohne das der Parser abbricht. :facepalm: Ganz zu schweigen, daß die zu übertragenden Dateien einfach riesig werden.

Deshalb ist heute mein Vorgehen, daß für kleine Konfigurationsdateien und kleine Nachrichten XML eine sinnvolle Sache ist, weil hier die Parameter dann auch selbsterklärend sind. Blöde sind dann alle Werte, die veränderbar sind, aber als Attribute deklariert werden, das sollte IMHO immer ein TAG sein, und alles was als fixer und fester Wert verarbeitet werden soll, kann ein Attribut sein. Sobald die Datenmenge größer wird, sollte man CSV und Co. oder so etwas wie EDIFACT, IDOC, usw. verwenden.

Das es jemals ein allglücklichmachendes Format geben wird, genau so wie die universelle Sprache oder Datenbank, soweit sind wir uns hier bestimmt einig, das werden wir wohl alle nicht mehr erleben. Es gibt einfach zu unterschiedliche Anforderungen, die nur mit unterschiedlichen Mitteln optimal gelöst werden können.

[Coda]

Gegen beschissene Datenstrukturen wird auch ein anderes menschenlesbares Datenformat nicht helfen.

Schönes Beispiel was ich jetzt öfters gesehen habe ist, dass man Bitfelder als Zahl in ein Attribut packt anstatt die einzelnen Bits separat als boolean Attribut. Das ist natürlich dann null lesbar.

[Matrix316]

Du meine Fresse. Ok, ich habe mit soetwas zum Glück noch nicht gearbeitet. Aber ähm, was zur Hölle ... 2GB? Ist das von Hand geschrieben? Wer kommt auf so bescheuerte Ideen? Nicht zufällig SAP? :D. Mit einem ordentlichen Format, spielt die Größe ja keine Rolle. Sagen wir mal so, da hätte man in der Tat mit einer DTD arbeiten müssen. XML kann da eigentlich, wie du schon sagtest, nichts dafür.
Och das geht ganz einfach, weil du DataSets mit vielen DataTables ganz leicht als XML speichern kannst:

https://msdn.microsoft.com/en-us/library/ms233698.aspx

[Ectoplasma]

Keiner schreibt so große XML Dateien von Hand.

Ich meinte die Struktur, nicht die Menge der Daten.

@Matrix, ich präzisiere noch einmal. Wie schafft man es, eine XML-Datei zu bauen, die strukturell total verkorkst ist und die man dann mit so großen Datenmengen befüttert? Das war eher meine Frage. Mich interessiert nicht, wie eine XML-Datei so groß sein kann. Dass das geht und wie das geht, weiss ich selbst. Meine Frage bezog sich auf den Beitrag von Marscel.

[Matrix316]

Man kann ja solche Dateien auch einfach programmatisch erstellen. Da reicht schon ein kleiner Fehler und dann sieht das so aus.

[Ectoplasma]

Man kann ja solche Dateien auch einfach programmatisch erstellen. Da reicht schon ein kleiner Fehler und dann sieht das so aus.

Ja richtig. Bei mir schwingt leider im Hinterkopf immer mit, dass ich noch an den normalen Menschenverstand glaube. Man sollte doch meinen, dass einem solche Fehler relativ früh auffallen und diese dann behebt, bevor man mit so einem Dreck loszieht. Das was Marscel beschrieb, klang ja fast schon nach Sabotage. So bescheurt kann doch keiner sein, denkt man da. Wie dem auch sei, ich sehe in dem Fall nicht bei XML die Schuld, sondern eher den Verantwortlichen und den Entwicklern.

[RLZ]

Es gibt ja schon existierende Alternativen, die dann auch etwas mehr Semantik bieten.

@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<#Person>
<foaf:firstName> "Anton";
<foaf:lastName> "Anders";
<foaf:birthday> "1950-03-23T13:40:22.489+00:00"^^xsd:dateTime;
<#citizenship> "German"^^en;

aka Turtle / Notation3

[PHuV]

Ja richtig. Bei mir schwingt leider im Hinterkopf immer mit, dass ich noch an den normalen Menschenverstand glaube.
Echt jetzt? :eek: Du bist doch auch schon lange im Business, da weißt Du doch, daß so was anscheinend nur in homöopathischen Dosen bei Kunden verbreitet ist. :lol:

[Gast]

Ich meinte die Struktur, nicht die Menge der Daten.

@Matrix, ich präzisiere noch einmal. Wie schafft man es, eine XML-Datei zu bauen, die strukturell total verkorkst ist und die man dann mit so großen Datenmengen befüttert?

Indem man Daten automatisiert exportiert? Jedes vernünftige DBMS kann schon seit 10 Jahren XML zurückliefern. Wenn man dann irgend eine Alt-Datenbank mit schlechten Datenbank Design hat, dann kommt halt standardmäßig Grütze raus, wenn der Entwickler nicht noch Arbeit in die Transformation steckt.

[Marscel]

Ich meinte die Struktur, nicht die Menge der Daten.

@Matrix, ich präzisiere noch einmal. Wie schafft man es, eine XML-Datei zu bauen, die strukturell total verkorkst ist und die man dann mit so großen Datenmengen befüttert? Das war eher meine Frage. Mich interessiert nicht, wie eine XML-Datei so groß sein kann. Dass das geht und wie das geht, weiss ich selbst. Meine Frage bezog sich auf den Beitrag von Marscel.

Wie ich das beurteilen kann, sind die Daten a) z.T. Dekaden alt und irgendwann, vermutlich händisch, digitalisiert worden, und b) werden diese ständig Diff-like angepasst.

Und nein, bei dem Durcheinander habe ich starke Zweifel, dass die XML Resultat einer Ausgabe sind, sondern eher die Quelle.

[Ectoplasma]

Echt jetzt? :eek: Du bist doch auch schon lange im Business, da weißt Du doch, daß so was anscheinend nur in homöopathischen Dosen bei Kunden verbreitet ist. :lol:

Ja, ich weiss es ja auch eigentlich, aber ich habe da so meinen "Schaden". Ich glaube immer an das Gute im Menschen :D

[Nasenbaer]

Zum Thema passt der hier gut:

http://imgs.xkcd.com/comics/standards.png

Statt TSF hättest du dir eher einen XML-Viewer/-Editor bauen können, bzw. ein Plugin für deine Lieblings-IDE, damit du das "bloatige" ausblenden kannst.
Ist sinnvoller als ein neues Format zu ersinnen, das niemand außer dir nutzen wird und kennt. Genau dann ist es mit der Lesbarkeit wieder dahin, außer für dich. ^^