was genau ist xml

[OregonGhost]

Den Speicherplatz sehe ich nicht als Problem. Wir haben hier in einer aktuellen Anwendung XML als Projektformat, das aber (zusammen mit einigem anderem Zeug) komprimiert wird, im Standard-ZIP-Format, so dass man es einfach im Explorer öffnen kann. Da lassen sich auch zig MB an XML in Sekundenbruchteilen laden (und sind als ZIP natürlich auch winzig, Komprimierungsraten von über 95% im Normalfall, den weitaus größeren Anteil haben die Binärdateien, die wir dazuspeichern müssen). Dabei handelt es sich natürlich nicht um "dumme" Daten in Form von Tabellen, sondern um eine komplexe Baumstruktur, die dann so oder so komplett im Speicher gehalten werden muss. Geht es nur um sehr große Tabellen, die man nicht im Speicher halten kann, steht man natürlich vor dem Positionierungsproblem.

Zitat:

Es gibt halt auch genügend Fälle, in denen ein binäres oder sonst wie gestaltetes Format mindestens genau so brauchbar, und in der Regel auch deutlich schneller zu verarbeiten ist.

Ja, und dann hat man für jede Art von Datei ein eigenes Dateiformat, für das man extra einen Parser schreiben muss. Dadurch gewinnt man doch nichts. Ich sehe das immer bei einem etwas älteren, in C++ geschriebenen Produkt bei uns und dem aktuellen, an dem ich arbeite. Beim alten muss man für jede noch so kleine Änderung an den Datenstrukturen auch die Routinen fürs Schreiben und Laden ändern. Beim aktuellen Produkt muss man meistens nichts ändern, in seltenen Fällen ein entsprechendes Attribut setzen, aber nie den Code anfassen. Und trotzdem kann man eine gespeicherte Datei problemlos angucken und analysieren, ohne ein entsprechendes Tool einsetzen zu müssen. Das sehe ich schon alles als gewaltigen Vorteil, der mit Hype nichts mehr zu tun hat.

[Medium]

Ich will XML nicht schlechter reden als es ist, versteh mich nicht falsch. Es ist wie so oft sehr vom Einsatzzweck abhängig was ich nun genau einsetzen mag. Letztlich hast du auch bei XML die Notwendigkeit einer Strukturbeschreibung, halt in Form einer DTD oder eines Schemas, statt in Prosa. Und wenn ich etwas ganz bestimmtes hinterlegen will, so habe ich auch bei XML das Problem, dass es nachdem fehlende oder falsch eingetragene Teile da sind, nachher nicht mehr zu der Struktur passt die meine Software erwartet. Ich hab es dann sicherlich leichter solche Fehler mit einem einfachen Texteditor ausfindig zu machen, das ganz unbenommen.

Für mich ist XML aber auch immer ein bischen so der Gipfel von "wir ham's ja". Wir haben die Rechenpower und den Speicherplatz, uns leisten zu können Daten in einem für Rechner völlig fremden Format zu hinterlegen: Klartext. Das bietet dem Menschen gewiss den Vorteil schneller etwas mit einer Rohdatenmenge anzufangen, es obligt aber der Maschine diese dann zu interpretieren, was meines Erachtens nach oftmals unnötig ist und Potential verschwendet. Nicht selten ist es doch letztlich die Maschine, die Daten im großen Stil nachher beim Anwender verarbeiten soll, und eben NICHT der Mensch in Notepad. Und das muss ich mir dann durch großformatigere Hardware erkaufen, die dann zu 30% damit beschäftigt ist menschliche Sprache zu übersetzen, die eigentlich für die Maschine gedacht ist. Im Grunde warte ich nur noch darauf, dass das heilige W3C eines Tages mit einem brandneuen Bitmap-Format ankommt:

Code:

