XML hat so keine Zukunft. Es geht unter.

Walli

Naja, ich finde XML zwar eine praktische Sache, aber wenn es um das Speichern von großen Datenmengen geht ist XML erstens langsamer und zweitens Speicheraufwendiger als bspw. ein binäres Format...

Marc++us

Kein Mensch käme auf die Idee, binäre Daten von Audio und Video in XML zu speichern. Tut das einer doch, so hat er nicht viel kapiert. Interessanter ist dann schon, die Header von Binärfiles wieder in XML abzulegen...

Prof84

Original erstellt von Marc++us:
Kein Mensch käme auf die Idee, binäre Daten von Audio und Video in XML zu speichern. Tut das einer doch, so hat er nicht viel kapiert. Interessanter ist dann schon, die Header von Binärfiles wieder in XML abzulegen...

Hi!

Soooo?!? - ...
Die Binärdaten werden in einen UTF-8 Format übersetzt. Das ist richtig.

Aber Standards und Spezifikationen, wie
VoiceXML
SALT (Speech Application Language Tags)
CCXML (call control XML)
SMIL (Synchronized Multimedia Integration Language)
und etwa weiter hundert übertragen transformierte Binär-Daten.

Nix für ungut!

P84

Marc++us

Ja, nur muß ich bei diesem Punkt Daniel E. zustimmen:

Nicht alles was möglich ist, ist auch sinnvoll.

Es kann nicht sein, daß sich die Forschung über Jahre den Kopf zerbricht wie man Audio- und Videodaten mit Hilfe von Fourier- oder Wavelet-Methoden zerkleinert, und nachher kommen einige fröhliche Jungs die es geil finden eine neue Spezifikation auch darauf anzuwenden und plötzlich ist die Filegröße einen Faktor 2 (da landet man ja mindestens) größer. Wer das macht, hat den Schlag nicht gehört.

Vor allem weil es für Audio- und Videodaten auch hardwarebasierte Algorithmen gibt, die in Chips bzw. speziellen ASICs abgelegt sind - die können mit einem XML-Stream nicht so viel anfangen.

Schaue ich mir aber z.B. VoiceXML an, so liegt das IMO eigentlich näher an dem was ich sagte: Binärdaten mit XML-Headern... die PCM-Daten liegen da nach wie vor binär ab. Auch SMIL geht in diese Richtung, ich meine, das ist letztlich so eine Art dynamisches HTML, aber die Mediadaten sind immer noch MPEGs, JPEGs, GIFs & Co.

Ich sehe also hier jetzt keinen, der Binärdaten wirklich in XML als Zeichen reincodiert.

Ich finde Eure Diskussion durchaus interessant, jedoch seid ihr vom Thema abgekommen. Ihr konntet mir nicht wirklich wiederlegen, dass XML keine Zukunft hat. Also habe ich recht?

Prof84

Original erstellt von Marc++us:
**Ja, nur muß ich bei diesem Punkt Daniel E. zustimmen:

Nicht alles was möglich ist, ist auch sinnvoll.

Es kann nicht sein, daß sich die Forschung über Jahre den Kopf zerbricht wie man Audio- und Videodaten mit Hilfe von Fourier- oder Wavelet-Methoden zerkleinert, und nachher kommen einige fröhliche Jungs die es geil finden eine neue Spezifikation auch darauf anzuwenden und plötzlich ist die Filegröße einen Faktor 2 (da landet man ja mindestens) größer. Wer das macht, hat den Schlag nicht gehört.**

