Was genau ist eigentlich XML?

[Seph]

Ja, klingt vielleicht komisch die Frage, ist aber mein Ernst. Die Wiki-Definition habe ich gelesen, werde aber nicht schlau daraus. Warum hat man denn XML "erfunden"? Und welche Vorteile bringt es?

[darph]

XML ist SGML (http://de.wikipedia.org/wiki/SGML). Es gibt keine Antworten. Nur Querverweise.

XML ist eine Auszeichnungssprache. Du kannst Daten sagen, daß sie nicht nur einen Wert haben (5, "Meier" sondern auch einen Typ (Ganzzahl, Kapitelzahl, Vorname). Das kannst du prinzipiell auch durch eine einfache Liste machen.

Nachname: Meier
Vorname: Gerd

Aber was, wenn du Daten hast, die wiederum Daten enthalten? Stell dir vor du hast zwei Datensätze. Jeder Datensatz repräsentiert eine Person. Wie speichert du jetzt Name und Alter zu jeder einzelnen Person?

[Seph]

Uff...wird noch nicht so ganz klar.

Also als erstes Mal zur Abgrenzung: HTML ist ja auch eine Auszeichnungssprache. Könnte ich jetzt XML als eine komplexere Auszeichnungssprache bezeichnen, die HTML u.a. "beinhaltet"?

Das Beispiel mit den Datensätzen verstehe ich leider nicht wirklich. Das hat jetzt aber nichts mit Datenbanken (SQL etc.) zu tun?

[rotalever]

Uff...wird noch nicht so ganz klar.

Also als erstes Mal zur Abgrenzung: HTML ist ja auch eine Auszeichnungssprache. Könnte ich jetzt XML als eine komplexere Auszeichnungssprache bezeichnen, die HTML u.a. "beinhaltet"?

Das Beispiel mit den Datensätzen verstehe ich leider nicht wirklich. Das hat jetzt aber nichts mit Datenbanken (SQL etc.) zu tun?
HTML und XML kann man durchaus vergleichen, schaut man sich zwei Dokumente an, sehen sie schließlich sehr ähnlich aus. Ich glaube XHTML erfüllt die XML-Spezifikationen?
XML ist im Endeffekt nichts anderes als ein Datei-Format, genauso wie ZIP oder DOC. Nur das man XML auch als Mensch lesen kann. Es wurde glaube ich erfunden damit Programme leichter Daten austauschen können. Es ist halt so universell angelegt, dass man damit (fast) alles speichern kann.

Das schöne daran, dass es Parser gibt, sodass man auf die Daten leicht zugreifen kann und sich nicht selbst um I/O kümmern muss.

[darph]

Zu XML und HTML: Jein.

XML ist eine Untermenge von SGML. SGML ist noch etwas größer und komplexer. XML selbst sagt dir nicht, was deine Daten bedeuten.

HTML ist eine Anwendung von SGML (merke: HTML ist kein XML. Wenn XML der kleine Bruder von SGML ist, dann ist HTML das Kind von SGML). HTML trägt Bedeutung. HTML sagt dir "Das hier ist eine Überschrift" und "Das hier ist ein Absatz".

XML und SGML benutzt du, um zu sagen "Wenn du einen Absatz haben möchtest, mach p drumrum."

Das Beispiel mit den Datensätzen verstehe ich leider nicht wirklich. Das hat jetzt aber nichts mit Datenbanken (SQL etc.) zu tun? Mit SQL nicht, aber mit Datenstrukturen.

Du hast ein Buch. Dieses Buch hat einen Titel. Das Buch hat einen Autor. Es hat 33 Kapitel. Außerdem hat das Buch die Eigenschaft, ein Hardcover zu sein.

Jetzt überlege dir ein Format, wie du diese Information speichern kannst, so daß sie schnell und einfach von Maschinen verarbeitet werden kann.

SGML und XML sind eine Antwort auf diese Frage.

[Seph]

Ja, aber was genau macht man denn mit XML? Wann "benutzt" man es? Kann man damit Webseiten programmieren etc.? Mir leuchtet der übergeordnete Zweck einfach nicht ein und was es unterscheidet von bspw. HTML, außer dass es wohl mehr Möglichkeiten bietet.

[Gast]

Ja, aber was genau macht man denn mit XML? Wann "benutzt" man es? Kann man damit Webseiten programmieren etc.? Mir leuchtet der übergeordnete Zweck einfach nicht ein und was es unterscheidet von bspw. HTML, außer dass es wohl mehr Möglichkeiten bietet.

Anwendungsbeispiel VS2005: http://www.galileocomputing.de/openbook/visual_csharp/visual_csharp_08_000.htm#Xxxobkap080000400185c1f01c187

[Seph]

Also ist es eine Art Beschreibungssprache, die universeller als HTML verstanden werden kann? Also ich kann damit einem Browser sagen, lass es so und so aussehen, ich kann aber gleichzeitig sagen, wenn es in Office angezeigt wird, lass es so und so aussehen? Also eine umfangreichere Weiterverarbeitung?

EDIT:

Ich bin kein Progger oder so...habe nur mal ein bisschen HTML und CSS gemacht. Mir geht es nur darum mal den Knackpunkt zu verstehen. Die ganzen Beschreibungen die ich Netz so lese sind oft sehr kompliziert und spezifisch und bringen die Sache irgendwie nicht so auf den Punkt...jedenfalls nicht so, dass mein Gehirn es versteht. ;)

[darph]

Also ist es eine Art Beschreibungssprache, die universeller als HTML verstanden werden kann? Also ich kann damit einem Browser sagen, lass es so und so aussehen, ich kann aber gleichzeitig sagen, wenn es in Office angezeigt wird, lass es so und so aussehen? Also eine umfangreichere Weiterverarbeitung?
Nein. Mit HTML gibst du deinen Daten einen "Typ". Überschrift. Bild. Textabsatz.

Mit XML beschreibst du, wie HTML aussieht. Also wie die Daten aussehen. Mit XML erzeugst du HTML und mit HTML erzeugst du dann ein Dokument/eine Website.

Es geht hier aber nur um Daten. Um Information. Es geht nicht um die Darstellung. In einem (X)HTML-Dokument steht nicht, daß zum Beispiel alle Überschriften groß und fett sind. In einem HTML-Dokument steht nur "Das ist eine Überschrift".

Das ist ein HTML-Dokument.
<html>
<head>
<title>Titel</title>
</head>
<body>
<h1>Überschrift</h1>
<p>Absatz</p>
<p>Lorem Ipsum...</p>
</body>
</html>

Das ist ein BUCH-Dokument.
<buch>
<titel>Titel</titel>
<autor>darph</autor>
<kapitel>
<kapitelüberschrift>Dies ist das erste Kapitel</kapielüberschift>
<absatz>Ich bin in Absatz</absatz>
<absatz>Ich bin in noch ein Absatz</absatz>
</kapitel>
</buch>


Das sind beides Anwendungen von XML. Ich habe XML benutzt, um zu sagen, wie ich eine Überschrift für mein Buch definiere. Mit XML kann ich sagen "Der Autor steht in den Tags "autor".

[instinct]

XML ist vorallem gut um ein standardisiertes Dateiformat zu haben, soll heißen, dass man aus einem Programm die Daten als .xml exportieren kann und ohne Probleme eine anderes Programm diese importieren.

[Gast]

Also ist es eine Art Beschreibungssprache, die universeller als HTML verstanden werden kann? Also ich kann damit einem Browser sagen, lass es so und so aussehen, ich kann aber gleichzeitig sagen, wenn es in Office angezeigt wird, lass es so und so aussehen? Also eine umfangreichere Weiterverarbeitung?

EDIT:

Ich bin kein Progger oder so...habe nur mal ein bisschen HTML und CSS gemacht. Mir geht es nur darum mal den Knackpunkt zu verstehen. Die ganzen Beschreibungen die ich Netz so lese sind oft sehr kompliziert und spezifisch und bringen die Sache irgendwie nicht so auf den Punkt...jedenfalls nicht so, dass mein Gehirn es versteht. ;)

