Für XML gibt es nicht einmal eine RFC aber die ganze Welt empfiehlt diesen Unfug
XML ist Nicht die Präsentation der Daten sondern die Verpackung!
Lasst mich diese traurige Kapitel der Geschichte des WWW mit einem Zitat beginnen:
Was um Himmels Willen haben Heerscharen an Programmierern an diesen zwei Sätzen von Niklaus Wirth nicht verstanden!? XML ist möglicherweise für einen Menschen verständlich aber für eine Maschine ist dieser Content-Type alles Andere als einfach zu parsen. Mit XML wird versucht, den wahlfreien Zugriff auf Dateiebene abzubilden und dass dies Unfug ist, hat Niklaus Wirth bereits in den 80er Jahren festgestellt.
XML zu erzeugen, nun da gehen die Meinungen auseinander. Ich selbst empfehle ein Template und daran wird schon deutlich, dass dieses Vorgehen eine sequentielle Erzeugung ausschließt. Immerhin jedoch, ermöglicht ein Template die Trennung der Datenhaltung im Hauptspeicher (Array, Hash, Scalar) sowie der Programmlogik von der Art und Weise des Datentransport (Content-Type).
Andere Vorgehensweisen beschreiben die Erzeugung von XML direkt aus dem Programmcode heraus. Damit ist der Programmcode an den auszugebenden Content-Type fest gebunden und aus diesem Grund ist das auch nicht gerade empfehlenswert.
Zweifelsohne jedoch, ermöglichen XML-Dateien schließlich einen Transport der Daten außerhalb von Programmen: Via HTTP, FTP, SCP, Socket usw. Propagiert weil es sich mit XML angeblich ein universelles Datenaustauschformat handeln soll. Das ist natürlich kompletter Blödsinn, weil es wesentlich einfachere Verfahren gibt, Daten (binary safe) zu serialisieren und im Hauptspeicher verschiedenster Programmiersprachen wiederherzustellen.
Sicher zeigen Boundaries oder andere Token in Dateien visuell, dass hier irgendwas voneinander getrennt oder anderweitig strukturiert wurde. In Dateien vom Content-Type: application/json ist sogar die für's Programm beabsichtigte Datenstruktur zu erkennen. Indes: Maschinen lesen Dateien völlig anders als unsereiner. Tatsächlich ist es so, dass Dateien, die mit textlichen Mitteln strukturiert sind, für Maschinen einen sehr hohen Aufwand erfordern. Und abgesehen davon muss dafür gesorgt sein, dass Token, welche der Strukturierung dienen, nicht selbst in den Nutzdaten vorkommen dürfen.
Aus den zuletzt genannten Gründen ist XML für den Transport von Binärdaten ungeeignet. Als ich einen Parser für multipart/form-data entwickelte, ist mir mal wieder mehr als einmal klargeworden, dass einzig eine Content-Length-Angabe für jeden einzelnen Part das ganze Boundary-Gedöns überflüssig machen würde. Mehr noch: Die Wiederherstellung der Einzelteile, Parameter und hochgeladene Dateien, würde ein ganzes Stück weit performanter sein, weil die Datei blockweise und nicht byteweise gelesen werden kann. Eben so, weil Content-Length die Länge eines Blocks beschreiben würde.
Eigentlich gehört multipart/form-data genauso wie application/xml oder application/json auf den Schrotthaufen der Internet-Geschichte. Aber wie liest denn nun eine Maschine Dateien und wie könnte ein Enwickler das unterstützen? Die Antwort ist ganz einfach: Verständnis für die Maschine zeigen. Sequentiell lesen heißt zum Beispiel:
- lese 4 Byte zum Ermitteln der Längenangabe,
- lese soviele Bytes wie in der Länge angegeben.
Und dann wiederholt sich das
Das wäre ein Algorithmus, den es einfacher kaum gibt. Es kommt nun ganz darauf an, wie der Bauplan beschaffen ist, der beschriebt, wie die Einzelwerte gruppiert oder anderweitig zusammengestellt sein müssen, so dass Arrays, Hashes und andere komplexe Datenstrukturen daraus entstehen. So gelangen die Daten aus einer Datei/Bytesequenz wieder in den Hauptspeicher und stehen dort für den wahlfreien Zugriff zur Verfügung.
Der beschriebene Algorithmus ist extrem einfach auf jeder Plattform und in jeder Programmiersprache zu implementiern. Des Weiteren erfolgt die Übertragung der Daten im binary safe Modus. Reden wir nicht alle seit Jahren von Multimedia? Oder gar von Hypermedia-Dateien? Hier sind sie!
Datenschutzerklärung: Diese Seite dient rein privaten Zwecken. Auf den für diese Domäne installierten Seiten werden grundsätzlich keine personenbezogenen Daten erhoben. Das Loggen der Zugriffe mit Ihrer Remote Adresse erfolgt beim Provider soweit das technisch erforderlich ist. sos@rolfrost.de.