nicht angemeldet
Hi Philipp,
Ich musste mal einen SOAP-Dienst (Simple Object Access Protocol)
programmieren, d. h. SOAP für ein Intranet und somit die Kommunikation
zwischen firmeninternen Diensten. Hab aber, frech wie ich bin,
kurzerhand XML durch ein (besseres ;) ) Format ersetzt.
Nach welchen Kriterien "besser"?
Einen solchen SOAP-Dienst kann man nämlich viel einfacher umsetzen.
Etwa so wie das HTTP-Protokoll aufgebaut ist (das wurde ja noch nicht
XML-ifiziert).
Was haben Protokoll und Syntax der darin verwendeten Anweisungen
miteinander zu tun?
HTTP ist m. E. vor allem eine semantische Definition, erst in zweiter
Linie eine syntaktische.
Ich frage mich einfach: WARUM XML??? - Das verschlingt doch nur unmengen
von Serverperformance und die Netzwerkaktivität nahm ebenfalls um etwa
40% zu, als ich das ganze mal mit XML versuchte (XML-Dateien sind eben
etwas grösser).
Ich denke, Du vermischst da mehrere Aspekte, die ich in unterschiedlichen
Ebenen ansiedeln würde - so wie beispielsweise Content-encoding eine Schale
um HTTP herum legt, um das 'platzverschwendende' Klartextformat HTML band-
breitenschonend zum HTTP-Client zu transportieren.
Ich frage mich warum? - Nur dem Standard willen?
XML erlaubt es, in standardisierter Weise Formate zu definieren.
Diese Idee ist uralt - denk mal an die Backus-Naur-Form für formale
Syntaxen, an reguläre Ausdrücke oder auch an Edifact.
XML geht aber viel weiter:
- Es outsourced wesentliche Aspekte wie etwa die Visualisierung der Daten
in einer ebenfalls standardisierten Weise. - Es bietet fertige APIs für die Analyse solcher Dokumente.
Was glaubt Du, wie viele Dateiformat-Parser ich schon geschrieben habe?
Es vergeht kein Monat, in dem ich nicht wieder irgend ein neues, obskures
Format vorgesetzt bekomme, das irgend jemand erfunden hat, der von XML
nichts weiß. Ohne Perl und seine regulären Ausdrücke wäre es entsetzlich.
Klar, XML-parsing-Software ist heute noch ziemlich langsam - die Last,
welche das Forum auf das Self-Portal bringt, zeigt das deutlich.
Aber für die Analyse einer 100-Zeilen-Datei nehme ich das gerne in Kauf,
wenn ich dafür nicht zum allerzweiundvierzigsten Male ein ähnliches und
doch in entscheidenden Aspekten wieder abweichendes Skript schreiben muß.
Klar, im Falle eines outsourcings, d. h. wenn der Dienst über Internet
erreichbar sein soll, verstehe ich den Vorteil von XML
Darum geht es mir gar nicht. Ich würde nicht in erster Linie meine CGI-
Skripte zur Generierung von HTML-Seiten ablösen. Ich würde mich gerne
mehr auf die Analyse der Semantik konzentrieren als auf die Analyse der
Syntax.
Und wellformedness sicherzustellen wäre doch auch mal ein echter Fort-
schritt für unzählige Formate, für die bislang niemand einen Validator
geschrieben hat, weil es "den Aufwand nicht lohnte".
(Ich muß heute schon wieder genau so etwas bauen, weil jemand drei se-
mantisch zusammengehörige Informationsklassen in drei unterschiedlich
formatierten Dateien abgelegt hat und in deren Kommentarzeilen! erwähnt,
daß er sich darauf verläßt, daß diese drei Dateien inhaltlich zusammen
passen - geprüft wird das bisher nirgendwo, aber ich muß jetzt die Ober-
menge dieser drei Dateien in ein relationales Datenbankschema übernehmen.)
aber in einem Intranet, wo man die Standards selber festlegt?
Ich weiss nicht.
Deine Anwendung _mag_ ein Sonderfall sein. Aber wie sicher kannst Du Dir
sein, daß Du es nicht eines Tages irgendwo anders brauchst?
Vor allem: Wenn Du mal fit bist im Erstellen von DTDs usw., dann wird es
beim zehnten Format dieser Art schneller gehen als beim ersten.
Was haltet ihr von dieser XML-ifizierung?
Man kann alles übertreiben. Aber die Idee ist so richtig, wie sie alt ist.
In Deinem Fall mag Deine Lösung tatsächlich die bessere sein ...
Also ich bin ein Freund der "alten Schule".
Ich habe auch noch kein XML selbst verwendet - aber ich wäre froh, wenn
ich _nichts_ anderes mehr zu verarbeiten hätte als XML. Leider ist die
reale Welt nicht so ... noch nicht ...
Viele Grüße
Michael