Die Stylesheets für XML ist XSL, ähnlich wie CSS für HTML: http://www.w3schools.com/xsl/xsl_languages.asp

XML ist sehr mächtig, du kannst damit auch komplette Webseiten generieren oder Office-Dokumente speichern wie z.B. in Open Office.

[Seph]

Mit XML beschreibst du, wie HTML aussieht. Also wie die Daten aussehen. Mit XML erzeugst du HTML und mit HTML erzeugst du dann ein Dokument/eine Website.

Hm, ok, vielleicht lässt sich hier drauf aufbauen. Es ist also eine Metasprache mit der ich HTML beschreibe. Du sagst, ich erzeuge mit XML HTML. Wie genau geht dieser Prozess vonstatten?

Also kann ich meinetwegen mit XML beschreiben, dass alle Überschriften fett sind, während ich mit HTML jede Überschrift einzeln als fett deklarieren müsste?

[EgonOlsen]

Ja, aber was genau macht man denn mit XML? Wann "benutzt" man es? Kann man damit Webseiten programmieren etc.? Mir leuchtet der übergeordnete Zweck einfach nicht ein und was es unterscheidet von bspw. HTML, außer dass es wohl mehr Möglichkeiten bietet.Du kannst, wenn du es mit XSLT kombinierst, damit auch Webseiten machen, d.h. du generierst HTML aus dem XML. Das kann serverseitig passieren, aber auch im Browser. Aber das würde ich nicht als Hauptzweck sehen.
XML ist praktisch zum Datenaustausch und/oder für Ajax. Du hast auf fast jeder Plattform Parser und Generatoren dafür. Das macht es einfach, ein XML-Dokument zu verwenden. Wenn du ein eigenes Datenformat wählen würdest, müsstest du immer einen eigenen Parser dafür bauen. Bei XML brauchst du das zumeist nicht, weil eigentlich für fast jede Umgebung sowas schon da ist.

[darph]

so kann ich meinetwegen mit XML beschreiben, dass alle Überschriften fett sind, während ich mit HTML jede Überschrift einzeln als fett deklarieren müsste?
Nein. Löse dich von der Vorstellung, daß Überschriften fett sind. Sind sie nicht. Sie sind nur "Überschriften". Es ist nur Information. Information hat kein Aussehen.


Mit XML sagst du: "Überschriften sind Überschriften, wenn sie zwischen <h1>...</h1> stehen". Das ist die Metasprache. Mit dieser Sprache (XML) beschreibst du die Sprache (HTML).

Das hat nichts mit fett oder kursiv zu tun.

[Seph]

Gut, kapiert. Ich lege also in XML fest, was eine Überschrift ist. Bspw. ist es dann eine Überschrift, wenn sie zwischen den HTML-Tags h1 und /h1 steht (könnte ich da theoretisch auch irgendwas anderes festlegen, was nicht aus HTML stammt?). Aber wer liest dieses XML dann wie aus, dass letztlich eine Webseite daraus entsteht?

EDIT:

Mein Problem ist einfach auch, dass der Kram ja genauso aussieht wie HTML...

Wiki-Beispiel:

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<wikipedia>
<titel>Wikipedia Städteverzeichnis</titel>
<eintrag>
<stichwort>Genf</stichwort>
<eintragstext>Genf ist der Sitz von ...</eintragstext>
</eintrag>
<eintrag>
<stichwort>Köln</stichwort>
<eintragstext>Köln ist eine Stadt, die ...</eintragstext>
</eintrag>
</wikipedia>


Beispielsweie wird der Titel festgelegt...

[Bietchiebatchie]

Ich bin kein Progger oder so...habe nur mal ein bisschen HTML und CSS gemacht. Mir geht es nur darum mal den Knackpunkt zu verstehen. Die ganzen Beschreibungen die ich Netz so lese sind oft sehr kompliziert und spezifisch und bringen die Sache irgendwie nicht so auf den Punkt...jedenfalls nicht so, dass mein Gehirn es versteht. ;)

Ich vermute mal der Knackpunkt liegt bei deiner fehlenden Programmiererfahrung ;)
Wenn man xml nutzt macht man in der Regel die gesamte Struktur des Dokumentes/der Daten die man speichert explizit.

Was heißt das konkret? Um darps Beispiel zu holen

Du hast ein Buch. Dieses Buch hat einen Titel. Das Buch hat einen Autor. Es hat 33 Kapitel. Außerdem hat das Buch die Eigenschaft, ein Hardcover zu sein.

Das ist natürliche Sprache - für den Menschen sehr einfach zu lesen, für Maschinen (wenn überhaupt) nur mit extremen Aufwand zu verstehen. Außerdem "zugemüllt" mit natürlichsprachlichem Schnickschnack.


Reduziert man das ganze auf die wesentlichen Informationen und strukturiert man das ganze etwas, könnte es ein Computer schon deutlich besser lesen:

Buch:
- Titel = ...
- Autor = ...
- Anzahl Kapitel =
- Format = Hardcover


Geht man jetzt weiter und macht man jegliche Struktur explizit erhält man xml:

<Buch>
<Titel>...</Titel>
<Autor>...</Autor>
<KapitelAnzahl>...</KapitelAnzahl>
<Format>Hardcover></Format>
</Buch>

Der Vorteil bei letzterer Darstellung ist einfach, dass ein Computer das ganze extrem leicht bearbeiten kann - und es kann immer noch von Menschen gelesen werden.


Hoffe, ich konnte etwas helfen ;)

[Seph]

Etwas. ;) Ich glaube, was meinem eigentlichen Verständnis entgegen steht ist die für mich immer noch undurchsichtige Differenzierung von HTML. Ok, ich habe verstanden, dass XML nur "Zusammenhänge" oder "Zustände" beschreibt, während HTML die Daten quasi direkt bearbeitet, ohne Beschreibung. Also wäre nach meinem Verständnis das eine eine "Beschreibungssprache", das andere aber eine "Auszeichnungssprache". Trotztdem wird XML AUCH als "Auszeichnungssprache" aufgeführt.

Was ich jetzt in den Code-Beispielen sehe ist, dass halt keine expliziten Befehle benutzt werden wie bei HTML sondern offenbar frei festzulegende Begriffe, um die Daten zu strukturieren. Aber wenn ich jetzt bspw. mit XML eine Webseite erzeugen möchte und auf dieser Webseite soll eine Stelle im Text kursiv sein, wie beschreibe ich das dann, damit es auch passiert? XD

[Monger]

XML ist ein Datencontainer. Nicht mehr, nicht weniger.

Ursprünglich hat man die meisten Daten als Binärdaten gespeichert. Das ist bis heute eigentlich auch das was am geläufigsten ist - die meisten Word Dokumente sind als Binärdaten gespeichert, genauso wie jedes JPEG, und jeder Speicherstand in einem Computerspiel.

Der Vorteil eines binären Formates ist, dass es relativ kompakt ist, und schnell bearbeitet werden kann. Klartext braucht halt immer noch irgendjemanden, der diesen Text liest und deutet - das braucht natürlich Performance.

Der Nachteil ist, dass Daten so zwischen Anwendungen fast nicht austauschbar sind. Wenn man sich nicht auf sehr klar definierte Schnittstellen geeinigt hat, hat man fast keine Chancen ohne den Original Quellcode die Binärdaten wieder rückzulesen. Auch kleinste Fehler in der Datei, oder leichte Änderungen am verarbeitenden Programm können die Daten komplett unleserlich machen.