Nun, dass XML das kompakte Format zu gunsten einer transparent, sicheren und patternorientierten Lösung aufgibt, haben wir ja vorher diskutiert. Und das eine Kapselung aus dem SGML zu einen XML Standard das Datenvolumen, wie Du meinst verdoppeln kann, wurde von der W3C und jedem anderen führenden Softwareunternehmen der Welt bewußt in Kauf genommen. Da jeder Standard - wie sagten die Kids hier - "bloatig ist". Aber ein Standard macht ein Verfahren für den Durchschnitt erst praktikabel. Deine Sichtweise wurde nur zu oft in der Softwaregeschichte angeführt:
"Warum denn eine Hochsprache lernen? Mit Assembler schreibe ich viel kompaktere und schnellere Programme!".
"Warum denn Windows installieren? Das kostet nur die Hälfte meines Hauptspeichers."
"Und warum Objektorientierung ...?!"
Nun ob das nun alles zum Wohle der Menschheit sein wird?! Die Frage kann man zurückverfolgen als Ed Roberts an seinen Altea schraubte und die Antwort steht noch aus.
Ist dir eigentlich klar, dass alles was Du jetzt auf Bildschirm siehst, sich aus einen Pool von Standards bildet?! Ob ein Standard immer sinnvoll ist, die Frage steht sich jeder, der mal eine Amtseingabe gemacht hat!
Wenn ich dann "den Schlag noch nicht gehört habe", dann macht das nichts. Dann schließe ich mich den Abermillionen anderer "Geisterfahrern" an und fahr euch trotzdem alle platt! :p

Original erstellt von Marc++us:
Vor allem weil es für Audio- und Videodaten auch hardwarebasierte Algorithmen gibt, die in Chips bzw. speziellen ASICs abgelegt sind - die können mit einem XML-Stream nicht so viel anfangen.

Wo steht geschrieben, dass Sie das müssen. Wozu gibt es Software...?

Original erstellt von Marc++us:
Schaue ich mir aber z.B. VoiceXML an, so liegt das IMO eigentlich näher an dem was ich sagte: Binärdaten mit XML-Headern... die PCM-Daten liegen da nach wie vor binär ab. Auch SMIL geht in diese Richtung, ich meine, das ist letztlich so eine Art dynamisches HTML, aber die Mediadaten sind immer noch MPEGs, JPEGs, GIFs & Co.

Ich habe jetzt nicht gesagt, dass es sich auschließlich um Binärübertragungen handelt. Bei VXML erinnere ich mich schwach eine Binärübertragung von Records. Du schriebst wörtlich: "die Header von Binärfiles wieder in XML abzulegen..." nicht "Binärdaten mit XMLfile" - Sagen wir mal Missverständnis
Was Du jetzt unter SMIL gefunden hast, kann ich im Moment nicht nachvollziehen.

cu

P84

japro

Original erstellt von <Doktor Prock>:
Ich finde Eure Diskussion durchaus interessant, jedoch seid ihr vom Thema abgekommen. Ihr konntet mir nicht wirklich wiederlegen, dass XML keine Zukunft hat. Also habe ich recht?

rotfl
niemand kann wiederlegen das ich in zukunft der alleinherrscher der welt werden. Also habe ich recht?

[ Dieser Beitrag wurde am 27.01.2003 um 07:41 Uhr von japro editiert. ]

Marc++us

Original erstellt von Prof84:
Nun, dass XML das kompakte Format zu gunsten einer transparent, sicheren und patternorientierten Lösung aufgibt, haben wir ja vorher diskutiert. Und das eine Kapselung aus dem SGML zu einen XML Standard das Datenvolumen, wie Du meinst verdoppeln kann, wurde von der W3C und jedem anderen führenden Softwareunternehmen der Welt bewußt in Kauf genommen.

Ich hatte mir einige der Formate jetzt noch mal angesehen und nirgendwo ein Format gesehen, das Binärdaten tatsächlich zeichencodiert in einer XML-Datei parkt. Das wäre auch wirklich der Hammer, wenn jemand MPEG als XML ablegen würde.

Insofern verstehe ich Deine Aussage nicht, ich bin nur ein entschiedener Gegner davon, hochkomprimierte Binärformate als XML abzulegen, wie Grafiken, Audio, Video.

