nicht angemeldet
Halihallo Stefan
Aber was heisst das? - Dass man ein Programm schreiben kann, welches ein XML Dokument einliest und dann weiss wie es den Inhalt darstellen muss, bzw. welchen Befehl es ausführen muss?
Wie XML-Daten bei der Ausgabe/Darstellung (wo eigentlich? Drucker? Bildschirm? Stimme im dunklen Raum? Voellig egal!) auszusehen haben, steht in den XML-Daten nicht drin - das ist ja der Trick.
Stimmt. Das war ja auch die Kritik. Da XML nur ein "Datenträger" ist und somit den Daten ein gewisses Format aufzwingt; hat es mir eben einen schlechten Eindruck hinterlassen, da man ja passende Formate einfach selber erstellen kann (die eben der Anwendung angepasst sind). XML alleine bringt mir einfach zu wenig.
Dazu gibt es Techniken wie XSL oder XSLT.
Deswegen auch das Beispiel mit dem Glossar. Glossare lassen sich ja perfekt mit XSLT erstellen; das ist genau die Stärke von XSLT.
schön und gut, aber ein Kunde muss trotzdem wissen, wie das Dokument aufgebaut ist.
Muss er das? Dann kann er ja einen schicken XML-Editor verwenden, wie X-MetaL oder so was. Und wenn er keine Angst vor spitzen Klammern hat, wird es auch Notepad tun.
Halt, ich glaube ich habe mich schlecht ausgedrückt:
Wenn ich z. B. einen SOAP-Service auf XML-basis programmiere, muss ich dem Kunden (trotz XML) eine Beschreibung des Datentyps liefern (oder ein IDL-Dokument, welches die Ein- und Ausgabe des Interfaces definiert), welcher über das XML-Interface versendet wird.
Meine Meinung:
Ob ich nun sage, dass Befehle zwischen <envelope> und </envelope> stehen und das Dokument-Tag <SOAP><REQUEST> und </REQUEST></SOAP> heisst. Oder ob ich sage: Einzelne Befehlsblöcke werden durch Leerzeilen getrennt und die Parameter werden so übergeben:
<name>=<wert>\n
spielt doch keine Rolle was man anwendet. Es gibt beides etwa den selben Arbeitsaufwand. Die zweite (meine) Methode, ist aber beim parsen schneller und das Dokument kleiner. Also fragte ich mich, warum XML? - Nur dem Standard zuliebe? - Nur den anderen zuliebe? - Oder hat es soviele Vorteile, dass ich es auch mir zuliebe machen kann?
Bisher sehe ich nur den Vorteil, dass sich jeder (Kunde sowie Serviceprovider) derselben Module (XML-Parser Module) bedienen kann und somit keine Zeit verschwenden muss, um selbst einen passenden Parser für meine Formate zu schreiben.
Also kann man doch gleich eine eigene Definition bringen.
soll dann der gezwungen werden, sich mit deinem INI-Format rumzuschlagen?
Ja, das ist in der Tat eine positive Kritik, welche ich mir merken werde. Aber bisher ist das der einzige Nachteil.
Viel einfacher ist es dann, wenn er eine XML-DTD hat, wo steht, wie die Daten aufgebaut sind. Da braucht er dann nur noch einen XML-Parser zum Einlesen, den ja jede moderne Programmiersprache als Modul zur Verfuegung stellt, und schwupps, schon hat er die Daten, und zwar nicht nur eingelesen, sondern auch inhaltlich strukturiert.
Wenn der Inhalt strukturiert sein soll, macht XML natürlich Sinn, denn jeder Versuch ein eigenes Format zu basteln, was diesen Anforderungen entspricht, wird wohl etwa gleich enden wie XML. XML ist einfach, logisch und strukturiert. Braucht man diese Kriterien soll man sich gleich XML bedienen. Aber für eine einfache Schnittstelle taugt ein "lineares Format", dieses muss nicht inhaltlich strukturiert sein.
Ich frage mich: "Ist der XML-boom gerechtfertigt? - Ist XML wirklich das Ende aller kommunikativen Probleme???" - Ich sage, dass XML überbewertet wird! - Meine Meinung, man möge mich dafür lünchen.
Naja, die falsche Euphorie, die mit solchen Sachen seit jeher verbunden wird, verfliegt halt irgendwann wieder. Was dann bleibt, ist ein Standard, der sicher viele Probleme loesen wird - wenn auch nicht alle. Aber dafuer wurde er wohl auch nicht gemacht ;-)
Ja, da wirst du recht haben. In den meisten Artikeln, welche ich zu diesem Thema gelesen habe, wird XML einfach als "Gott der Datenkommunikation" dargestellt. Das mag auch stimmen, aber solange ich lebe haben wir Polytheismus!
Viele Grüsse
Philipp