Ist XML überbewertet?
-
Vielleicht bin ich zu blöde für XML.
Vielleicht ist es aber auch nur der größte Hype seit langem.Wie denkt ihr darüber:
"If they [Developers] DO have sense, future applications will exchange their data in XML.
The future might give us word processors, spreadsheet applications and databases that can read each other's data in a pure text format, without any conversion utilities in between."
Schön und gut. Aber es gibt keine semantische Ebene.
Meine Textverarbeitung unter Windows verarbeitet die XML-Tags anders als die unter Linux. Wenn da ein <bold>-Tag auftaucht, wissen zwar alle Entwickler wie es zu verarbeiten ist. Aber es ist nirgends formal definiert.
Damit XML im Bezug auf den Datenaustausch wirklich sinnvoll ist, müsste es neben der Schema-Definition für die Syntax auch eine Beschreibungssprache für die Semantik geben. Natürlich nicht in jedem Fall. Aber das Beispiel des <bold>-Tags in einer Textverarbeitung heißt: "drucke fett", und sonst nichts. Das ist eine Übereinkunft aller Entwickler, die nirgends formal festgehalten wird: Hier fehlt eine Beschreibungsebene!Eine solche semantische Definition gewisser Tags würde aber dem XML-Gedanken einer Trennung von Daten und Darstellung widersprechen. Geht also auch nicht.
Tja, entweder habe ich den Gedanken hinter XML immer noch nicht verstanden, oder es resultiert alles einfach nur in aufgeblasenen Textdateien.
Anmerkung: Gewisse Vorteile sehe ich natürlich. Aber die sind alle rein syntaktischer Natur und beschleunigen etwa das Einlesen von Datein. Überzeugen tut mich das alles aber nicht so richtig.
-
XML-Lerner schrieb:
Ist XML überbewertet?
Ja.
Hier ein Beispiel eines Hypeopfers, das den Absprung geschafft hat. http://colinux.wikia.com/wiki/Configuration_XML_format
-
Ja und Nein.
XML ist eine von vielen moeglichen Wegen, Baumartig strukturierte Daten abzuspeichern. Da man sehr viele Arten von Daten baumartig darstellen kann, ist XML schon praktisch. Und es hat dabei auch noch nette Zusatzfeatures (wie z. B. Namespaces, Human Readability, ...). Klar kann man genau die gleichen Features auf viele andere Arten (oder zumindest anderer Syntax) implementieren, aber XML ist nunmal eines der am weitesten verbreiteten Arten, das zu tun.
XML ist aber nichts weiter als ein schlichtes (Meta)Datenformat. Sprich: du kannst damit ein Datenformat festlegen, mehr auch nicht. Damit Windows- und Linuxanwendungen XML-Tags gleich verarbeiten, muessen sich die Anwendungen auch mal auf ein eigenes XML-Schema einigen. Nur allein die Verwendung von XML ist kein Allheilsmittel, nur ein moegliches Werkzeug. (und wenn du Semantik auch noch haben willst, gaebs mit RDF immerhin schon was, das vllt. in die richtige Richtung geht).
Kurzum: XML hat seine Vor- und Nachteile. Mich stoerts nicht sonderlich wenn Programme ihre Daten in XML ablegen/austauschen, ist besser als in einem proprietaeren Binaerformat. Ausserdem glaub ich, dass der XML-"Hype" schon lang vorueber ist, du kommst also ein bisschen zu spaet. Heutzutage ist XML einfach eine Art, Daten abzuspeichern.
-
-
Blue-Tiger schrieb:
Klar kann man genau die gleichen Features auf viele andere Arten (oder zumindest anderer Syntax) implementieren, aber XML ist nunmal eines der am weitesten verbreiteten Arten, das zu tun.
Das ist das Problem von XML. Wenn ich einen Strom von menschenlesbaren Zeichen speichern will, dann nehme ich eine "text"- (im Gegensatz zu "binär"-) Datei. Der Unterschied ist marginal. Die Vorteile, die ich damit erhalte: es gibt eine Unmenge an Tools, die mit Textdateien umgehen können. Emacs, vi, grep ... etc.
Das liegt daran, dass die Textdatei ein offensichtlicher Kompromiss zwischen Benutzerfreundlichkeit und Vielseitigkeit ist.Für baumartige Strukturen gibt es einen solch offensichtlichen kompromiss nicht. (Naja, Verzeichnisse vielleicht. Die haben sich übrigens auch eingebürgert und es gibt eine Unmenge an Tools, die mit Verzeichnissen umgehen können. Emacs oder Windows explorer z.B.)
Aber XML hat sich einen halbwegs sicheren Platz freigehalten. Das zweite Problem von XML, das gleichzeitig ein Vorteil ist, dass XML eine Textdatei ist. D.h., ich kann eines der obengenannten Tools nehmen, und aus einem XML-File eine Textdatei machen, die fast so aussieht wie XML. Das ist unelegant. Besser wäre es, wenn XML nur mit XML-Editoren bearbeitbar wäre, die sowas nicht zulassen. Nein, halt, wäre es das? Natürlich nicht, weil binärformate stinken. Und man die vorhandene Infrastruktur zum Texteditieren nicht recyclen kann.XML ist übrigens größentechnisch schon sehr suboptimal. Gerade in Zeiten, in denen das Lesen von der Festplatte ein Bottleneck ist, hätte man sich das sparen können.
-
volkard schrieb:
Blue-Tiger schrieb:
Human Readability
Ist immer noch lesbarer als ein Binaerformat. Ich glaub nicht dass sowas mit einem anderen textbasierten Format wesentlich besser aussehen wuerde.
@TheCockatrice: abgesehen vom letzten Satz (den ich nich richtig finde, man kann das XML ja noch schnell durch gzip rennen lassen) verstehe ich nicht, was du sagen willst?
-
Blue-Tiger schrieb:
man kann das XML ja noch schnell durch gzip rennen lassen
Ja,das macht MS-Word. Mit dem Effekt, daß das Backup der 10000 Word-Dateien, die alle aus ganz wenigen Vorlagen entstammen, jetzt unpackbar sind. Vorher hatte der Packer über Dateigrenzen hinaus Gleichheiten gesehen und sagenhafte Kompressionsraten, jetzt müssen wie Hardware dazukaufen.
-
Der XML-Hype hat doch stark abgenommen. Vor ein paar Jahren war der ja wirklich unerträglich und jeder musste alles in irgend eine Form in XML verpacken. Die ganzen Buzzwordprädiger wollten alle mit einer "XML Konfigurationsdatei" aufwarten. XML an sich finde ich gar nicht so schlimm. Es hat eben seinen Zweck als Markupsprache und es existieren mehr oder minder brauchbare Technologien um XML. Es ist jedoch nicht sinnvoll als Datensprache und dafür wurde es eben immer missbraucht.
Für das speichern von Daten gibt es aber mittlerweile brauchbare etablierte alternative Formate, wie JSON.
-
Wenn man nicht gerade Bücher schreibt hat XML einen verdammt grottiges Protokoll/Nutzdaten-Verhältnis. Der einzige Grund es zu nutzen wäre für, daß bereits viele Tools dafür erhältlich sind, ich also Zeitsparen kann beim entwickeln.
-
Blue-Tiger schrieb:
@TheCockatrice: abgesehen vom letzten Satz (den ich nich richtig finde, man kann das XML ja noch schnell durch gzip rennen lassen) verstehe ich nicht, was du sagen willst?
tl;dr: Eigentlich wären wir mit einem Binärformat glücklicher. Wir würden zwar über den unleserlichen Schmarrn fluchen, hätten aber keine Probleme mit unpackbarkeit. Ein Binärformat hätte sich aber nie im Leben durchgesetzt, weil man es nicht mit Emacs bearbeiten kann.
-
TheCockatrice schrieb:
Eigentlich wären wir mit einem Binärformat glücklicher. Wir würden zwar über den unleserlichen Schmarrn fluchen, hätten aber keine Probleme mit unpackbarkeit.
das hier z.b: http://en.wikipedia.org/wiki/Type-length-value
aber ich denke, XML lässt sich sehr gut komprimieren, weil es ja unkomprimiert für sehr wenig informationen viele-viele bytes braucht.
-
Das Binärformat ist noch besser komprimierbar, weil von Anfang an weniger Daten da sind, die man komprimieren muss. Zwischen einem 16bit-Wort und "<value>5194</value>" liegen doch Welten.
-
Ja fricky, das gefällt mir auch entschieden besser.
Vielleicht sogar eine Norm, die die gesamte Datenstruktur vorne in der Datei ablegt, sodaß man später seeken kann für das was man braucht!
XML mag ich nicht. Ich mag es überhaupt nicht, wenn ich mich in halbgegessene Modeerscheinungen einarbeiten soll.
Da wird immer von der Wiederverwendbarkeit der OOP geredet - praktisch kommt man dazu aber überhaupt nicht, weil es ja direkt 'proprietär' ist, und 'Normen' grundsätzlich von anderen gemacht werden. Das verleidet einem so langsam alles!
-
Einen leichte Rückbesinnung zu Binärformaten scheint es ja zu geben, wenn man sich Bison oder BERT anschaut. Binärformate haben halt einen besonders schlechten Ruf, weil viel zu oft die Entwickler einfach
fwrite(&einestruct, ...);gemacht haben. An und für sich spricht nichts dagegen, warum diese nicht genauso flexibel wie Textformate sein sollen. Eben mit der einzigen Ausnahme, dass man die nicht mit einem Texteditor bearbeiten kann. Aber wie volkards Beispiel zeigt ist dies für viele Bereiche in denen XML eingesetzt wird ohnehin nicht bedeutsam.TheCockatrice schrieb:
Ein Binärformat hätte sich aber nie im Leben durchgesetzt, weil man es nicht mit Emacs bearbeiten kann.
Klar kann man das mit Emacs http://www.gnu.org/software/emacs/manual/html_node/emacs/Editing-Binary-Files.html
:p
-
Bitsy schrieb:
XML mag ich nicht. Ich mag es überhaupt nicht, wenn ich mich in halbgegessene Modeerscheinungen einarbeiten soll.
Da wird immer von der Wiederverwendbarkeit der OOP geredet - praktisch kommt man dazu aber überhaupt nicht, weil es ja direkt 'proprietär' ist, und 'Normen' grundsätzlich von anderen gemacht werden. Das verleidet einem so langsam alles!Was genau gefällt Dir denn nicht an XML? Klar, über die Syntax lässt sich streiten. Aber ansonsten isses doch super, dass es einen quasi Standard gibt, zu dem massig Tools existieren, so dass man sich ums Serialisieren, Deserialisieren und Parsen nicht mehr selbst kümmern muss.
Und was genau hat Wiederverwendbarkeit der OOP mit XML zu tun? Bist du angepisst, weil es mit XML + seinen Tools schon fertige Lösungen gibt und Du es daher nicht mehr selbst programmieren darfst?
So ist das heute nun mal. Man kann entweder jedes mal das Rad neu erfinden oder man benutzt die fertige Lösung von jemand anderem.
-
Gegenfrage: Was genau hat serialiseren mit XML zu tun?
Natürlich muß man nicht immer das Rad neu erfinden, aber 4-eckige Räder wie XML sollte man schon verbessern. Was mir nicht gefällt hab ich ja schon geschrieben. XMl ist wie Politik: viel Text, wenig Inhalt.
-
Tyrdal schrieb:
XMl ist wie Politik: viel Text, wenig Inhalt.
und was ist, wenn genau das gewünscht ist, man also eine für den Menschen les- und bearbeitbare Datei haben will?
Binärdateien sind platzsparender, das stimmt, aber dafür ist die Struktur fest vorgegeben, sei es durch Feldgrößen oder irgendwelche Stoppcodes. Wenn man selbst der einzige Nutzer der Datei ist aber nicht weiter schlimm
XML hat dann einen Vorteil wenn man eine Baumstruktur abbbilden will oder das Ergebnis an andere Programme weitergeben will bzw mit den Ergebnissen anderer Programme arbeiten muss. Da einigt man sich nur aufs Schema (das muss, das darf, das sollte drin sein) und der Rest ist egal.
Für alles sollte man XML auch nicht einsetzen. Für simple Konfigurationsdateien einer Anwendung ist ini immernoch besser geeignet. Und wer keinen Wert auf Lesbarkeit legt und dafür auf den Speicherplatz achten will, gibts immernoch Binärdateien
-
Tyrdal schrieb:
Gegenfrage: Was genau hat serialiseren mit XML zu tun?
Dachte eigentlich, das sollte klar sein, wenn man über XML diskutiert. So what, siehe:
- XML Data Binding
- SOAP
- Burlap
- usw.Natürlich muß man nicht immer das Rad neu erfinden, aber 4-eckige Räder wie XML sollte man schon verbessern. Was mir nicht gefällt hab ich ja schon geschrieben. XMl ist wie Politik: viel Text, wenig Inhalt.
Ich sagte ja schon, dass die Syntax nicht so glücklich ist. Aber das spielt für viele Anwendungsfälle keine gravierende Rolle. Und es gibt ja längst effizientere Alternativen, siehe JSON.
-
Nachdem Ihr meinen XML-Paste aus einer *.docx überlebt habt, hier der finale Schwachsinn:
http://pastebin.com/m132fba2f
-
Ist doch super. Das passt prima in ne HTTP Message und lässt sich somit problemlos durch die meisten Firewalls kommunizieren.
-
byto schrieb:
Ist doch super. Das passt prima in ne HTTP Message und lässt sich somit problemlos durch die meisten Firewalls kommunizieren.
Äh, HTTP ist egal was es transportiert. XML, Binärdaten, eigene Formate, offene Formate etc.