XML ist die Lösung aller Probleme, wird vielfach geschrieben.
Ich mag XML, ich nutze XML, zum Beispiel für mein Profil, für Schnittstellen (WebServices), teilweise für INI-Dateien (Programmeinstellungen), …
Vor XML habe ich SGML genutzt, und finde die beiden deutlich besser wie die IDL von CORBA.
Der grosse Vorteil von XML ist die Möglichkeit, eine XML Anwendung in eine andere XML Anwendung zu Transformieren. XML selber ist ja nur ein kurzer Satz an Regeln, jedes Element beginnt mit einem Start-Tag <DiesesIstEinElement> und endet mit einem End-Tag </DiesesIstEinElement> und nur innerhalb eines Elements dürfen andere Elemente enthalten sein.
Über die DTD, XSD oder Relax wird der genaue Syntax der Anwendung, zum Beispiel der Aufbau einer Nachricht zum Handel mit Aktien, beschrieben.
XHTML ist eine XML Anwendung. HTML ist übrigens eine SGML Anwendung, deshalb sind zum Beispiel Dinge wie <p><b>Test</p></b> in HTML erlaubt, bei XML wäre die Regel der „well formed“ verletzt.
Um zum Beispiel aus der XML Anwendung, in dem ich mein Profil pflege und die ich mit DTD (es war im Jahr 1999, da gab es nur DTD) beschrieben haben, ein HTML Dokument oder ein FOP (der Input zu Apache FO, um dann ein PDF zu erzeugen), wird ein XLST genutzt.
Für die Umwandlung des XML, das ein WebService liefert, in das hausinterne XML Format, wird auch XLST genutzt. Ein solches XLST ist ein XML, das in etwa den Aufbau des Ziel XML hat, in zusätzlich XPath Ausdrücke enthält, um die Daten aus der Quell XML Anwendung einzufügen.
Bei einfachen Transformationen ist das XLST schnell zu erstellen.
In COBOL würde das gleiche mit
move CORR Input to Output
gemacht werden, wenn die Namen innerhalb von Input zu denen von Output passen und die Formate kompatible sind.
Bei komplexen Transformationen wird XLST schnell sehr unübersichtlich. Dann ist es besser ein Programm zu schreiben.
Aber wohl liegt nun der Vorteil von XML?
XML ist für einen Menschen, der über die entsprechende Ausbildung und Erfahrung verfügt, besser zu lesen wie ein Flatformat File.
Dafür ist das Flatformt File für einen Computer einfacher zu verstehen.
Und für einen erfahrenen Programmierer (nur diese verfügen in der Regel über die Ausbildung und Erfahrung, ein XML auf Fehler zu prüfen oder direkt zu editieren) und auch für Anwender gibt es Tools, um ein Flatformat lesbar darzustellen und zu editieren (zum Beispiel CompuWare FileAid auf IBM Mainframes).
Der eigentliche Grund für XML ist aber ein anderer: Die verschiedenen Zeichensätze, die bei Computern verwendet werden.
Unicode, also der 16 Bit Zeichensatz, mit dem alle Zeichen, die auf der Erde benötigt werden, eindeutig beschreibbar sind, ist eine recht junge Entwicklung.
Vor 30 Jahren wurde vielfach ein 7 Bit Zeichensatz verwendet, der ASCII Zeichensatz. Da er für die USA entwickelt wurde, fehlen dort die deutschen Umlaute, also gab es dann den DIN Zeichensatz, wo die 7 Bit Werte für die eckigen und geschweiften Klammern und einige andere Zeichen des ASCII Zeichensatzes für die Umlaute verwendet wurden. Mit dem DIN Zeichensatz kann man also nicht C oder Java programmieren.
Deshalb erweiterte IBM für den PC den Zeichensatz auf 8 Bit, die unter Hälfte entspricht dem ASCII Zeichensatz, die obere Hälfte beinhaltet u.a. die Umlaute. Neben IBM erfand auch Microsoft einen 8 Bit Zeichensatz für Windows (ANSI), die untere Hälfte ist wieder der ASCII Zeichensatz, die obere Hälfte enthält teilweise die gleichen Zeichen, aber in einer anderen Kodierung. Für die westeuropäischen Sprachen waren alle notwendigen Zeichen im IBM-PC und im ANSI-Zeichensatz enthalten, aber nicht für andere Sprachen. Also gibt es eine sehr große Anzahl an verschiedenen 8 Bit Zeichensätzen.
Auf dem Grossrechnern gibt es den EBDIC Zeichensatz. Der wichtigste Unterschied zu den PC Zeichensätzen ist die Sortierung.
Auf dem PC gilt Space < 0 < 9 < A < a,
bei EBDIC Space < A < a < 0 < 9.
Da die Grossrechner nicht nur in den USA und Westeuropa laufen, gibt es hier auch verschiedene Zeichensätze mit verschiedenen Sonderzeichen. Für Deutschland nutzte man früher meist EBDIC 273, mit Einführung des Euro-Zeichens den EBDIC 1141.
Bei XML sollte in der ersten Zeile ein Hinweis auf den verwendeten Zeichensatz stehen, damit weiss der Zielcomputer, ob und wenn ja welche Zeichensatz-Transformation benötigt wird.
Diese Information kann aber auch beim Transfer zwischen verschiedenen Rechnern mitgegeben werden, so etwas kennt jedes File-Transfer Programm und auch FTP.
In XML sind alle Werte als Zeichen kodiert, die Zahl „minus Siebenunddreizig“ steht als „-37“ im XML.
In Flatfiles kann „-37“ binär (als signd integer im Dualsystem „1000.0000.0010.0101“), BCD (jede Ziffer wird mit 4 Bit kodiert, das Vorzeichen ist das letzte Halbbyte, also in hexadezimal System „037C“) oder als Zahl aus 8 Bit Zeichen, wobei das Vorzeichen im oberen Halbbyte des letzten Bytes steht (im Hex-Darstellung auf dem Mainframe „F3D7“).
Wie soll nun ein Programm zur Zeichensatz-Umwandlung wissen, dass das Zeichen ab der 89. Stelle die Zahl „-37“ ist, und nicht ein Zeichen, das umzuwandeln ist?
Wenn in dem Flatformat nun keine binären Zahlen, sondern nur druckbare Zeichen gespeichert werden, ist die Gefahr gebannt. Wenn auf der COBOL Seite die Zahl als „PIC SZZ9 Sign is Leading Separator“ definiert wird und auf der anderen Rechnern auch mit druckbaren Zeichen für Zahlen gearbeitet wird, können die Systemprogramm zum Datentransfer einfach genutzt werden.
Ein XML
<kunde>
<nummer>4711<nummer>
<vormane>Hans</vorname>
<name>Testmann</name>
<telefon>
<lfdNr>1</lfdNr>
<telefonnummer>555-123-456</telefonnummer>
</telefon>
<telefon>
<lfdNr>2</lfdNr>
<telefonnummer>555-234-567</telefonnummer>
</telefon>
</kunde>
ist sehr gut lesbar, meist sieht das XML aber so aus:
<kunde><nummer>4711<nummer><vormane>Hans</vorname><name>Tstmann</name><telefon><lfdNr>1</lfdNr><telefonnummer>555-123-456</telefonnummer></telefon><telefon><lfdNr>2</lfdNr><telefonnummer>555-234-567</telefonnummer></telefon></kunde>
Der Inhalt kann auch als Flatformat: Satzart, Key, Satzdetail gespeichert werden,
kunde 004711Hans Testmann
telefon00471101555-123-456
telefon00471102555-234-567
Für einen Computer ist das Parsen dieses Formats wesentlich einfacher und verbraucht deutlich weniger Zeit.
Es ist übrigens ein Leichtes, in Java eine Daten-Klasse zu erstellen, die XML, Festformate, CSV und auch JSON (die Methode, mit der in JavaScript Daten beschrieben werden) lesen und schreiben kann.
Auch die Bereitstellung als JDBC ResultSet oder SQL Insert / Update / Delete / Select ist recht einfach machbar.
Ob man für die Beschreibung der Inhalte eher Meta-Klasse nutzt, oder aus einer UML oder sonstigen Beschreibung die Klasse generiert, ist den Umständen im Projekt geschuldet und keine strategische Entscheidung.