Nun wurden die Rechner mit der Zeit immer schneller, und insbesondere mit den modernen Sprachen die ja ohnehin auf Byte Code basieren, wurde auch die Verarbeitung von Klartext immens schneller. Deshalb geht gerade der Trend dahin, zumindest die Daten die sich in Klartext vernünftig formulieren lassen, irgendwie in XML zu lagern.
Zwischendrin gab es auch andere Klartextformate, wie z.B. CSV. Der Vorteil an XML ist halt, dass XML nicht nur die Daten selbst abbilden kann, sondern auch noch die Datenstruktur. Sprich: in einem XML Dokument steht möglicherweise nicht nur eine Tabelle, sondern auch gleichzeitig eine Bedienungsanleitung wie diese zu verstehen ist. Das ist alles andere als selbstverständlich, und aufgrund dieser Vielseitigkeit und Robustheit setzt sich XML - in den verschiedensten Geschmacksrichtungen - langsam aber sicher durch.

[DanMan]

Wie Monger ja schon geschrieben hat. XML ist eine Möglichkeit Informationen strukturiert zu speichern. Warum wurde es erfunden? Ich denke mal, weil es einfach von jedem Menschen gelesen und auch (mehr oder weniger) verstanden werden kann. So hat es auch Vorteile was zukunftsicherheit angeht, weil es ein einfaches rein-text Format ist, das auch später noch problemlos geöffnet und gelesen werden können wird (uiuiui, war das gerade Futur 2? :ugly: ).

Anwendungsbeispiel wär z.B., dass du aus ein und derselben XML Datei eine HTML Webseite, eine Flash-Webseite und einen gedruckten Katalog erstellen könntest. Natürlich kann man das nicht NUR mit XML...

[Seph]

Anwendungsbeispiel wär z.B., dass du aus ein und derselben XML Datei eine HTML Webseite, eine Flash-Webseite und einen gedruckten Katalog erstellen könntest. Natürlich kann man das nicht NUR mit XML...

Und wie genau funktioniert das?

Und weshalb werden HTML und XML beide als Auszeichnungssprachen bezeichnet, bzw. XML als eine Familie von Auszeichnungssprachen (XML-Dialekte), wenn es doch eigentlich gar nichts damit zu tun hat? Melde mich morgen nochmal detailierter zurück, aber danke schonmal für eure Bemühungen! :)

[Gast]

....

Anwendungsbeispiel wär z.B., dass du aus ein und derselben XML Datei eine HTML Webseite, eine Flash-Webseite und einen gedruckten Katalog erstellen könntest. Natürlich kann man das nicht NUR mit XML...

Sondern?

[Gast]

Was darph dir zu erklären versucht ist zwar höchst korrekt, aber imho etwas zu detailverliebt oder tiefgründig, um es als Neueinsteiger verstehen zu können.

Ich würde es etwas oberflächlicher machen:

Mithilfe vom XML kannst du eine Struktur beschreiben, in welcher Daten abgelegt werden können. Das beschreiben dieser Struktur ist der sprachliche Aspekt an der ganzen Sache, XML eben.

Hast du deine Struktur fertig geschrieben und willst Daten speichern, dann erstellst du eine XML-Datei, welche auf der entwickelten Struktur aufbaut. Diese XML-Datei kannst du mit jedem Text-Editor ansehen und bearbeiten, da wurde nichts kompiliert, verschlüsselt, komprimiert oder sonstwas, einfach nur Klartext.

Die meisten modernen Programmiersprachen haben nun schon von Haus aus Werkzeuge dabei, um solche Dateien zu parsen. Nicht ganz so abstrakt ausgdrückt, kannst du nun jede Information gezielt mit ein paar Anweisungen auslesen oder auch an eine spezielle Stelle schreiben, ohne selbst solch ein Parser/Werkzeug entwickeln zu müssen. Du musst dem Parser nur sagen, was du haben willst... die betroffenen Zeilen im XML-Dokument löschen, hinzufügen oder ändern tut er dann an der richtigen Stelle von selbst.
Zwar hast du dein eigenes Süppchen gekocht bei der Anordnung der Daten - solange diese Struktur aber XML-konform ist, interessiert das den Parser überhaupt nicht.

_Rein technisch_ betrachtet ist ein valides XHTML-Dokument gleichzeitig auch ein XML-Dokument! Das ist der Sinn der Sache.
ABER: die hier angesprochenen Unterschiede (also dass xml != xhtml) sind ja auch nicht technischer Natur, ich glaube das ist das, was du noch nicht recht verstehst.

[Monger]

Ehrlich gesagt finde ich die Diskussion sehr künstlich. Was XML genau ist, und wozu man es verwenden kann - das definiert sich jeder Anwender wieder neu.

Wie jede Form der Datenhaltung ist auch XML erstmal vollkommen kontextfrei. Die Interpretation der Daten hängt einzig und allein an der Applikation, die diese Daten liest.
Die eine Anwendung mag aus ein paar Zahlen eine Tabelle machen, eine andere macht daraus ein Balkendiagramm, und eine dritte vielleicht irgendein Koordinatennetz. XML ist nur eine Syntaxfestlegung, damit man mal zumindest weiß wo ein Element aufhört und wo es anfängt. Da herrschte vor XML nämlich ein ziemlich großes Durcheinander.

[RaumKraehe]

Also ich finde den Wiki-Artikel sehr gut geschrieben und äußerst verständlich. ;)


Die Extensible Markup Language (engl. für „erweiterbare Auszeichnungssprache“), abgekürzt XML, ist eine Auszeichnungssprache zur Darstellung hierarchisch strukturierter Daten in Form von Textdateien. XML wird u. a. für den Austausch von Daten zwischen Computersystemen eingesetzt, speziell über das Internet.[1]

Die vom World Wide Web Consortium (W3C) herausgegebene XML-Spezifikation (Recommendation, erste Ausgabe vom 10. Februar 1998, aktuell ist die vierte Ausgabe vom 29. September 2006) definiert eine Metasprache, auf deren Basis durch strukturelle und inhaltliche Einschränkungen anwendungsspezifische Sprachen definiert werden. Diese Einschränkungen werden durch Schemasprachen wie DTD oder XML-Schema ausgedrückt. Beispiele für XML-Sprachen sind: RSS, MathML, GraphML, XHTML, Scalable Vector Graphics, aber auch XML-Schema.

Ein XML-Dokument besteht aus Textzeichen, im einfachsten Fall ASCII, und ist damit „human-readable“ – Binärdaten enthält es per Definition nicht.


http://de.wikipedia.org/wiki/Extensible_Markup_Language

Tja, und mehr ist es auch nicht und für mehr habe ich es auch nie benutzt. :|

[Unfug]

Achtung jetzt komm ich ;D:

XML-Schema:
Das Schema ist wie eine Datenbank. Es definiert, was, wo und wieviel in einer richtigen XML-Datei stehen darf.
Beispiel:
Kundensammlung-Schema: (Name, Adresse, Email).

Dieses Schema können (also dieses Datenbankkonstrukt) wir an andere Firmen schicken, die uns dann ihre angepassten Daten zusenden:

Weiter im Beispiel:
Einwohnermeldeamt schickt uns folgende XML-Datei (namens UnserEinwohner.xml)
(Hansi, Oreganostraße 22, hansi@gmx.de)
(3dcfreak, freakstraße 22, 3dcfrea@gmx.de)
....

Wir können diese Daten ohne weiteres in unser Programm importieren, da wir vorher ja mit dem Schema festgelegt haben wie die Daten zu übertragen sind. Nämlich in dieser Form wie angegeben.


XML ist somit nichts anderes als etwas wie eine Datenbank (Schema) + Werte (XML-Dateien).

Jetzt gibt es noch sogennante Transformer, die deine XML-Dateien einfach in HTML, PDF oder sonstwas "transformieren" können. Das ist nichts anderes als wenn Du deine Datei ausliest, die Werte darin nimmst und sie zwischen <html> </html> packst. (Du musst also auch dem Transfomer ein Grundgerüst deiner Seite von HTML mitgeben)


p.s: Merk dir nicht die Art und Weise wie die Daten hier stehen im Post, denn das soll nur zur Veranschaulichung dienen ;-)

[Spasstiger]

