Markup-meta-languages - Nothing but nonsense?

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.

rüdiger

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.

Ben04

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.

Jochen Kalmbach

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.

Marc++us

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.

Gast++

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 werden

Wenn 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

pale dog

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.

Ben04

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.

minhen

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.

pale dog

net-vista-dog schrieb:

8 gigabyte xml ... und solche dateigrößen sind weder eine seltenheit in großer business software...

wundert dich das? XML macht's möglich

net-vista-dog schrieb:

...noch ein problem.

nein, natürlich nicht, 8GB sind niemals ein problem

danke dass du so konstruktiv auf meinen beitrag eingehst.
wenn xml dateien in gigabyte größe ein problem wären, würde sowas niht verwendet werden, schließlich geht es zum Beispiel bei den großbanken um jede menge geld. die haben anscheinend kein problem 10 gb xml sich gegenseitig zu zu schieben und zu parsen

pale dog

net-vista-dog schrieb:

die haben anscheinend kein problem 10 gb xml sich gegenseitig zu zu schieben und zu parsen

sagt ja keiner, dass es unmöglich ist, aber warum sollte jemand regelmässig 10GB XML (mit vielleicht 0.5GB informationsgehalt) durch die gegend schieben? wird das zeug wenigstens komprimiert?

pale dog schrieb:

warum sollte jemand regelmässig 10GB XML (mit vielleicht 0.5GB informationsgehalt) durch die gegend schieben?

weil es offensichtlicher billiger ist als 0.5gb binärdaten durch die gegend zu schicken

wird das zeug wenigstens komprimiert?

ja mit base64

pale dog

net-vista-dog schrieb:

pale dog schrieb:

warum sollte jemand regelmässig 10GB XML (mit vielleicht 0.5GB informationsgehalt) durch die gegend schieben?

weil es offensichtlicher billiger ist als 0.5gb binärdaten durch die gegend zu schicken

...und warum sollte das billiger sein sein? wegen mengenrabatt oder was?

net-vista-dog schrieb:

wird das zeug wenigstens komprimiert?

ja mit base64

base64 macht's ja noch grösser
ausserdem braucht man für reine textdaten kein base64, es sei denn, man möchte es für uneingeweihte unleserlich machen.
...aber ich merke schon, dass du voll den durchblick hast

OK Thread kann geschlossen werden.

pale dog schrieb:

net-vista-dog schrieb:

wird das zeug wenigstens komprimiert?

ja mit base64

base64 macht's ja noch grösser
ausserdem braucht man für reine textdaten kein base64, es sei denn, man möchte es für uneingeweihte unleserlich machen.
...aber ich merke schon, dass du voll den durchblick hast

schon mal was von eronie gehört?

pale dog schrieb:

net-vista-dog schrieb:

pale dog schrieb:

warum sollte jemand regelmässig 10GB XML (mit vielleicht 0.5GB informationsgehalt) durch die gegend schieben?

weil es offensichtlicher billiger ist als 0.5gb binärdaten durch die gegend zu schicken

...und warum sollte das billiger sein sein? wegen mengenrabatt oder was?

weil es weniger mannstunden kostet die passende software zu entwickeln und zu warten und zu modifizieren => weniger geld-kosten, kapicse?

net-vista-dog schrieb:

wird das zeug wenigstens komprimiert?

ja mit base64

base64 macht's ja noch grösser
ausserdem braucht man für reine textdaten kein base64, es sei denn, man möchte es für uneingeweihte unleserlich machen.
...aber ich merke schon, dass du voll den durchblick hast

vielleicht solltest du nicht so viel in internet foren rumhängen, dann hättest du auch genug soziale kompetenz etwas zu verstehen was ironie genannt wird *autsch*

pale dog

god elap schrieb:

...

hey, cooler name

net-vista-dog schrieb:

schon mal was von eronie gehört?

nö...

net-vista-dog schrieb:

pale dog schrieb:

net-vista-dog schrieb:

pale dog schrieb:

warum sollte jemand regelmässig 10GB XML (mit vielleicht 0.5GB informationsgehalt) durch die gegend schieben?

weil es offensichtlicher billiger ist als 0.5gb binärdaten durch die gegend zu schicken

...und warum sollte das billiger sein sein? wegen mengenrabatt oder was?

weil es weniger mannstunden kostet die passende software zu entwickeln und zu warten und zu modifizieren => weniger geld-kosten...

es gibt auch fertige, getestete und tausendfach bewährte implementationen von binärprotokollen. das ist kein ausreichendes argument.
ausserdem enstehen mehrkosten (bei der hardware) gerade durch unnötig ressourcenhungrige programme, d.h. pro gerät braucht man mehr speicher und leistungsstärkere CPUs, die mit der datenflut klar kommen.
software ist billiger als hardware