<?xml version="1.0" encoding="UTF-8"?>
<bitmap>
  <properties>
    <size>
      <width>800</width>
      <height>600</height>
    </size>
    <layers>1</layers>
    <colorformat>
      <channelcount>4</channelcount>
      <byteforalphachannel>2</byteforalphachannel>
      <byteforredchannel>2</byteforredchannel>
      <byteforgreenchannel>2</byteforgreenchannel>
      <byteforbluechannel>2</byteforbluechannel>
    </colorformat>
  </properties>
  
  <bitmapdata>
    <layer1>
      <pixel>
        <row>0</row>
        <column>0</column>
        <alphavalue>255</alphavalue>
        <redvalue>0</redvalue>
        <greenvalue>0</greenvalue>
        <bluevalue>10</bluevalue>
      </pixel>
      <pixel>
        <row>0</row>
        <column>1</column>
        <alphavalue>255</alphavalue>
        <redvalue>0</redvalue>
        <greenvalue>5</greenvalue>
        <bluevalue>16</bluevalue>
      </pixel>
.
.
.
    </layer1>
  </bitmapdata>
</bitmap>

Solche Art von Misshandlungen meine ich (Ja, das ist karikiert - aber ich schließe nichts mehr aus, nach dem ich SVG gesehen habe.)

[xaromz]

Hallo,

Zitat von Medium:

...aber ich schließe nichts mehr aus, nach dem ich SVG gesehen habe.)

sag, mal, ich sehe Dich in letzter Zeit immer auf SVG rumhacken. Jetzt würde mich doch mal interessieren, warum Du so eine Abneigung dagegen hast (ich persönlich finde das Format nämlich super).

Gruß
xaromz

[Medium]

Das muss ich dann als Frage formulieren: Was für einen Vorteil bringt SVG einem Grafiker (also für den, der Grafikformate nutzt, nicht implementiert) gegenüber nicht lesbaren Vektorformaten?

[Namenloser]

Zitat von Medium:

Das muss ich dann als Frage formulieren: Was für einen Vorteil bringt SVG einem Grafiker (also für den, der Grafikformate nutzt, nicht implementiert) gegenüber nicht lesbaren Vektorformaten?

Ich denke, die Frage beantwortet sich selber: SVG bringt dem programmierer was, sodass SVG eine große Kompatiblität hat - was wiederum gut für den Grafiker ist, der seine Bilder ja verbreiten möchte.

Ich bin SVG gegenüber trotzdem skeptisch, weil ich der Meinung bin, dass man Mediendateien wie Bilder oder Videos (komtm vllt auch noch ) prinzipiell nicht in textbasierten Dateiformaten abspeichern sollte. Hier kommt es ja auch nicht darauf an, dass es Human Readable ist, stattdessen kommt es gerade im Internet (wo das SVG-Format ja mittlerweile recht weit verbeitet ist) darauf an, dass Dateien möglichst klein sind, damit sie schnell geladen werden können.

Andererseits ist mri auch noch keine SVG-datei mit einer unangenehm langen Ladezeit aufgefallen (wenn lags meistens an der lahmen Gecko-Engine).

[Medium]

Das ist eben der Punkt: Es ist bestenfalls für den Entwicklungszeitraum eine kleine Entlastung, im restlichen Lifecycle und damit besonders der Produktivumgebung ist es eher eine Belastung. Ich finde es auch recht witzig, dass so gerne die Portabilität hervor gehoben wird. Letztlich muss ich ja doch für jedes Programm einen Importfilter schreiben um es lesen zu können, nur dass es dabei nun statt min. einem nun kein System mehr gibt, dass z.B. das Zahlenformat nativ verwendet.
Wenn auf ein Mal alle extrem begeistert von iBVG sind, meinem fiktiven "interchangeable Binary Vector-Graphics"-Format und 90% der Hersteller finden, sie müssten das Format unterstützen, dann ist das auch extrem portabel
Mir stellt sich dann die Frage, ob der geringe Nutzen der Lesbarkeit durch Menschen rechtfertigt, dass man nun nicht mehr auf 50% der Systeme Big- nach Litte-Endian wandeln muss und beim Rest gornüscht, sondern auf 100% der Systeme träge Stringinterpretation verwendet. Für Dateien, die bestenfalls 1% der Anwender jemals in einem Texteditor öffnen wird, und auch da nur um nachher erstaunt "aha, so sieht das also aus" zu sagen.