Und soweit ich das im Schnelldurchlauf überblicke, machen das die Formate auch alle so: Grafiken, Audio und Video wird als Referenz (URI oder URL) im XML-File abgelegt und getrennt geladen. Das ist auch sinnvoll.

Ich sehe den Vorteil von XML auch darin, wenn Hersteller eigene Fileformate in XML ablegen, daß ich selbst sofort ein Format vorliegen habe, auf das ich über Parser zugreifen kann, keine Einwände.

Dennoch bleiben einige grundsätzliche Kritikpunkte an Software-Standards wie XML bestehen:

Aufblähung
Liest man sich die Spec von sowas wie VoiceXML durch sieht man rasch, daß hier wieder mal entgegengesetzte Richtungen in eine Spec sollten. Dadurch wird das Format extrem komplex und verliert irgendwann eben doch die Möglichkeiten einfacher Auswert- und Parsbarkeit, wenn man auch noch 100 Tags berücksichtigen muß, die man nicht braucht.
Zu schneller Entwicklungszyklus für Standards
Bsp SMIL, die sind schon bei Version 2.0. Welches Programm unterstützt SMIL aber schon? Ist noch nicht mal richtig auf dem Markt eingeführt und es gibt bereits ein 2.0. Die ganzen W3C-Standards bringen ein unglaubliches Versionschaos auf den Markt, siehe HTML - v1, 2, 3, 4, xhtml, davon gibt's auch wieder Versionen - zu viel zu schnell. Ein durch ein XML-Format beschriebener Standard sollte eben auch eine Laufzeit besitzen, das ist zur Zeit nicht immer gewährleistet. Wenn Du heute eine Software entwickelst, die z.B. einen Standard wie VoiceXML benutzt kannst Du getrost davon ausgehen, daß das in 2 Jahren mit nix mehr zusammen läuft. Weil in 2 Jahren für die gleiche Sache plötzlich ScreamXML v3 benutzt wird. Die Aussage der Softwarefirmen das langfristig zu unterstützen ist nicht das Papier wert auf dem diese Aussagen geschrieben stehen. Wenn die Softwarefirmen eines Tages es schaffen davon weg zu kommen bin ich auch mal geneigt Softwareindustrie zu sagen. Bis dahin ist's aber noch ein weiter Weg.

Einige XML-Entwicklungen sind auch absurd, z.B. Konzepte von IBM, Daten aus Datenbanken Record für Record als XML-Dateien abzulegen. Weil nun aber die ganze Suche zu lange dauerte, legt man eine Datenbank an, die die XML-Dateien indiziert, damit man auf den XML-Dateien eine schnelle Suche hat. Nun hat man eine neue Anwendung für die Datenbank gefunden: Indizierung von XML-Dateien. Das nenne ich Kopfschuß^3 - riecht verdächtig nach rekursiver Selbstherapie.

Bist du auch ein Proktologe?

echter Troll

Da fällt mir so nebenher ein, das Office 11 von M$ nicht mehr die Dokumente in .doc etc. abspeichert, sondern in xml.

Meiner Meinung nach ein Vorteil, kann ich doch auf wirklich jedem Rechenr das Dokument lesen und bearbeiten.

rüdiger

BTW. Open Office macht das schon längst.

Daniel E.

Original erstellt von Prof84:
W3C [...] bewußt