XML ermöglicht es, Daten so zu speichern und auszutauschen, dass man sie auch ohne Kenntnisse über deren Herkunft in einen Kontext bringen kann.

Beispiel: Man will eine Tabelle und ein Schaubild mit einer Kurve speichern.

Erste Möglichkeit, Speicherung in Bitform:
Für die Tabelle legt man zunächst fest, wieviele Spalten und wieviele Zeilen sie hat und speichert diese Zahlen z.B. jeweils als 8 Bits. Danach folgt eine Ansammlung von Bits, welche ASCII-Zeichen und Trennbytes repräsentieren. Die Trennbytes legen fest, wann der Inhalt eines Tabellenfeldes fertig ist.
Das Schaubild speichert man, indem man zunächst festlegt, wieviele Punkte die Kurve enthält (z.B. als 16-Bit-Wert). Dann folgt z.B. ein 32 Bit breiter Wert, der den Wertebereich der x-Achse festlegt. Danach folgt ein 32-Bit breiter Wert, der den Wertebereich der y-Achse festlegt. Und anschließend folgen alle Wertepaare der zu speichernden Punkte. Z.B. könnte man festlegen, dass jedes Wertepaar in 64 Bit gespeichert wird.

Wenn man solche Dokument ohne Beschreibung vorfindet, kann man als Mensch erstmal gar nix damit anfangen. Es sind propietäre Dateiformate, die für einen bestimmten Zweck maßgeschneidert wurden.
Mit XML bekommt man beide Anwendungen unter einen Hut und das in einer für den Menschen lesbaren Form. Man kann problemlos das entsprechende Dokument mit den bereitsgestellten Informationen rekonstruieren.

<tabelle>
<zeile>
<feld>Hallo</feld>
<feld>Das ist ein Test</feld>
<feld>Adieu</feld>
</zeile>
<zeile>
<feld>bla</feld>
<feld>blub</feld>
<feld>...</feld>
</zeile>
</tabelle>

<schaubild>
<x_achse>
<von>0</von>
<bis>100</bis>
</x_achse>
<y_achse>
<von>-50</von>
<bis>200</bis>
</y_achse>
<punkt>
<x>1</x>
<y>4</y>
</punkt>
<punkt>
<x>2</x>
<y>3</y>
</punkt>
<punkt>
<x>3</x>
<y>7</y>
</punkt>
<punkt>
<x>4</x>
<y>6</y>
</punkt>
<schaubild>


Bei HTML ist schon vorne herein ein Syntax und eine Anwendung festgelegt, es bietet also nicht die Flexibilität von XML.

[Seph]

Gut, dass mit der Flexibilität hatte ich ja schon angesprochen. Aber mit welcher Begründung fallen dann sowohl HTML als auch XML in die Familie der "Auszeichnungssprachen", wenn sie letztlich doch recht verschieden sind? Das eine funktioniert irgendwie als Beschreibung auf einer übergeordneten Metaebene für verschiedene Ausgabeformate und man zeichnet nichts direkt aus, das andere ist ein "direktes Arbeiten" am Inhalt und für einen spezifischen Ausgabekanal.

Also HTML ist quasi wie der Handwerker, der die Kacheln verlegt und XML der Chef im Hintergrund, der das fertige Gesamtprojekt im Kopf hat und einen Plan aufstellt (beschreibt), bei dem alle möglichen Mitarbeiter ankommen können um die für sich relevanten Daten rauszuziehen und es entsprechend umzusetzen. So?

[Dr.Doom]

Gut, dass mit der Flexibilität hatte ich ja schon angesprochen. Aber mit welcher Begründung fallen dann sowohl HTML als auch XML in die Familie der "Auszeichnungssprachen", wenn sie letztlich doch recht verschieden sind? Das eine funktioniert irgendwie als Beschreibung auf einer übergeordneten Metaebene für verschiedene Ausgabeformate und man zeichnet nichts direkt aus, das andere ist ein "direktes Arbeiten" am Inhalt und für einen spezifischen Ausgabekanal.Jein. XML kannst du dir als einen Editor vorstellen, mit dem du Sprachen für Dokumente eigens definieren kannst.

Wenn du dir so eine Sprache definierst, also die Elemente vorgibst, die vorkommen dürfen in einem Dokument, das in dieser Sprache verfasst ist, dann hast du dir quasi ein eigenes irgendwasML kreiert.

(x)htML ist (rein oberfläch betrachtet) eine konkrete Ausprägung einer solchen Sprache, die definiert wie man Text o.ä. mit einem "Sinn" versieht.
Ein Browser versteht diese Sprache, weil er weiss, was mit den Tags und dem umschlossenen Text anzufangen ist <h1>überschrift</h1>.
Ein Browser ist schlicht ein Programm, dass HTML auswerten kann.

Mit XML kann ich mir eine doomML definieren, indem ich die Elemente, die diese Sprache spezifizieren in einer DTD- bzw Schema-Datei festhalte.
Diese doomML ist mit XML definiert, legt aber spezielle Tags für meine ML fest.
Ein Dokument verfasst in doomML hat dann einen bestimmten Zweck, für den mir jetzt kein sinnvolles Beispiel einfällt.

Also HTML ist quasi wie der Handwerker, der die Kacheln verlegt und XML der Chef im Hintergrund, der das fertige Gesamtprojekt im Kopf hat und einen Plan aufstellt (beschreibt), bei dem alle möglichen Mitarbeiter ankommen können um die für sich relevanten Daten rauszuziehen und es entsprechend umzusetzen. So?Nein, (x)HTML ist ein Klon, der aus einer XML-Klonfabrik spaziert. ;)
Horst der HTML-Klon
Malte der MathML-Klon
usw

[Coda]

XHTML ist eine Anwendung von XML, genauso wie SVG oder MathML.

Der eigentlich Vorteil von XML ist, dass man nicht für jede Sache wieder einen neuen Parser schreiben muss sondern einfach die vorgefertigten nimmt.

[frix]

Ich bin nun sicherlich kein XML experte möchte dir aber mal schildern wozu ich XML benutze.

Hab mir eine Webseite mit Flash aufgebaut. Der Inhalt und die Navigation der Flash seite wird mittels XML generiert. Dadurch ist sie sehr leicht und schnell zu pflegen.

hab z.B. für die navi mal vereinfacht folgende XML Struktur:

<navi>
<item name="about me" />
<item name="home" />
<item name="contact" />
</navi>


Flash liest nun die XML datei ein und erstellt je nach anzahl der items die menüpunkte und vergibt die passenden namen. So kann ich jederzeit weitere Navigationspunkte hinzufügen oder die namen ändern.

[Seph]

Könnte man dann XML als eine Art zusammenfassenden Begriff definieren, der alle Auszeichnungssprachen (XML-Dialekte) unter sich vereint?

[ScottManDeath]

XHTML ist eine Anwendung von XML, genauso wie SVG oder MathML.

Der eigentlich Vorteil von XML ist, dass man nicht für jede Sache wieder einen neuen Parser schreiben muss sondern einfach die vorgefertigten nimmt.

Jo. boost::archive::xml_oarchive FTW =) Ist praktisch wenn man fix ein Objekt auf Platte bannen will und man danach einfach mit notepad was aendern kann :)

[Gauß]

Das wichtigste was man über XML wissen muß, ist dass es zum Frickeleipfusch anstiftet und gigantische Ressourcen in der Welt sinnlos verplämpert hat.

[Marscel]

Das wichtigste was man über XML wissen muß, ist dass es zum Frickeleipfusch anstiftet und gigantische Ressourcen in der Welt sinnlos verplämpert hat.

Alternative? Ini-files?

[Gast]

XHTML ist eine Anwendung von XML, genauso wie SVG oder MathML.

Der eigentlich Vorteil von XML ist, dass man nicht für jede Sache wieder einen neuen Parser schreiben muss sondern einfach die vorgefertigten nimmt.

Genau, und mit XPath hat man für XML sogar eine Abfragesprache ähnlich SQL.