Man nehme sich z.B. mal dieses Bild von der Wikipedia. Dafür über 1 MB zu verbrauchen ist finde ich schon fast eine Frechheit. Selbst als ZIP sind es mit rund 320kB noch zu viel, und vor allem NOCH ein Verarbeitungsschritt mehr. Das ist für ein einzelnes Bildchen evtl. noch unerheblich, aber man sollte auch an die zu erwartenden Dimensionen denken, wenn ich sowas einsetzen will. Man durchsuche mal so 1000 gezippte SVGs dieser Größenordnung nach, sagen wir mal, Elementen die >100 Pixel breit und bläulich sind. Bis die alle ausgepackt und in Bäume geparst sind, hab ich 5000 Bilder in einem Chuck-Organisierten Binärformat durch, die zu dem 1/10 des Platzes belegen.


Noch mal in aller Deutlichkeit: Es gibt reichlich Anwendungsbeispiele, in denen XML ein prima Ding ist! Aber insbesondere der Weg der mit SVG beschritten wurde ist für mich ein Zeichen davon, dass XML offenbar im allgemeinen als "kanonisch optimal" und auf alles anwendbar angesehen wird. Und wenn fast alle unreflektiert rufen: "Das ist prima!", dann hat das finde ich durchaus Züge von Hype. Einzelne mögen wohl durchdachte Gründe vorbringen können warum das gerade hier oder dort gut passt, und das ist ja auch völlig okay, aber ich sehe nicht, dass das weltweit gesehen in allen Bereichen der Fall wäre.

Hab auch kürzlich ein paar Stellenausschreibungen durchgesehen. In fast jeder kam in der Anforderung der Punkt "XML" vor, und zwar meist ohne weitergehende Erläuterung, und auch teilweise in Zusammenhängen in denen es entweder eine untergeordnete Rolle spielt (nach dem Motto: In dem Format sind die Config-Files), oder gar kaum zum Job gehörte. Bei einer Ausschreibung für einen Nebenjob in einem Helpdesk für MS-Office Anwender eines Unternehmens ist der Punkt "XML" doch wirklich nur noch da, weils irgendwie jeder schreibt und ganz toll und modern aussieht. Das ist Hype.

[xaromz]

Hallo,

Zitat von Medium:

Das ist eben der Punkt: Es ist bestenfalls für den Entwicklungszeitraum eine kleine Entlastung, im restlichen Lifecycle und damit besonders der Produktivumgebung ist es eher eine Belastung. Ich finde es auch recht witzig, dass so gerne die Portabilität hervor gehoben wird. Letztlich muss ich ja doch für jedes Programm einen Importfilter schreiben um es lesen zu können, nur dass es dabei nun statt min. einem nun kein System mehr gibt, dass z.B. das Zahlenformat nativ verwendet.

nun, das ist aber doch der Punkt. Weil es ein einfach zu implementierendes Format ist, ist es auch weit verbreitet. Und schau Dir mal an, welche Probleme Microsoft mit ihren binären Office-Formaten hat. Die haben nicht umsonst eine neues Format (XML-basiert) eingeführt. Die Spezifikation (soweit vorhanden) füllt ganze Regale und ist wohl auch von MS langsam nicht mehr zu überblicken. Was mich zum nächsten Punkt bringt: So ein XML-Format ist leicht zu erweitern und eine neuere Version kann auch von einem alten Programm gelesen werden, das ignoriert dann eben die neuen Tags.

Zitat von Medium:

Man nehme sich z.B. mal dieses Bild von der Wikipedia. Dafür über 1 MB zu verbrauchen ist finde ich schon fast eine Frechheit.

Das ist ein extrem schlechtes Beispiel. In dem Bild sind z. B. sämtliche Texte als Pfad abgespeichert. Wenn ich will, kann ich jedes Format (auch Binärformate) aufblasen.

Gruß
xaromz

[Namenloser]

Officedateien bestehen aber auch größtenteils aus Text (naja, zumindets sollte es so sein, wenn man sich den HTML-Export von Office anguckt, kriegt man einen anderen Eindruck). Alles weitere sind Formatierungen, die auch keinen großen Platzbedarf haben und teilweise selber auch wieder Text sind (z.B. Font Name).
Die Flexiblität ist natürlich eine tolle Sache, und einer der größten Vorteile von XML. das wird sicherlich auch einer der Gründe für die große Verbreitung sein. Allerdings muss man scih manchmal Fragen, ob diese Flexiblität (zumindets in dem Ausmaße) wirklich nötig ist: Bitmaps gibt es ewig, und sind sie je erweitert worden? Eigentlich nicht, außer, dass sie vielleicht die Farbtiefe geändert hat.
Außerdem kann man Formate auch anders flexibel halten. Z.B. bestehen PNG-Dateien aus sogenannten Chunks, die hintereinander in der Datei stehen. So wurde z.B. die PNG-Erweiterung APNG, die Animationen ermöglicht, implementiert. Tortzdem braucht das PNG-Format sehr wenig Platz.

