XML hat so keine Zukunft. Es geht unter.
-
warum in xml daten speichern?? die werden ja sonst viel zu größ!!
-
jeder kann es auslesen ( -> portabilität) und nochdazu kann man sich so nen aufbau leichter merken, als irgeneinen binäraufbau einer datei
-
Is ganz einfach - man speichert die Files in XML, und jagt danach nen Packer drüber, dann brauchen sie auch ned so viel Speicherplatz
Naja - für INI Files is ja XML ganz ok
- aber viele Sachen, sind einfach Schmarn, wo XML eingesetzt wird. Soviel Overhead muß nicht wirklich immer sein.
Nur um "Yea - wir sind im Trend" sagen zu können, weiß ich nicht, ob es denn wirlich sein muß[ Dieser Beitrag wurde am 24.01.2003 um 18:22 Uhr von SnorreDev editiert. ]
-
XML - was ist das eigentlich? Ein Dateiformat? Eine Sprache? Für was? Also: Was ist XML, und wozu ist es gut?
-
XML ist eine Markupsprache.
Genauer gesagt, ist XML eine Spezifikation, wie man Daten speichern muss, damit sie Platform unabhängig ausgelesen werden können.
-
Beispiel?
-
<?xml version = "1.0" encoding = "UTF-16"?> <Fonts> <!-- MSK files. Note that these should be specified before any fonts. --> <MSKFile typeFace = "Arial" file = "Arial.msk"/> <MSKFile typeFace = "MS Pゴシック" file = "mspgthc.msk"/> <!-- Arial --> <Font Name = "Arial 10"> <param TypeFace = "Arial"/> <param AscentHeight = "10"/> <param Antialiased = "false"/> <param Bold = "true"/> <param Italic = "false"/> <param BackgroundOutline = "false"/> <param BackgroundShadow = "true"/> <param BackgroundOffset = "1"/> <param BackgroundAlpha = "0.5"/> <param SpacingAdjustment = "0"/> <ResolutionOverride ResX = "1280"> <param AscentHeight = "12"/> </ResolutionOverride> </Font> ...
Ist ein Stück aus einer Datei bei Age of Mythology von MS. Hab auf die Schnelle nix anderes gefunden...
-
Ich mach mal 2 Beispiele:
1. Die Firmen Beispiel AG und Mustermann GmBH wollen zusammen arbeiten, sie benutzen 2 unterschiedliche Systeme, die wahrscheinlich noch auf unterschiedlichen OSs und auf unterschiedlicher Hardware läuft, da es kein standardisiertes Protokoll für ihre Anwendung gibt, stehen sie vor einem Problem, beide Systeme benutzen proprietäre Protokolle, die wunderbar funktionieren, solange man mit dem eigenen System arbeitet (wobei man natürlich immer die gleiche neueste Version der Software haben muss ;)). Also versucht man sich auf ein Protokoll zu einigen, man benutzt die XML Ausgabe der Programme (oder parst die Ausgabe in eine XML Datei) zB. so etwas
<?xml version = "1.0"?> <kaufe> <produkt-id>0012</produkt-id> <stueck>100</stueck> <preis waehrung="euro">10</preis> </kaufe> <signatur><!-- ... --></signatur>
Vielleicht unterscheidet sich die XML Ausgabe des Programmes, dann ist man auch nicht verloren, da man mit XSL(T), dass ist eine Sprache, die mit XML definiert wurde, die Daten leicht umwandeln kann und so kann ein Programmierer innerhalb von ein paar Stunden die Kommunikation zwischen den proprietären Welten herstellen.
Deine Firma hat eine andere Firma aufgekauft, beide Firmen bieten ein gleiches Software Produkt an, die Features, die die andere Firma hatte, werden nun im Eilverfahren in das eigene Produkt integriert (wobei natürlich unzählige Bugs entstehen, was man aber mit 2 bis 7 Service Packs ausbaden kann ;)), nun muss die eigene Anwendungs Konfigurations Datei erweitert werden und den Nutzern des Produkts, der übernommenen Firma, soll eine einfache Methode zum tauschen der Software gegeben werden, um möglichst viele Kunden zu übernehmen.
Wenn die Firma nun ein ASCII Zeugs benutzt hat, kann das leicht zu einem Problem führen, vor allem wenn die Konfigurationsdatei eh schon wild durcheinander ist, da man dort nie aufgeräumt hat und immer mehr Features hinzugefügt hat, also steht die Firma vor einem Problem, wenn man noch mehr hinzufügt, dann geht die Datei wirklich daneben aber wenn man mal vernünftig aufräumen will, muss man den Release Termin verschieben, bei XML wär das kein großes Problem, da der Syntax vorgegeben ist, kann man leicht etwas hinzufügen und mit XSL(T) kann man die Konfigurations Datei des anderen Produkts leicht in das eigene Format umwandeln.
hoffe, dass die Beispiele dir ein wenig helfen.
-
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...
-
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...
-
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
-
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?
-
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! :pOriginal 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
-
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. ]
-
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?
-
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.
-
BTW. Open Office macht das schon längst.
-
Original erstellt von Prof84:
W3C [...] bewußtKaum :). 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. ]