Markup-meta-languages - Nothing but nonsense?
-
Ist dir irgendwie langweilig?
-
finix schrieb:
Ist dir irgendwie langweilig?
Ich weiß nicht was die Frage nach dem Sinn eines Verfahrens, mit dem man involviert ist, mit Langeweile zu tun hat?
-
S.Till schrieb:
finix schrieb:
Ist dir irgendwie langweilig?
Ich weiß nicht was die Frage nach dem Sinn eines Verfahrens, mit dem man involviert ist, mit Langeweile zu tun hat?
Nun ja, man könnte z.B. vermuten, fälschlicherweise sicherlich, dass ein Unreg mal wieder einen pro/kontra/vs_x-XML-Flame anzetteln will; insbesondere wenn du nur ein paar schwammige Behauptungen in den Raum stellst, ohne diese irgendwie zu Begründen.
-
finix schrieb:
Nun ja, man könnte z.B. vermuten, fälschlicherweise sicherlich, dass ein Unreg mal wieder einen pro/kontra/vs_x-XML-Flame anzetteln will; insbesondere wenn du nur ein paar schwammige Behauptungen in den Raum stellst, ohne diese irgendwie zu Begründen.
Sorry, ich war mir nicht bewußt dass diese Thema hier schon mal diskutiert wurde.
Allerdings konnte ich eine Diskussion über meine Frage hier bis jetzt nicht finden.Ich wollte hier nichts behaupten, sondern nur meine Auffassung in den Raum stellen, die ich ja wenn möglich gerne wiederlegt haben möchte, da ich es durchaus für möglich halte, den Nutzen von XML & Co übersehen zu haben.
Vielleicht hat ja jemand ein praktisches Beispiel parat, wo z.B. mit XML effizienter eine Problemlösung ermöglicht wird, als mit einer dokumentierten Binärschnittstelle.
Danke!
-
S.Till schrieb:
Vielleicht hat ja jemand ein praktisches Beispiel parat, wo z.B. mit XML effizienter eine Problemlösung ermöglicht wird, als mit einer dokumentierten Binärschnittstelle.
Erweiterbarkeit ohne bestehenden Code zu brechen!?
-
Die Grundfrage ist sicherlich berechtigt, z.B. wenn man sich den Overhead bei WebServices durch WSDL/XML anschaut, kann einem schon Angst und Bange werden.
In einer idealen Welt bräuchte man das nicht, da würde man das mit schlanken RPCs machen.
Aber offensichtlich hat das nicht so toll funktioniert, anders kann man sich kaum erklären, warum auf einmal die Vernetzung heterogener Plattformen möglich ist - ohne WebServices haben es die Leute nicht hinbekommen. Routing, die Datenformate, Big Endian, Wortbreiten - offensichtlich waren diese Hürden in der Summe zu hoch, da es nun überhaupt kein Thema mehr ist die gleiche Vernetzung mit WebServices zu realisieren.
-
Jochen Kalmbach schrieb:
Erweiterbarkeit ohne bestehenden Code zu brechen!?
Was meinst du damit zum Beispiel?
-
Marc++us schrieb:
Routing, die Datenformate, Big Endian, Wortbreiten
Was meinst du mit "Routing"?
Der Rest ist ein reines Dokumentationsproblem, und da hat XML auch nur "Werkzeuge" mitgeliefert, die es ohne dem auch gibt.
-
als gut erweiterbares schlankes format könnte man hier ebml aufführen, das z.B. für matroska videocontainer genutzt wird
-
r0nny schrieb:
als gut erweiterbares schlankes format könnte man hier ebml aufführen, das z.B. für matroska videocontainer genutzt wird
Naja, mir geht es um den Sinn aller (erweiterbaren) Auszeichnungssprachen.
-
S.Till schrieb:
Letztendlich ist dies eine Frage nach dem Sinn von Auszeichnungs-Objektsprachen.
Welch einen Vorteil bringt es, mit den Daten selbst die Semantik der Daten zu beschreiben, anstatt Kommunikation direkt zu führen, indem man Semantik und Daten getrennt betrachtet?
Und warum sollten Daten mit Text strukturiert werden (was meines Erachtens nichts weiter als ein Faulheitsmotivator gegen Editoren und vollständige Dokumentation ist)?Einerseits gibt es Bereiche, wo man kein festes Protokoll ala "bytes 1-5 entsprechen X und bytes 6-11 entsprechen Y" einführen kann. Zum Beispiel stammt XML aus dem Bereich der einfachen Text-Markierungen. Daher gibt es auch Dinge wie Attribute, da man Metainformationen eben getrennt vom Fließtext ablegen musste. Auszeichnungs-Sprachen werden mittlerweile auch in anderen Bereichen eingesetzt. Einmal weil bereits eine Infrastruktur existiert, andererseits weil man so die Formate flexibler gestallten kann. So kann man ein Text-Format eben leichter erweitern, als ein binäres Format. Außerdem bieten Text-Formate portablere Möglichkeiten Daten zu transportieren und sie lassen sich eben mit einfachen und vereinheitlichen Werkzeugen bearbeiten. Wie Marc++us schon gesagt hat stößt man bei binär Formaten schnell an Probleme. Das fängt ja bei alignment und Endianess an und endet dann bei ganz anderen Darstellungen von Zahlen. Aus dem Grund sind viele Netzwerk/Internet-Application-Protokolle im Textformat.
Und im Grunde baut man in Protokollen doch auch immer wieder Auszeichnungen ein, nur eben nicht vereinheitlicht und man muss sich zusätzlich jedes mal noch mit dem Format auseinandersetzen und hat keine einheitlichen Tools (zB zur Validierung) und muss sich die teilweise sogar selbst schreiben.
Es gibt ja auch binäre Formate für Auszeichnungssprachen, ala ebxml und ASN.1
Alternativen zu XML wären zB TDL, OGDL oder YAML.
-
S.Till schrieb:
Jochen Kalmbach schrieb:
Erweiterbarkeit ohne bestehenden Code zu brechen!?
Was meinst du damit zum Beispiel?
Ein Editor kann Metadaten in die Datei reinpacken. So packt zum Beispiel Inkscape eine Reihe von eigenen Tags, die auch als solche gekennzeichnet sind, in SVG Dateien rein damit die Einstellungen des Editors nicht verloren gehen. (Man kann diese Tags aber auch strippen wenn alles fertig ist.)
Bei einem binär Format wäre es nicht so einfach möglich mal eben Metadaten reinzupacken, falls dies nicht von Anfang an geplant war, und man müsste diese in eine separate Datei packen oder ein neues Format erstellen welches nur der Editor benutzt und am Ende konvertiert wird.
Ein anderes Beispiel wären verschiedene Versionen von Formaten. Bei binär Formaten kommt man oft selbst bei sehr einfachen Erweiterungen wie dem hinzufügen einer Spalte in einer Tabelle nicht um drum herum einen Konverter zu schreiben. Bei XML fügt man einfach ein paar optionale Tags hinzu und definiert einen Defaultwert und alte Dateien bleiben lesbar.
PS: Auch wenn mein Post anders klingen mag, bin ich kein großer Freund von XML.
-
S.Till schrieb:
Jochen Kalmbach schrieb:
Erweiterbarkeit ohne bestehenden Code zu brechen!?
Was meinst du damit zum Beispiel?
Alt:
<Node attr="value" />Neu:
<Node attr="Value" attr2="Value" />Alle bestehenden Applikationen können noch mit dem XML-String wunderbar leben. Bei einer Binär-Schnittstelle wäre hier schon der Tod angesagt. Du müsstest sofort alle Seiten ändern!
bei XML kannst Du beliebig erweitern. Neue Client können dann z.B. sowohl mit den neuen XML-Daten arbeiten als auch mit älteren.Der Aufwand ist immer nur auf einer Seite, ohne dass es gleich einen ganzen Rattenschwanz nach sich zieht...
So können wir z.B: bei uns Schnittstellen erweitern und können unsere Software bei bestehenden Kunden updaten, ohne dass dort auch die Fremdsoftwaren upgedatet werden müssen. Somit müssen wir nur einen Softwarestand "pflegen" und nicht bei jedem Kunden nachschauen, was der für "Randbedingungen" hat, sondern können ihm einfach immer die neueste Version geben...
(wir haben natürlich trotzdem ein Release-Management).
-
Der große Unterschied ist doch nicht, ob es binär oder Text ist. Der Text wird am Schluss auch binär dargestellt und man muss angeben wie (UTF-8 UTF-16...). Das bewirk ja nur, dass es vom Mensch einfacher gelesen werden kann. Der Unterschied ist, dass man zu den Daten auch die Struktur Informationen rein packt und das macht es einfach erweiterbar.
-
S.Till schrieb:
Marc++us schrieb:
Routing, die Datenformate, Big Endian, Wortbreiten
Was meinst du mit "Routing"?
Routing - RPC ist im Netzwerk nicht schön routbar, WebServices sind es aber schon.
S.Till schrieb:
Der Rest ist ein reines Dokumentationsproblem, und da hat XML auch nur "Werkzeuge" mitgeliefert, die es ohne dem auch gibt.
Offensichtlich war es kein reines Dokumentationsproblem, da es ja nicht so umfangreich verwendet wurde. Außerdem nützt mir die Dokumentation nur bedingt, wenn ich zum Beispiel Fließkommazahlenformate an ein System im Format IECDingenskirchen liefern muß, aber mein System das nicht unterstützt. Oder Big Endian/Little Endian-Umcodierung, außerordentlich nervig, da man das zusätzlich anpassen muß. Für jedes Pärchen aus Client/Server benötigt man in diesem Modell einen eigenen Interfaceadapter, während man bei WebServices für alle identische Interfaces einsetzen kann. Gleiches Timing, gleiches Protokoll, usw.
-
Es gab und gibt sicherlich einen XML-Hype wie es schon viele Hypes gab
- den OO-Hype "Schauen Sie mal! Hier haben ein Objekt vom Typ NT-OS dessen Methode Coredump uns gerade ein Objekt vom Typ Bluescreen geliefert hat! Mittels des Powerswitches rufe ich jetzt den Destruktor auf..."
- den Java-Hype "Programmierer braucht man nicht mehr. Anwender stecken ihre eigenen Business-Objekte zusammen und fertig!"
- den Internet-Hype "Heute kam at me e-Mail von e-Solutions at e-Commerze dot com. Die Fragen ob ich die e-Cash Lösung auch ohne e-Xtra e-Ntlohnung in e-Assembler schreiben könnte. Und ob's e-Assembler überhaupt gibt..."
Und genau solche Auswüchse finden sich auch beim Thema XML. Genau wie die obigen Zoten nichts über die Qualität der Technologien/Methoden aussagen sagt die Existenz von inperformanten XML-Datenbanklösungen etwas über XML aus.
XML ist ein textbasiertes und offenes Format.
Deshalb ist es vielseitig einsetzbar aber teuer weil Strings parsed oder kopiert werden.Wenn man in einer Applikation an jeder Stelle von/nach XML en/decodiert wird die Anwendung langsam; setzt man es dort ein wo sowieso Parsing erforderlich ist (Config) oder von der RT nur geschrieben wird (Logging) ist's kostenneutral aber man gewinnt Interoperabilität.
Ferner bringt XML viel für den Entwicklungsprozess:
XMI hat soch als Standard für UML-Dateien durchgesetzt und aus Datenbanken lassen sich XML-Schemata generieren.
Ein gutes Beispiel für die Verwendung zur Entwicklungszeit ist Perl::SQL::Translator aka "SQLFairy" - trotz des scheusslichen Logos ein imo exzellentes Toolkit:
- Die Perl XML-Unterstützung ist die Grundlage
- Eine SQL-DDL Datei für z.B. MySQL wird in ein temporäres XML-Schema überführt
- Das XML-Schema kann dann zur DDL von z.B. MSSQL oder PostgreSQL trasformiert werdenWenn man dann noch beachtet dass z.B. DBDesigner 4 Modelle im XML-Format speichert sieht man welche Möglichkeiten sich durch ein gemeinsames (Meta-)Format für die Softwareentwicklung ergeben.
Es war Ende der 90er einfach an der Zeit für ein offenes Format und XML ist schon deshalb nicht die schlechteste Lösung weil es sehr einfach ist; der Umgang mit Bäumen ist doch sehr grundlegendes Handwerkszeug.
Grüsse
*this
-
Jochen Kalmbach schrieb:
Alt:
<Node attr="value" />Neu:
<Node attr="Value" attr2="Value" />das kriegste selbst damit hin: http://en.wikipedia.org/wiki/Type-length-value
auch representation von daten, so dass endianess usw. keine rolle spielen.
XML ist einfach nur fett, man kann damit locker den overhead verzehnfachen.
der einzige vorteil von XML ist, dass man es mit einem texteditor bearbeiten kann, sonst gibt es keinen.
-
Marc++us schrieb:
Offensichtlich war es kein reines Dokumentationsproblem, da es ja nicht so umfangreich verwendet wurde. Außerdem nützt mir die Dokumentation nur bedingt, wenn ich zum Beispiel Fließkommazahlenformate an ein System im Format IECDingenskirchen liefern muß, aber mein System das nicht unterstützt. Oder Big Endian/Little Endian-Umcodierung, außerordentlich nervig, da man das zusätzlich anpassen muß. Für jedes Pärchen aus Client/Server benötigt man in diesem Modell einen eigenen Interfaceadapter, während man bei WebServices für alle identische Interfaces einsetzen kann. Gleiches Timing, gleiches Protokoll, usw.
So ganz glaub ich dir da nicht. Es ist ja nicht außerordentlich schwer sich für Zahlen auf eine Kodierung zu einigen. Eine Reihe von Sprachen können das Kodieren auch automatisch übernehmen (big - little endian oder besser native - network brauchen verschiedene Typen) und so für den Programmier transparent und viel weniger fehleranfällig gestallten.
In der Tat müsste man sich erst einmal einigen und solche Schnittstellen schreiben. Allerdings wenn ich das mit dem ganzen Aufwand der hinter XML steckt und auf welches man sich ja auch erst einigen muss vergleiche sind das Peanuts.
-
XML baute auf bereits existierenden und etablierten Technologien auf...
-
pale dog schrieb:
Jochen Kalmbach schrieb:
Alt:
<Node attr="value" />Neu:
<Node attr="Value" attr2="Value" />das kriegste selbst damit hin: http://en.wikipedia.org/wiki/Type-length-value
auch representation von daten, so dass endianess usw. keine rolle spielen.
XML ist einfach nur fett, man kann damit locker den overhead verzehnfachen.
der einzige vorteil von XML ist, dass man es mit einem texteditor bearbeiten kann, sonst gibt es keinen.schwachsinn, vor allem weil man mal eben so 8 gigabyte xml im texteditor bearbeitet; und solche dateigrößen sind weder eine seltenheit in großer business software, noch ein problem.