[Gauß]

Alternative? Ini-files?Wenn etwas komplexeres als eine simple Liste an Einstellungsschlüsseln gefragt ist, ist eine binäre Schnitstelle das einzigst sinnvolle.


"Das Internet ist so wahninnig erfolgreich gewesen, und dort wird HTML genutz. Also machen wir alles mit textbasierten Auszeichnungssprachen!"

So simpel ist die Basis des ganzen Irrwitzes!
Beängstigend viele machen sich absolut keinen Kopf mehr darüber.

[Coda]

Wenn etwas komplexeres als eine simple Liste an Einstellungsschlüsseln gefragt ist, ist eine binäre Schnitstelle das einzigst sinnvolle.
Begründung?

Beängstigend viele machen sich absolut keinen Kopf mehr darüber.
Ich mach mir darüber durchaus Gedanken, aber es geht einfach oft schneller ein XML-Framework zu verwenden anstatt eigene Dateiformate zu erzeugen. Für große Binärdaten würde ich auch nie XML verwenden.

[Pinoccio]

Das wichtigste was man über XML wissen muß, ist dass es zum Frickeleipfusch anstiftet und gigantische Ressourcen in der Welt sinnlos verplämpert hat.Exakt. Während früher alle Programmiere alle Binär-Formate auswendig kannten und sich kleinere Änderung im Pflichtenheftes eines Daten-Formats ganz einfach einpflegen ließen und es ein leichets war, eine fremde Datei zu verstehen und selbst in sein Programm zu importieren, so ist das alles wegen XML nicht mehr möglich. *hust*

Noch ein Beispiel für die Menschenlesbarkeit:
(Zur Probe einfahc mal in ein Textfile kopieren und mit nem Browser oder einer (geeigneten!)Bildbearbeitung öfffne)

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
id="svg2">
<circle cx="84" cy="84" r="23" style="stroke: blue; fill:none"/>
</svg>


Eine weitere Anwendungen ist QuakeML (https://quake.ethz.ch/quakeml/QuakeML).

Begründung?Trollalarm.

mfg

[Gauß]

Begründung?Weil es sonst keinen Sinn macht so etwas in Textform und in einer festgelegten Abstraktionssprache zu beschreiben und zu definieren.

Ich mach mir darüber durchaus Gedanken, aber es geht einfach oft schneller ein XML-Framework zu verwenden anstatt eigene Dateiformate zu erzeugen.Was es an API gebundener Abstraktion für XML Parser gibt, gibt es auch für Binärformate in schier unendlicher Breite.

Das wichtige aber ist, dass so eine absolute Abstraktion einfach keinen Sinn macht.
Je trivialer die Datenstrukturen sind, desto sinnvoller ist eine simple Ein-/Ausgabe.
Je komplexer die Datenstrukturen sind, desto sinvoller ist ein spezialisiertes Format.

Zudem ist die Textbasiertheit von XML ist in allen Belangen ein Nachteil.
Notargumente wie "Lesbarkeit" sind einfach Schwachsinn, da das Gegenteil die Wahrheit ist.

[Coda]

Was es an API gebundener Abstraktion für XML Parser gibt, gibt es auch für Binärformate in schier unendlicher Breite.
Aber nichts standardisiertes für das es garantiert auch in Jahren noch Libraries geben wird.

Und doch, XML ist deutlich menschenlesbarer als ein Binärformat, wenn man semantisch einigermaßen logisch vorgeht.

[DanMan]

Mensch Leute, nu machts ihm doch nicht so schwer. :)
Und wie genau funktioniert das?
Nun, das geht hier dann zu sehr ins Detail, aber kurz gesagt: das (X)HTML kriegst du über xsl, Flash kann XML verarbeiten und die Daten für den Katalog z.B. in der DTP Software (z.B. Indesign) importieren.
Sondern?
Die Daten müssen ja nicht als XML vorliegen, sondern könnten auch stinknormal als ASCII in einer Datenbank liegen.

[Monger]

Was es an API gebundener Abstraktion für XML Parser gibt, gibt es auch für Binärformate in schier unendlicher Breite.

Das ist genau das Problem: sich ein eigenes Datenformat auszudenken, ist überhaupt kein Problem. Das kann sogar ich. Und weil die schlecht standardisiert sind, sind sie auch schlecht dokumentiert. Deshalb haben wir auch Unmengen an Binärdaten die kein Schwein mehr verwenden kann. Das fängt schon bei so trivialen Dingen wie alten Office-Suiten an.

Dass XML nicht immer und überall Sinn macht, ist klar. Aber sobald es mal um die Frage geht, wie man seine Daten auch in kommenden Generationen noch lesbar macht, ist XML nahezu unschlagbar.

Vorallem in Kombination mit einem brauchbaren Kompressionsverfahren (Zip-Stream, z.B.) erhält man etwas, was schon eine Menge Vorteile vereint: geringer Speicherbedarf (das neue XML basierte Docx Format z.B. braucht weit weniger als sein binärer Vorgänger), Lesbarkeit, Interopabilität...

Binärströme sind nämlich auch auf jeder Plattform wieder ein bißchen anders, mitunter sogar durch Versionsunterschiede in der Verarbeitung zueinander inkompatibel. Ein Stream von Textzeichen ist auf jedem Betriebssystem und in jeder Umgebung immer noch ein Text.

[Gast]

Dass XML nicht immer und überall Sinn macht, ist klar. Aber sobald es mal um die Frage geht, wie man seine Daten auch in kommenden Generationen noch lesbar macht, ist XML nahezu unschlagbar.


Das ist leider der größte Trugschluss. Je nach Komplexität kann man auch bei XML Daten Bahnhof verstehen. Darüberhinaus kann man auch in XML binäre Daten über Base64 speichern, in denen man seine eigenen Daten geschickt verpackt. Wer Daten noch in kommenden Generationen lesen will, braucht in erster Linie ein klar dokumentiertes Format.

Die Stärken von XML liegen im Datenaustausch von unterschiedlichen Systemen (Windows <-> Unix; Java <-> .NET usw.) und nicht, dass man irgendwelche Dokumente noch in 20 Jahren lesen kann.
Es gibt aber viele Szenarien, da ist einfach Performance wichtig und nicht Interoperabilität.

[PHuV]

XML ist aus meiner Sicht im eigentlichen Ansatz kläglich gescheitert, eine abstrakte Datendarstellung als universales Übertragungs- und Austauschmedium zu schaffen. Mit XML muß man genau so, wie bei Flatfiles auch, die Abstraktionsebenen und Definitionen sehr gut kennen, um sie richtig anzuwenden. Die unabhängige Parsierbarkeit ist eine Mär, und das Aufblähen auf ein Vielfaches einer Flatdatei spricht für sich (Faktor 10-20).

Was vor allen Dingen grausam ist die Definition von Werten in Tags:

<xml>
wert
<g1>bla</g2>
</xml>

oder

<xml>
<g1>bla</g2>
wert
</xml>



Kein Witz, es ist gültiges XML. Was sich die Leut im W3C ham da einfallen lassen, ich verstehe es nicht. Für eine vernünftige Datenabstraktion sind solche Möglichkeiten einfach Gift. Weiterhin ist die Datenkonstistenzprüfung mit DTD ein einziger Krampf, überladen, und simple Dinge dagegen fehlen.

Ne, mit XML wurde aus meiner Sicht der Welt kein Gefallen getan.

[Monger]

Das ist leider der größte Trugschluss. Je nach Komplexität kann man auch bei XML Daten Bahnhof verstehen.

Klar, natürlich wird mit XML unglaublich viel Blödsinn getrieben. Natürlich wird es gehyped wie sonstwas - aber eben nicht vollkommen grundlos.


Es gibt aber viele Szenarien, da ist einfach Performance wichtig und nicht Interoperabilität.
Wenn du Daten persistierst, ist dein Flaschenhals niemals die CPU. Da hast du auch locker noch die Zeit, den Datenstrom zwischendrin mal zu zippen. Und wenn du Gigabyte für Gigabyte an XML Daten auf die Festplatte müllst, hast du ohnehin ein architekturelles Problem.