Kaum :). Wenn ich die W3C-Seiten so lese, dann habe ich das Gefühl, dass das größtenteils Satire ist (http://www.w3.org/TR/xexpr/ ).

Lustig ist auch die gesamte Idee hinter XML[1]:
<Theorie>Viele Leute sind mit derzeitigen komplexen Programmen so ausgelastet, dass sie sich nicht mehr ihrer richtigen Arbeit zuwenden können und nichts vernünftiges mehr machen. Also machen sie es noch komplizierter (durch falsche Anwendung z.B.), womit sich am Schluß alle nur noch mit extrem komplexen Umgebungen beschäftigen und nicht mehr mit dem Problem an sich.
Im Vergleich dazu beschäfftigen sich nur wenige Leute mit der Lösung von Problemen, die aber mit diesen unnötig komplexen Systemen der Mehrheit interagieren müssen. Dazu müssen sie diese Systeme aber erst einmal verstehen, und während sie das verstehen, können sie sich mit nichts sinnvollen auseinandersetzten.
Der Teufelskreis der Komplexität ...
Wenn jemandem nichts mehr einfällt, dann macht man eine neue (ein paar 2000 Seiten starke) Norm[1], um andere Dinge zu vereinfachen, und merkt dabei garnicht, dass er damit die Situation verschlimmert.
</Theorie>

In XML ist einfach 80% zu überflüssig.

XML bietet mir mehrere Schichten[1] an, die immer das gleiche immer komplett anders machen. '<a type="b">c</a>': Hier kann 'a' als das 'aufrufende' Element[1] oder einfach ein syntaktisches Element betrachtet werden. [Wenn letzteres gilt, dann bekommt 'b' 'aufrufende' Bedeutung.]
Diese Attribute[1] sind überhaupt nur nötig, weil man es XML nicht anders sagen kann, dass man 'etwas' von mehreren Eingabedaten machen möchte. Darum bekommt man gerne sehr generische[1] Daten:

<foo do="bla" name="fasel">
  <foo do"bla2" name="fasel2">
    <foo ...>xxx</foo>
  </foo>
</foo>

'foo', dass eigentlich für die Struktur[1] der Dateien gedacht ist, ist eigentlich absolut sinnlos. Man hat also Müll strukturiert, denn Attribute _kann_ man eben in XML nicht strukturieren, was mir auch nicht ganz logisch erscheint. Ausserdem sind die End-Tags[1] sind absolut überflüssig und häßlich. Wenn man einfach Tags schachten könnte ...

Darum u.a. halte ich XML für die meisten Anwendungen suboptimal (lies: Konzeptionell kaputt), denn um diese Defizite von XML auszubessern braucht es wieder eine neue 'Technologie', zum Beispiel DTD[1] (Siehe oben zum Thema 'Komplexität' :)). Und XML als etwas revolutionär Neues hinzustellen erscheint mir auch ein wenig realitätsfern ...

Aber ein Standard macht ein Verfahren für den Durchschnitt erst praktikabel.

Ein Standard um jeden Preis ist auch nicht praktikabel, denn er leistet nicht das, was 'man eigentlich will'[tm]. Oder was hältst Du von der Norminierung von Schraubenlängen auf 25 cm :)? Ich glaub' es war letztens Volkard, der behauptet hat, dass ein Standard Innovation und damit bessere Technologien unterbindet.

[1]: 9 Treffer beim Buzzword-Bingo ;).

Cheers, Daniel

[ Dieser Beitrag wurde am 27.01.2003 um 18:12 Uhr von Daniel E. editiert. ]

BTW. Open Office macht das schon längst.

Mag sein, aber: Wer oder was ist Open Office bitteschön.
(läuft bei mir übrigens nicht )

Ich denke mal, das gerade durch MS xml gut verbreitet wird, weil ja jeder DAU eine hypermega_Schreibmaschiene braucht, die er nicht benutzen kann (mal abgesehen von strg+o,s und p ... evt. noch ALT+F4).

Wenn der DAU merkt, dass ohne probs andere Programme auch seine Office_Dateien bearbeiten können, wird er Office wohl schnell verlassen, da dann Magazine wie Computer-DAU etc. viele bessere Progs vorstellen werden, die dann aus dem Boden schießen werden.

Dann können wir auch nochmal über Open Office reden

Ich persönlich arbeite schon länger mit xml finde es gar mal schlecht, Daten damit abzulegen. Durch eine externe DTD kann ich meine Mitmenschen endlich mal dazu zwingen, meine Struktur auch einzuhalten, da es sonst Fehler hagelt.

