nicht angemeldet
Halihallo Michael
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"?
Mit "besser" meinte ich: Angepasst an die Aufgabenstellung und platzsparend (Netzwerk soll nicht gleich ausgelastet sein).
In der Aufgabenstellung beschrieben war auch das Performanceproblem. Da hab ich schon mal gute Karten mit dem eigenen Format.
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.
Ja, ich meinte die einfache, "lineare" Struktur.
Set-Cookie: ...
Server: ...
das ist ja eigentlich nichts anderes als ein assoziatives Array (oder Hash). Genau das brachte ich eben für meinen SOAP-Dienst.
Mir ist klar (das habe ich auch im Posting zu Stefans Post geschrieben), dass XML Sinn macht, wenn das Datenset nicht mehr so einfach ist.
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.
Kannst du diese Analogie etwas anders formulieren? - Ich habe die Aussage nicht mitbekommen. Was willst du mir damit sagen? - Content-Encoding steigert die Bandbreite. Was sprichst du von bandbreitenschonend?
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.
Das ist auch lobenswert! - Die Idee gefällt mir auch, nur sehe ich nicht's göttliches hinter XML ;)
- 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.
;)
Ja, da hast du recht.
b.t.w : Mein Mitgefühl ;)
Ich habe das Glück, dass ich eben der bin, welcher eigene Formate definiert, mit denen du dich dann beschäftigen darfst ;)
Aber keine Sorge: Bei mir geht's _immer_ ohne reguläre Ausdrücke!
Klar, XML-parsing-Software ist heute noch ziemlich langsam - die Last,
welche das Forum auf das Self-Portal bringt, zeigt das deutlich.
Ich mag mich an die Diskussion erinnern, ja.
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ß.
Ja und nein. Aber ich stimme dir eher zu ;)
Es entsteht schon eine gewisse Redundanz, wenn man eigene Formate entwirft. Redundanz in dem Sinne, dass man das selbe immer wieder auf eine andere Weise implementiert.
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.
Das ist eine neue Sichtweise für mich. Aus dieser Perspektive habe ich noch nie überlegt.
[...Analyse der Semantik...]
Wie gesagt, ist dies für mich eine neue Perspektive des Problems. Bisher hat sich mir nie das Problem gestellt, dass eine Datei nicht meiner Semantik entsprach, da dafür genaue Definitionen vorlagen. Deshalb machte auch ein Validator keinen Sinn.
Man muss sich eben an die Vorgaben halten, dann ist ja alles OK, nicht?
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.
Nun, wie mir scheint, fehlt mir einfach die Praxis. Ich denke, dass sich meine Meinung zu XML ziemlich grundlegend ändern könnte, wenn ich diese Technik endlich verstehen würde. Ich muss mich einfach mal dahinter setzen und mir diese Parser vornehmen. Ich meine, das grobe (Grundidee und alles Grundlegende) an XML habe ich ja verstanden, nur an der Umsetzung habe ich noch Schwierigkeiten.
Viele Grüsse
Philipp
PS: Danke für die neue "Perspektive"/Sichtweise