Natürlich ist XML nicht für alles geeignet. Für große Datenmengen, die sich regelmäßig ändern, sind Datenbanken die interessantere Wahl. Die aber - oh Wunder! - nunmal ihre Kommunikation auch größtenteils über Klartext abwickeln.
Binärformate sind in der Anwendungsentwicklung (zum Glück!) auf dem Rückzug.

[Gast]

Wenn du Daten persistierst, ist dein Flaschenhals niemals die CPU. Da hast du auch locker noch die Zeit, den Datenstrom zwischendrin mal zu zippen. Und wenn du Gigabyte für Gigabyte an XML Daten auf die Festplatte müllst, hast du ohnehin ein architekturelles Problem.


Performance hat auch nicht zwangsweise etwas mit CPU Leistung zu tun, sondern zb. auch Netzwerkbandbreite und Latenzen. Wenn es nicht notwendig ist, würde ich z.B. beim Datenaustausch niemals Web Services verwenden und stattdessen lieber ein binäres Remoting.

Und wenn du die XML Daten komprimierst setzt das voraus, dass der Konsument damit umgehen kann. Eher unwahrscheinlich, dass dies die Regel ist.


Natürlich ist XML nicht für alles geeignet. Für große Datenmengen, die sich regelmäßig ändern, sind Datenbanken die interessantere Wahl.


Wenn du die Daten alle selbst kontrollieren kannst. Auf dem Desktop eher unvorstellbar. WinFS wäre ein guter Ansatz gewesen.


Die aber - oh Wunder! - nunmal ihre Kommunikation auch größtenteils über Klartext abwickeln.


Das wäre mir vollkommen neu. Außerdem geht es hier nicht um Klartext, denn CSV, ini Dateien usw. sind auch alles Klartext. Es geht darum, dass XML eine Menge Overhead mitbringt.

[Pinoccio]

Zudem ist die Textbasiertheit von XML ist in allen Belangen ein Nachteil.
Notargumente wie "Lesbarkeit" sind einfach Schwachsinn, da das Gegenteil die Wahrheit ist.Ernsthaft?
Ich habe quasi beruflich mit seismologischen Daten zu tun, dafür gibt es einen schönen Standrad, den "Standard for the Exchange of Earthquake Data". Die Beschreibung ist als PDF (http://www.iris.edu/manuals/SEEDManual_V2.4.pdf) 214 Seiten dick. Das ganze ist enorm kompliziert aufgebaut, weil man versucht hat, einfach alle möglichen Belange und Sonderfälle einzuarbeiten. Diese Komplexität führt dazu, daß es genau eine Software (http://www.iris.edu/software/downloads/seed_tools/) (Jrdseed zählt nicht, da nicht final) gibt, die das ganze liest und in andere Formate (GSE (http://www.seismo.ethz.ch/autodrm/autodrm_doc.html), SAC (http://www.passcal.nmt.edu/software/sac.html) usw.) umwandelt. Niemand macht sich (freiwillig) die Arbeit, einen eigenen Parser zu schrieben. Aber der normale Workflow besteht darin, als allererstes aus diesem Format wegzukonvertieren in brauchbarere Formate, die eine große Vielzahl von Programmen versteht (z.B. der SH).
Hatte ich schon erwähnt, das der einzige verfügbare Parser auch Bugs hat?

Wäre das ganze ein XML-Format, könnte ich ganz einfach mit den fertigen XML-Parser-Bibliotheken in der Sprache meiner Wahl und auf der Maschine meiner Wahl die mich interessierenden Daten (d.h. Inhalte) rausziehen. Das wäre schneller und einfacher.

Die oben von mir schonmal als Beispiel angeführte QuakeML ist da aus meiner Sicht ein sehr vernünftiger Schritt.

(Das ist meine (z.T. frustierenden) Erfahrung, möglicherwiese(bzw. hoffentlich :wink:) machst du andere ...)

mfg

[Besserwissend]

Was vor allen Dingen grausam ist die Definition von Werten in Tags:

<xml>
wert
<g1>bla</g2>
</xml>

oder

<xml>
<g1>bla</g2>
wert
</xml>



Kein Witz, es ist gültiges XML. Was sich die Leut im W3C ham da einfallen lassen, ich verstehe es nicht. Für eine vernünftige Datenabstraktion sind solche Möglichkeiten einfach Gift...

Wo ist das Problem? Dann definier Dein Format doch halt anders???
Für so etwas ist das ganz gut geeignet:

<xml>
Das ist ein wichtiges <important>Wort</important>. Hier steht anderer Text.
</xml>



Performance hat auch nicht zwangsweise etwas mit CPU Leistung zu tun, sondern zb. auch Netzwerkbandbreite und Latenzen. Wenn es nicht notwendig ist, würde ich z.B. beim Datenaustausch niemals Web Services verwenden und stattdessen lieber ein binäres Remoting.

Das wäre mir vollkommen neu. Außerdem geht es hier nicht um Klartext, denn CSV, ini Dateien usw. sind auch alles Klartext. Es geht darum, dass XML eine Menge Overhead mitbringt.

Schau mal hier:

http://www.w3.org/XML/EXI/
http://www.w3.org/TR/2008/WD-exi-20080326/

[The_Invisible]

wieso wird hier performance und webservices in einem wort erwähnt?

das größte problem ist hier immer noch die latenz. ob bei den heutigen leitungen ein paar kb mehr versendet werden ist eh schon egal, außerdem gibts eh noch json.

mfg

[Monger]

Performance hat auch nicht zwangsweise etwas mit CPU Leistung zu tun, sondern zb. auch Netzwerkbandbreite und Latenzen. Wenn es nicht notwendig ist, würde ich z.B. beim Datenaustausch niemals Web Services verwenden und stattdessen lieber ein binäres Remoting.

Über was für Anwendungen reden wir hier eigentlich?

Performance-intensive Aufgaben sind ja die Ausnahme, nicht die Regel. Wenn du bei Übertragungen mit ein paar kB Erweiterbarkeit und Robustheit für ein Quentchen Performance opferst, gehörst du zu Recht geohrfeigt.


Und wenn du die XML Daten komprimierst setzt das voraus, dass der Konsument damit umgehen kann. Eher unwahrscheinlich, dass dies die Regel ist.

Zip kann jeder. Das ist mittlerweile sogar in vielen Standardframeworks drin.


Das wäre mir vollkommen neu. Außerdem geht es hier nicht um Klartext, denn CSV, ini Dateien usw. sind auch alles Klartext. Es geht darum, dass XML eine Menge Overhead mitbringt.
Das kommt nunmal auf die Implementierung an. Die meisten Datenstrukturen tragen den Großteil ihrer Informationen nunmal in der Struktur selber, und nicht so sehr in den Endknoten. Das spiegelt sich logischerweise in XML dann auch wieder.

Mit CSV, ini etc. hast du nunmal schlicht keine Chance, ähnliche Strukturen wie mit XML aufzubauen.

[Gast]

Performance-intensive Aufgaben sind ja die Ausnahme, nicht die Regel. Wenn du bei Übertragungen mit ein paar kB Erweiterbarkeit und Robustheit für ein Quentchen Performance opferst, gehörst du zu Recht geohrfeigt.


Dir fehlt anscheinend schlicht die Erfahrung welche Anwendungsbereiche es alles gibt.

[Bietchiebatchie]

Bullshit, Monger hat vollkommen recht, wenn er behauptet, dass im Businessbereich cpu-performancekritische Anwendungen die Ausnahme sind. Denn
a) haben wir mittlerweile extrem mächtige Rechner, die sich cpu-technisch gesehen die meiste Zeit nur langweilen.
b) ist IO in 95% der Fälle der Performancekiller und nicht die CPU.
c) pro xml überall da, wo es Sinn macht. Und das ist in sehr vielen Fällen der Fall. (Ich hab schon xml-Dateien mit mehreren Gigabytes bearbeitet und war froh das es kein Binärformat war - lieber ein, zwei Minuten länger beim Einlesen warten als drei, vier Stunden den Binärparser debuggen)