Marc++us

Original erstellt von <Luke>:
Durch eine externe DTD kann ich meine Mitmenschen endlich mal dazu zwingen, meine Struktur auch einzuhalten, da es sonst Fehler hagelt.

Das ist mal eine Aussage, die den praktischen Vorteil schön auf den Punkt bringt...

Wobei natürlich die eingefleischten Leser von W3C wissen, daß DTD ja wieder out ist und wir inzwischen bei den XML-Schemata angekommen sind... damit kann man dann auch Parameter auf Wertebereiche etc. prüfen.

zum Thema MS Office und XML

altes .doc File :

binary crap
binary crap
...

neues .xml File :
<xml>
binary crap
binary crap
...
</xml>

Also mal wieder typisch MS....

Stefan

Spiegelschatten

Aha. So etwas wäre Sinnlos. Aber das sind wir ja seit Fenster 95 gewohnt.

Ich glaube jedoch nicht, dass die es so machen werden.
Das wird eher wie den Manifest-Dateien aussehen.

Daniel E.

Original erstellt von <Luke>:
Durch eine externe DTD kann ich meine Mitmenschen endlich mal dazu zwingen, meine Struktur auch einzuhalten, da es sonst Fehler hagelt.

DTDs saugen. Sie sind nicht mit den 'typischen' XML-Werkzeugen manipulierbar und das, was 'non-validating' Parsern machen müssen, um die Gültigkeit von Dateien zu überprüfen ist mehr als krank. Außerdem ist DTD statisch, was faktisch fast verbietet, dass ich Programme modularisieren, und damit eine neue Syntax in den Dateien erlauben kann, kann.

Marc++us

Original erstellt von Daniel E.:
Außerdem ist DTD statisch, was faktisch fast verbietet, dass ich Programme modularisieren, und damit eine neue Syntax in den Dateien erlauben kann.

Bitte erklären und mit Aussage verdeutlichen, ich verstehe nur Bonhoff.

OT: Daniel E. rede doch mal wie ein normaler Mensch. Hier ist nicht jeder so hochintelligent wie du.

Daniel E.

Marc++us: Ein Programm, dass verscheidene Plugins unterstützten will, will XML als Standarddatenformat benutzten. Der normale Weg für XML ist ja, dass man ein DTD (statisch) anlegt und daran habt sich dann alles zu halten, was dieses Programm an XML-Code jemals ausgibt.
Nun lädt der Benutzter ein Plugin hinzu, dass eine _neue_ Funktionalität in das Programm miteinbringt (was eigentlich der Sinn sein sollte :)). Diese neue Funktionalität lässt sich aber nicht mit den Mitteln des ersten DTDs beschreiben. Soweit das Problem :). Das DTD anzupassen ist offensichtlich die falsche Strategie, denn damit werden ja Dinge erlaubt, die das Programm 'an sich' nicht leisten will. Das einzig sinnvollen Vorgehen, die mir einfallen sind folgende: Jedes Plugin erzeugt ein eigenes Format, welches wieder durch ein DTD beschrieben werden muss. Oder man baut eine Hierarchie aus XML-Dateien (man bindet also andere Dateien ein), und verwendet immer nur das, dieser Datei zugeordnete DTD. Beide Ansätzte sind nicht wirklich schön, weil die Anzahl der Dateien, die betrachtet (und gewartet und bla) werden müssen extrem schnell ansteigt und weil der Schreiber von neuen Plugins nicht mehr die schöne Schnittstelle zum Programm benutzten kann, sondern er muss zumindest ein eigenes DTD basteln ...

Das hört sich reichlich theoretisch an aber in vielen dynamischen Sprachen ist das Problem viel unmittelbarer sichtbar, weil man durch das hinzufügen von Modulen/Funktionen programmiert :-/!