Markup-meta-languages - Nothing but nonsense?

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

Gast++

Das Problem mit "Technologien" wie XML ist dass sie nicht nur eingesetzt sondern auch aktiv verkauft werden:

- XML/XHTML haben auch mit dem Web zu tun; das heißt von Haus aus "Hype Gefahr"

- Unter Java gibt es 'zig Java-XML-Standards; also können Firmen (IBM), die EJB-Lösungen herstellen diese XML-Fähigkeit zum Marketing nutzen.
Und sei es nur um mal wieder eine Botschaft zu haben und sich in Erinnerung zu bringen.

- Entscheidungen für/und gegen Technologien werden nicht (immer) nach sachlichen Kriterien getroffen; bei Großprojekten läuft es z.B. oft so dass der Reihe nach Consulting-Firmen mit dem Vertreterköfferchen in der Hand vorstellig werden und dem Köfferchen dann ein Powerpoint mit sinpelstem XML steckt; das versteht dann auch der Entscheider und fühlt sich bestätigt.
Der nächste travelling Salesman erzählt was von SQL und der Entscheider versteht "Bahnhof" und fühlt sich inkompetent.
Letztlich wählt er die Lösung bei der er sich besser fühlt.

- XML ist sogar sexy; siehe die Werbestrategie von XML-Spy http://www.altova.com/

- Wenn Dinge verkauft werden müssen ist es hilfreich wenn sie Konnotationen erlauben und das erlaubt XML:

"XML ist ein Datenformat" (fast richtig) => "Mit XML kann man Datenbanken erstellen" (richtig aber unangemessen) => "Es braucht XML-RDBMS" (bestenfalls hier unentscheidbar; zumindest falsch gefolgert)

"XML lässt sich mit DOM verarbeitet" (fast richtig) und "DOM beinhaltet das Wort 'Objekt' " (richtig) => "XML und OO passen gut zusammen"(falsch gefolgert; aber für den Entwicklungsprozess sogar durchaus gültig)

Dagegen zu argumentieren erweist sich als sehr undankbare Aufgabe; statt ein Schlagwort zu verwenden ("XML") und dies positiv zu besetzen ("macht erfolgreich und somit sexy") muss man mit Zahlen und abstrakten Strukturen argumentieren.

Als ich Anfang der Dekade von "XML-Datenbanken" las befürchtete ich schon dass solch ein Unsinn aufkommen würde.
10 GB als String zu kodieren und zu parsen erinnert mich an die Bemühungen einiger "Office-Programmierer" Datenbanken mit Excel zu implementieren weil dies das einzige war was sie kannten.

Aber erklärt das mal Entscheidern die Excel so einsetzen!

Grüsse

*this

pale dog

Gast++ schrieb:

- Wenn Dinge verkauft werden müssen ist es hilfreich wenn sie Konnotationen erlauben und das erlaubt XML:

ja, das stimmt.
es gibt vieles, das eine grosse beliebtheit geniesst, nur weil es gut vermarktet wird. aber eigentlich ist es ziemlich suboptimal.
XML ist dafür das beste beispiel.