[PHuV]

Wo ist das Problem? Dann definier Dein Format doch halt anders???
Für so etwas ist das ganz gut geeignet:

<xml>
Das ist ein wichtiges <important>Wort</important>. Hier steht anderer Text.
</xml>



Daran merkt man, daß Du von Datenformaten keine Ahnung hast, und wer sich so was aufbaut, gehört gevierteilt und gerädert. :rolleyes: BTW habe ich diesem Mist mal für einen eigenen geschriebenen XML-Parser anpassen müssen, daß hat mir gereicht.

[PHuV]

(Ich hab schon xml-Dateien mit mehreren Gigabytes bearbeitet und war froh das es kein Binärformat war - lieber ein, zwei Minuten länger beim Einlesen warten als drei, vier Stunden den Binärparser debuggen)

Wie und wo :eek:. Das will ich sehen. Wir haben interne Tests mit diversen Parsern gemacht, da knallten alle Parser schon nach 2-5 MB, je nach Verschachtelungstiefe, auf einem 32-Bit System (Win XP mit 2 GB Hauptspeicher). Die meisten Parsern müssen doch daraus immer eine intern aufwendige Struktur in Form von DOM. XOM, DOM4J aufblähen, was sehr schnell zu großem Bedarf an Hauptspeicher führt. Gut, ich bin mittlerweile seit fast 2 Jahren da draußen, vielleicht hat sich hier mittlerweile was bewegt.

[Shink]

Ich finds ja schön dass immer jeder meint er müsse einen XML-Parser basteln. Aber wenn man damit dem Standard nicht entspricht soll man sich nicht über ihn aufregen.

[Coda]

Daran merkt man, daß Du von Datenformaten keine Ahnung hast, und wer sich so was aufbaut, gehört gevierteilt und gerädert. :rolleyes: BTW habe ich diesem Mist mal für einen eigenen geschriebenen XML-Parser anpassen müssen, daß hat mir gereicht.
Was ist daran denn so schlimm?

[Ganon]

Wir haben interne Tests mit diversen Parsern gemacht, da knallten alle Parser schon nach 2-5 MB, je nach Verschachtelungstiefe, auf einem 32-Bit System (Win XP mit 2 GB Hauptspeicher).

Hmmm... also ich habe schon 100 MB XML-Dateien ausgelesen/bearbeitet und hatte dabei keine Probleme... 32bit, XP, 1024MB RAM....

[Shink]

Wie und wo :eek:. Das will ich sehen. Wir haben interne Tests mit diversen Parsern gemacht, da knallten alle Parser schon nach 2-5 MB, je nach Verschachtelungstiefe, auf einem 32-Bit System (Win XP mit 2 GB Hauptspeicher). Die meisten Parsern müssen doch daraus immer eine intern aufwendige Struktur in Form von DOM. XOM, DOM4J aufblähen, was sehr schnell zu großem Bedarf an Hauptspeicher führt. Gut, ich bin mittlerweile seit fast 2 Jahren da draußen, vielleicht hat sich hier mittlerweile was bewegt.
Der Standard-Java XML Parser SAX muss da z.B. gar nichts persistent halten. Hab aber auch schon mit JDOM auf diversen Plattformen XMLs mit Größen zwischen 10 und 100MB verarbeitet.

[Besserwissend]

Daran merkt man, daß Du von Datenformaten keine Ahnung hast, und wer sich so was aufbaut, gehört gevierteilt und gerädert. :rolleyes: BTW habe ich diesem Mist mal für einen eigenen geschriebenen XML-Parser anpassen müssen, daß hat mir gereicht.

Uiuiui. Harte Worte. Ich sag nur "Anwendungszweck": (La)TeX macht so etwas (auch ne Auszeichnungssprache), (X)-HTML macht so etwas, XSL-FO macht so etwas und ICH mach so was - und finde es gut so!
Also haben der Knuth/Lamport, der Goldfarb alle von der W3C und ICH ;D also keine Ahnung von Datenformaten? Bitte sachlich bleiben!
Wenn Du jemandem vorwirfst er hätte keine Ahnung von "Datenformaten", dann bitte bitte bitte begründe das auch damit alle etwas lernen können.


Du weisst schon das, wenn man dieses XML-Beispiel verabeitet (parsed) z.B. mit XPATH etc. dann sind die nicht ausgezeichneten Knoten eigentlich auch ausgezeichnet:

Wurzel
Hauptknoten -> xml
Textknoten -> "Das ist ein wichtiges "
Markupknoten(important) -> "Wort"
Textknoten ->. Hier steht anderer Text.


Btw. Wozu schreibt einen eigenen XML-Parser? Da gibts doch Auswahl bis zum geht nicht mehr von MiniXML bis zu Schema-aware XSLT-Prozessor- Monsterparser.
Man muss keinen Parser für irgend ein XML-Format selber schreiben. NIEMALS - auch für das von mir angegebene Beispiel nicht!

[PHuV]

Also haben der Knuth/Lamport, der Goldfarb alle von der W3C und ICH ;D also keine Ahnung von Datenformaten? Bitte sachlich bleiben!
Wenn Du jemandem vorwirfst er hätte keine Ahnung von "Datenformaten", dann bitte bitte bitte begründe das auch damit alle etwas lernen können.


Nö, lerns selber. Es gibt schließlich noch diverse andere Datenformate, wenn ich da alleine an den EDI-Bereich denke, von den ganzen Applikationsdaten ganz zu schweigen.


Du weisst schon das, wenn man dieses XML-Beispiel verabeitet (parsed) z.B. mit XPATH etc. dann sind die nicht ausgezeichneten Knoten eigentlich auch ausgezeichnet:

Wurzel
Hauptknoten -> xml
Textknoten -> "Das ist ein wichtiges "
Markupknoten(important) -> "Wort"
Textknoten ->. Hier steht anderer Text.



Wo mach so ein Konstrukt Sinn? Wenn man einer Gruppe einen Wert geben will, gibt es Attribute. Als zu was dann separat nochmals für eine Gruppe (oder Hauptknoten) einen Wert zuweisen? Beim Austausch von Informationen jeglicher Art ist so eine Konstruktion sehr kontraproduktiv, da hier eine Mehrdeutigkeit geschaffen wird, die ohne Strukturbeschreibung selbst gar nicht auflösbar ist. Aber gerade diesen Anspruch hat ja XML, und mit dieser Möglichkeit ist wieder die alte Problematik der Mehrdeutigkeit reingekommen. Für eine Formatierungssprache wie HTML oder meinetwegen auch auch TeX mag es in Ordnung sein, weil es diese Fälle der Verwendbarkeit gibt, aber für Datenstrukturen bzw. Dateibeschreibungen zum Austausch von Informationen ist das tödlich.

Nehmen wir doch mal mein Beispiel:


<xml>
wem gehört
<tag>bla</bla>
diese info
</xml>


Nehmen wir an, Du hast keine Strukturbeschreibung in Form einer DTD was was ich, kannst Du "wem gehört" und "diese Info" nichts zuordnen. Sind das nun Infos für xml, oder für bla, und was gehört wem? Stell Dir mal vor, diese Werte wären Mengenangaben oder Datumsfelder, und schon hast Du den Salat. Klar, könnte man jetzt argumentieren, das wäre doch durch saubere Strukturierung kein Problem. Dann schauen wir mal in die Praxis, da werden oft Laien hingesetzt, die dann ein Austauschformat definieren sollen, und wenden dann natürlich alle möglichen Schweinereien an, die dann keiner der Partner (denen man natürlich das Format aufdrücken kann, da man mächtiger,größer etc. ist) ohne Schwierigkeiten verarbeiten kann, und man nur mit viel Trickserei und mehrstufiger Verarbeitung lösen kann, wenn man dieses Format in andere überführen will.