[Medium]

Zitat von xaromz:

Und schau Dir mal an, welche Probleme Microsoft mit ihren binären Office-Formaten hat.

Ich kann hier in einem, vor dir vermutlich so nicht gemeinten Punkt zustimmen: Man kann binäre Formate ungünstig designen (aber nicht nur diese). Dieses Propietär zu halten war dabei wohl der ungünstigste Aspekt, hat aber mit der "Binärität" wiederum nichts zu tun.
Dass MS nun ein XML-basiertes Format einführt, klingt doch super. Fast in allen Office-Applikationen werden Medien kombiniert, im Wesentlichen Klartext Inhalte gespeichert, und eine visuelle Repräsentation erstellt - oftmals auch mit einer Gewissen Hierarchie. Word ist z.B. ein tolles Anwendungsgebiet, dort würde ich XML auf jeden Fall auch in die engere Auswahl nehmen. Ich wüsste nur noch nicht, wie ich mit eingebetteten Medien umgehen wöllte. Hinterlege ich ein importiertes Video in PowerPoint direkt inline in seinem Tag, muss es dafür aber Base64 encoden, leiste ich es mir diese in externe Dateien zu stecken auf die ich verweise und fasse nachher alles in ein zip oder Cabinet zusammen, oder erweitere ich mutwillig das Format, und stecke Binärdaten hinter das schließende Root-Tag in eine Chunk-Artige Struktur?
Konsequent wäre der erste Ansatz, aber Base64 ist so eine blöde Zwischensache um binär in zumindest darstellbaren Zeichen zu zwingen, dabei aber auch wieder eine Interpretationsstufe einzuführen, und den Platzbedarf zu vervierfachen. Am "besten" wäre natürlich ein ebenfalls XML-basiertes Videoformat dass ich einfach so inline zwischenschieben kann, aber was das hieße wenn man es zu Ende denkt, sollte denke ich meine Bitmap-Karikatur oben ganz gut demonstrieren.
Der Teufel steckt wie immer im Detail. XML ist hier ein guter Ansatz, aber keineswegs ausreichend um alle Anforderungen möglichst optimal zu erfüllen. Was mich bei XML dabei besonders stört ist, dass es jegliches Vorkommen von Binärdaten verbietet, und mich damit vom Start weg in meiner Flexibilität einschränkt, wenn ich mich wirklich an die Standards halten will/muss.

Was die Erweiterbarkeit angeht, so hat NamenLozer schon genau das richtige Stichwort genannt: Chunks. Ein Paradebeispiel ist da z.B. auch das RIFF Format, konkreter RIFF-Wave. Man kann völlig beliebig Chunks hinzufügen, so lange man die (per konkreter Spezifikation) drei Kern-Chunks auch drin hat. Und diese drei sind alles, was ein Player z.B. kennen muss, der egal wie erweiterte Wave Files einfach nur abspielen soll.

[Namenloser]

Ich habe mir aus dem Grund eine kleine "BinaryXML"-Unit geschrieben. grundstruktur ist ähnlich wie bei XML, nur dass es keine Attribute gibt 8auch wenn ich sie zuerst geplant hatte), weil ich sie einfach nicht brauche. Daten wie Bilder, die sich nicht gut in einer Baumstruktur speichern lassen, bracuh ich so nur noch in einen Memorystream zu packen und in einen tag zu speichern (genauergesagt sind die tags von TMemorystream abgeleitet). Einige Kompofrtfunktionen sind auch noch dabei, sodass z.B. auf den Inhalt per property auch als Integer, String usw zugegriffen werden kann. Sozusagen Variants Light.
Bisher nutze ich das aber erst in einem Projekt. Ich habe aber noch vor es in ein anderes Projekt einzubauen, in dem ich bisher listen von PNG-Bildern als XML speichere (Base64), was also eigentlich eine Schande ist.