Markup-meta-languages - Nothing but nonsense?

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.

Gast++

pale dog schrieb:

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.

"(Allgemein) suboptimal" ist schwer zu beweisen...

Wo XML suboptimal ist könnte man z.B. entscheiden wenn man etwas das im gleichen Bereich eingesetzt wird mit XML vergleicht und des sich als besser geeignet herausstellt.

Bei RDBMS ist es offensichtlich dass XML Nachteile hat.

Aber zur Sicherstellung der Interoperabilität von (UML/ERM/...) Modellen (s. m. Beitrag auf S.2) und für Konfigurationslösungen ist mir noch nichts besseres untergekommen.

Grüsse

*this

Gast++

pale dog schrieb:

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

Bei Grossprojekten (darunter versteh ich >= 100 Use-Cases => >= 10 Mannjahre) z.B. in Banken kann man die Hardwarekosten und Lizenzkosten ggü. den Personalkosten und der ILV für die Entwicklung meist vernachlässigen.

Grüsse

*this

pale dog

Gast++ schrieb:

Bei Grossprojekten (darunter versteh ich >= 100 Use-Cases => >= 10 Mannjahre) z.B. in Banken kann man die Hardwarekosten und Lizenzkosten ggü. den Personalkosten und der ILV für die Entwicklung meist vernachlässigen.

naja, die coden ja meistens für grossrechenanlagen, die sowieso schon angeschafft sind, da kann das stimmen was du sagst.
ich komme aus einer anderen branche, in der wird meistens mit der software auch gleich die dazugehörige hardware verkauft und immer wenn man etwas in software machen kann, damit die hardware schlanker ausfällt, gibt's ein dickes plus in der kasse (je mehr geräte produziert werden)...

pale dog schrieb:

Gast++ schrieb:

Bei Grossprojekten (darunter versteh ich >= 100 Use-Cases => >= 10 Mannjahre) z.B. in Banken kann man die Hardwarekosten und Lizenzkosten ggü. den Personalkosten und der ILV für die Entwicklung meist vernachlässigen.

naja, die coden ja meistens für grossrechenanlagen, die sowieso schon angeschafft sind, da kann das stimmen was du sagst.
ich komme aus einer anderen branche, in der wird meistens mit der software auch gleich die dazugehörige hardware verkauft und immer wenn man etwas in software machen kann, damit die hardware schlanker ausfällt, gibt's ein dickes plus in der kasse (je mehr geräte produziert werden)...

dass der schreiner für den du sein buchhtaltungsprogramm schreibst keine gigabytes xml produziert ist klar, aber dann halte dich auch bitte mit äußerungen zurück, von deren materie du keine ahnung hast um damit die anfänger/fragesteller zu verwirren, danke