Und da ich die ersten Schritte mit XML in diversen Firmen direkt mitbekommen habe, genau das passiert ständig. Das W3C hat sich auch gerade mit der Normierung überhaupt nicht mit Ruhm bekleckert, oder warum glaubst Du, daß das W3C vom vielen sehr kritisiert wurde und sogar einige ausgestiegen sind (ich nenne da mal Björn Höhrmann (http://aktuell.de.selfhtml.org/weblog/zukunft-von-html), Andy Clarke (http://www.stuffandnonsense.co.uk/malarkey/more/css_unworking_group/), nur um mal einige zu nennen). Viele Anfragen Probleme (von der damaligen Firma, in der ich arbeitet), die wir an das W3C richteten, wurden gar nicht beantwortet, oder immer auf später verwiesen.


Btw. Wozu schreibt einen eigenen XML-Parser? Da gibts doch Auswahl bis zum geht nicht mehr von MiniXML bis zu Schema-aware XSLT-Prozessor- Monsterparser.
Man muss keinen Parser für irgend ein XML-Format selber schreiben. NIEMALS - auch für das von mir angegebene Beispiel nicht!

Sorry, das ich mich wiederhole, man sieht wirklich, daß Du in gewissen Bereichen keine Ahnung hast. :rolleyes: Was ist mit eigenen Applikationen, die XML-fähig gemacht werden müssen, und in denen kein herkömmlicher XML-Parser integriert werden kann. Was ist mit Umgebungen, die nur einen eigenen Parser anbieten, der eingeschränkt arbeitet (ich nenne da mal die SAP-XI Anbindungen in der ersten Ausprägung. Die Welt ist nun mal nicht immer Windows, gelle ;) . Und es gibt durchaus Unterschiede in den Parsierungsergebnissen, was auch nicht gerade lustig ist. :(

[PHuV]

Hmmm... also ich habe schon 100 MB XML-Dateien ausgelesen/bearbeitet und hatte dabei keine Probleme... 32bit, XP, 1024MB RAM....

Dann versuche das Ding mal mit XSLT in ein anderes Format zu bringen, vor allen Dingen, wenn das andere Format eine ganz andere Strukturlogik hat. Viel Spaß ;). Ich rede jetzt nicht von einer simplen seriellen Verarbeitung, das ist sicherlich kein Problem. Es wird in dem Moment ein Problem, wo man intern große Strukturen aufbauen muß, um auf alle Elemente innerhalb der Knoten zugreifen zu können. Wie gesagt, ich bin hier mittlerweile 2 Jahre wieder raus, was sich da mittlerweile getan hat, weiß ich nicht.

[Gast]

Wo mach so ein Konstrukt Sinn? Wenn man einer Gruppe einen Wert geben will, gibt es Attribute. Als zu was dann separat nochmals für eine Gruppe (oder Hauptknoten) einen Wert zuweisen? Beim Austausch von Informationen jeglicher Art ist so eine Konstruktion sehr kontraproduktiv, da hier eine Mehrdeutigkeit geschaffen wird, die ohne Strukturbeschreibung selbst gar nicht auflösbar ist. Aber gerade diesen Anspruch hat ja XML, und mit dieser Möglichkeit ist wieder die alte Problematik der Mehrdeutigkeit reingekommen. Für eine Formatierungssprache wie HTML oder meinetwegen auch auch TeX mag es in Ordnung sein, weil es diese Fälle der Verwendbarkeit gibt, aber für Datenstrukturen bzw. Dateibeschreibungen zum Austausch von Informationen ist das tödlich.

Na und? Nur weil die XML-Empfehlung das zuläßt heißt das noch lange nicht das man das auch benutzen muss (Das ist übrigens mit allen Normen und Empfehlungen so)
Wie man z.B. an den Formatbeschreibungs-Dateiformaten sieht, gibt es dafür einen nicht gerade kleinen Anwendungsbereich (Desktop, Webpublishing etc.)
Du kannst XML auch auf andere Art missbrauchen in dem Du z.B. jeden Müll auszeichnest anstatt beispielsweise CDATA-Abschnitte o.ä. zu benutzten oder 50 Elementknoten in der gleichen Ebene mit dem selben Identifier nutzt.
MISSBRAUCH, FEHLNUTZUNG ETC. IST KEIN ARGUMENT!!!




Und da ich die ersten Schritte mit XML in diversen Firmen direkt mitbekommen habe, genau das passiert ständig. Das W3C hat sich auch gerade mit der Normierung überhaupt nicht mit Ruhm bekleckert, oder warum glaubst Du, daß das W3C vom vielen sehr kritisiert wurde und sogar einige ausgestiegen sind (ich nenne da mal Björn Höhrmann (http://aktuell.de.selfhtml.org/weblog/zukunft-von-html), Andy Clarke (http://www.stuffandnonsense.co.uk/malarkey/more/css_unworking_group/), nur um mal einige zu nennen). Viele Anfragen Probleme (von der damaligen Firma, in der ich arbeitet), die wir an das W3C richteten, wurden gar nicht beantwortet, oder immer auf später verwiesen.


bischen Offtopic:
Die W3C erstellt keine Normen (das kann und darf sie nicht), sie gibt Empfehlungen!!!
Ich selbst habe viel mit VoiceXML/CCXML zu tun und ich kann mich über mangelnde Resonanz nicht beschweren! Ich denke aber es hängt auch von der jeweiligen Working Group ab. Insbesondere bei so wichtigen Dingen wie (X)-HTML und CSS will jeder seinen Senf dazugeben, da schaltet man halt auf Durchzug.



Sorry, das ich mich wiederhole, man sieht wirklich, daß Du in gewissen Bereichen keine Ahnung hast. :rolleyes:

Diese Sätze bitte ich zu unterlassen oder mit _ARGUMENTEN_ zu unterlegen. Das klingt nämlich persönlich.


Was ist mit eigenen Applikationen, die XML-fähig gemacht werden müssen, und in denen kein herkömmlicher XML-Parser integriert werden kann. Was ist mit Umgebungen, die nur einen eigenen Parser anbieten, der eingeschränkt arbeitet (ich nenne da mal die SAP-XI Anbindungen in der ersten Ausprägung.


XML ist eine eine Metasyntax. Domainspezifische Auszeichnungssprachen müssen dieser Metasyntax gehorchen. Applikationen/Bibliotheken, die mit dieser Metasyntax umgehen können, können ALLE Sprachen dieser Metasyntax handhaben. Ausnahmslos.
Wenn in die eigene Applikation kein "herkömmlicher" XML-Parser integriert werden kann, dann ist sie schlecht designt - Schließlich handelt es sich um simple I/O die man normalerweise abstrahiert.


Was ist mit Umgebungen, die nur einen eigenen Parser anbieten, der eingeschränkt arbeitet (ich nenne da mal die SAP-XI Anbindungen in der ersten Ausprägung.

"Eingeschränkte" XML-Parser? Heute?
Ich glaube kaum, das dafür irgendjemand Geld bezahlt!




. Und es gibt durchaus Unterschiede in den Parsierungsergebnissen, was auch nicht gerade lustig ist. :(
Beispiel?

[Gauß]

Aber nichts standardisiertes für das es garantiert auch in Jahren noch Libraries geben wird.Das ist kein Argument dafür, dass eine textbasierte Selbstauszeichnung der Daten sinnvoll ist.

Und doch, XML ist deutlich menschenlesbarer als ein Binärformat, wenn man semantisch einigermaßen logisch vorgeht.Eine direkte Formatdokumentation kann man in der Lesbarkeit und Klarheit nicht schlagen.

[Darkstar]

Eine direkte Formatdokumentation kann man in der Lesbarkeit und Klarheit nicht schlagen.So wie diese hier? :D

http://fanaticattack.com/wp-content/uploads/2007/12/ooxml.jpg