Unterschiede (Vor- und Nachteile) vom XML gegenüber Ini-Dateien

[c.rackwitz]

DEvent:
steve yegge spaltet. die einen wehren sich gegen seine sichtweisen, die anderen nicht. wenn du nicht aufgeschlossen an seine blogs rangehst, kannst du auch nichts gewinnen. dein verlust.

minhen:
ich moechte hier mal einen theoretischen regulaeren ausdruck darstellen:

([^<]+|<(\w+)>($$)</\2>)*

$ist die selbstreferenz auf den regex selbst. nur weil ich diese notation der rekursion eingefuehrt habe, kann ich wirklich rekursive eingaben parsen. mit backrefs allein geht das nicht. pars mir doch mal das (spaces zur lesbarkeit): ``` <foo></foo> <foo></foo> <foo></foo> <foo> <foo> <foo></foo> </foo> </foo> <foo> <foo> <foo><foo></foo></foo> <foo></foo> </foo> <foo> <foo></foo> <foo></foo> </foo> </foo> ``` wenn du diesem beispiel nicht glaubst, lies die fachliteratur. da stehts lang und breit.$

[rüdiger]

minhen schrieb:

rüdiger schrieb:

@minhen
Warum ist YAML die einzige alternative? Warum fährt man "sicherer" mit XML? Welche Infrastruktur meinst du?

Na schau dir doch mal die von dir genannten Alternativen an. Bei XML habe ich XML als Kern-Technologie, die einfach zu implementieren und gut zu handhaben ist.

Nein, ist es nicht. Attribute allein sorgen dafür, das man keine Sinnvolle Datenstruktur haben kann.

minhen schrieb:

Und für ein und die selbe Sache gibt es entgegen deiner Behauptung auch nicht verschiedene Spezifikationen.

Gut, dann nehmen wir zB mal Validierung hier als Thema. Da gibt es DTD, Xml-Schemas (ist das eigentlich schon 1.0 oder wird das immer noch alle paar Monate geändert?), Relax, Relax-NG, Schematron etc.

Aber es gibt gut ausgearbeitete Spezifikationen. Daran scheitern schon die meisten deiner "Alternativen". Ganz davon abgesehen, dass YAML, OGDL, noch nicht einmal stabile und finale Spezifikationen besitzen. Die Spezifikation von XML ist schon seit Jahren endgültig und entsprechend gut umgesetzt und verbreitet. Was du über XML sagst ist durch deine Alternativen geradezu absurd. Im Gegensatz zu diesen ist XML auch ein endgültiger, internationaler Standard. Das garantiert dir dann doch deutlich mehr Zukunftssicherheit als das, was eine Mailing-List als Arbeitsentwurf für eine Spezifikation (-> YAML) zusammengeschustert hat.

Es kommt eben auf das Einsatzgebiet an. Will ich einen Weg um Textdaten zwischen meine Anwendungen auszutauschen, dann ist das doch aussreichend. Ich nehm YAML oder OGDL oder wer weiß was für eine Alternative und nehm deren Parser und fertig. Ob es dann eine Version 1.1 oder 2.0 gibt, die dazu inkompatibel ist, interessiert mich ja nicht, so lange der Parser und die Spec die ich benutze für meinen Einsatz in Ordnung ist.

[quote]Von der Infrastruktur will ich eigentlich gar nicht erst anfangen. Wenn ich mag, kann ich XML-Dateien beliebig bündeln und zusammenwürfeln (Namensräume),/[quote]

ich kann XML-Dokumente von einem Format in ein anderes transformieren (XSLT),

Wo soll zB der Sinn von XSLT liegen? Wenn ich XML von A nach B umwandeln will, nehm ich eh Ruby oder Perl oder was weiß ich. Ich dachte eigentlich, das XSLT toll sei, weil man dann einfach Daten (eben als XML) und das Stylesheet (eben XSLT) an eine Anwendung weiterreicht, die einem nicht vertrauen muss (also zB Browser oder RSS-Reader) und die tranformieren sich dann aus den Daten mittels des entsprechenden Styleseehts ihre das was sie brauchen und verstehen (wenn der Client zB RSS lesen kann, nimmt er RSS, wenn er XHTML kann, nimmt er XHTML und wenn er PDF kann, nimmt er PDF etc). Aber puste Kuchen. Bei den Browsern ist XSLT nicht weit genug verbreitet. IE4/5 behandeln das nicht standard konform, die meisten Exoten können es nicht (zB Opera, Dillo und Textbrowser). Ich glaub IE6 und Firefox sind die einzigen die das können. Bei RSS-Readern sieht es ganz mau aus etc. Also der einzige sinnvolle Einsatzzweck wird eben durch die übliche Inkompatibilitätsholle nutzlos gemacht. (Wow, jetzt werden wir komplett OT ;))

ich kann ihnen eine eigenständige optische Erscheinung geben (CSS, XSL-FO),

Gibt es für XSL-FO eigentlich schon sinnvolle Darstellungsmöglichkeiten? Das letzte was ich davon gehört habe war, dass es absoluter Accessibility-Gift ist. CSS ist zwar ein guter Ansatz, aber XML+CSS ist in Browsern wohl auch problematisch (zumindest der IE hatte damit Probleme. Mozilla Browser können das wohl gut. Wie das bei den Exoten aussieht möchte ich gar nicht wissen).

ich kann eindeutige Verweise auf sehr einfache Weise innerhalb der Dokumente verwenden (id, xml:id), ich kann auch eindeutige Verweise auf externe Dokumente setzen (XLink), ich kann bestimmte Bereiche der Dokumente adressieren (XPath),

XPath ist auch eine viel zu komplexe Spec. Zumindest hatte ich immer Probleme mit Parsern die meine XPath-Ausdrück nicht richtig umsetzen konnten (sowohl in PHP, Ruby, C++ und Common Lisp hatte ich damit Probleme). (Allein die Tatsache, dass die bei 1 anfangen zu zählen finde ich schon grausam) Moral von der Geschichte war, das ich mir für Common Lisp ein eigenes XPath gebastelt habe, was S-Exps auf S-XML matcht (und wenn man sich so was schreibt merkt man erst einmal, wie kaputt die Umsetzung von XML Datenstrukturen sind, durch die Attribute).

ich kann große XML-Dokumente als Datenbank sehen (XQuery),

Vielleicht in 2 Jahren. XQuery ist seit einem Monat erst in einer finalen Version draussen und als ich das letzte mal nach einer XQuery Implementierung geguckt habe, gab es glaube ich für Java irgend eine liegen gelassene Alpha-Implementierung und hier und da eher Konzeptionelle Ansätze. Wobei genauere Blicke auf XQuery das Konzept eh sehr fragwürdig aussehen lassen. Da reicht XPath und der Rest in der Programmiersprache die man gerade verwendet...

ich kann die Struktur von XML-Dokumenten eindeutig definieren - für Konfigurationsdateien ist hier auch die Definition von Default-Werten ziemlich interessant - (DTD, XML Schema) und vor allem kann ich XML-Dokumente als Objekte in meinen Programmen verwenden (DOM).

XML Schema ist viel zu komplex und das letzte mal das ich damit gespielt habe war es praktisch nicht einsetzbar, da Validierungen viel zu lange gedauert haben.

All diese Technologien sind zusätzliche Möglichkeiten. Die Kerntechnologie XML wird dadurch in keinster Weise eingeschränkt. Ich kann diese Möglichkeiten nutzen, wenn sie mir sinnvoll erscheinen, und ich kann sie schlicht ignorieren und nicht verwenden wenn ich sie nicht brauche. Das gilt sowohl für die reine Anwenderseite als auch für das Entwickeln von Parsern. Ein Parser muss keine der genannten zusätzlichen Techniken unterstützen. Einzige Ausnahmen sind ein Teil der DTDs und die IDs, welche zum XML-Kern gehören. Wie am Beispiel der Namensräume schon ausgeführt, die zusätzlichen Möglichkeiten zerstören in keinster Weise die Interoperabilität als XML. Wie ebenfalls schon gesagt: der Kram ist eben gut durchdacht. Und zwar auch so weit, dass die jeweiligen Spezifikationen die Bereich sehr gut definieren. Die Sachen sind absolut eindeutig definiert. Da gibt's keine Unsicherheiten und kein Rätselraten. Die XML-Spezifikation gibt sogar Algorithmen an, die ich als Parserbauer nur abzutippen brauche.

Bei den meisten dieser Techniken erschließt sich kein Sinn (also auch kein Nutzen), es mangelt an Implementierungen, sie sind zu ineffizient per Definition oder sie bringen mir nichts, was ich mit einem kleinen Script nicht schneller, besser und flexibler machen kann.

Wie sieht's bei deinen "Alternativen" aus? Sind die ebenfalls so durchdacht und wohl definiert? Sind sie ebenfalls so offen und erweiterbar, was die Möglichkeiten angeht? (Antwort ist beide Male nein, hab mir die Spezifikationen angesehen)

kA ich kenn die YAML Spec nicht und das ist wohl das worauf du dich beziehst.

Das ist aber noch nicht einmal das, was ich mit Infrastruktur meine. XML ist purer Text, im schlimmsten Fall reicht also ein billig einfacher Texteditor bereits für die Arbeit mit XML aus.

Was auch für die Alternativen gilt.

Im weniger schlimmen Fall ein moderner Browser. XML, DOM, XSLT, XPath, CSS wird zum Beispiel von diesen Browsern unterstützt.

Wobei die Browser alles ein klein bisschen anders machen. So scheint es mir zumindest. Aber vielleicht findest du es ja leicht die ganzen XML-Sachen so hinzubekommen, das sie ohne Probleme zwischen 3 Browsern mit unterschiedlichen Renderern funktionieren.

Natürlich gibt es noch unzählige weitere Programme und Editoren für die Arbeit mit XML. Infrastruktur eben. Aber auch ganz normale Programme arbeiten mit XML ob es jetzt ein Microsoft Word oder meine MySQL-Datenbank ist, beide exportieren und importieren vergnügt XML.

Das ist ein Vorteil von XML oder was heißt Vorteil. Ist man mit solchen Programmen in Kontakt, nimmt man eben XML. Will man einem Browser etwas geben, nehm ich eben XML. Ich sag ja gar nicht "nie XML". Ich sage nur "nie XML einführen, wo man auch ohne XML auskommt".

Solche Dinge machen einem das Leben natürlich schon angenehmer. Das wichtigste Argument für einen Entwickler dürfte aber die Unterstützung bei der Programmiersprache seiner Wahl sein. Und da ist XML eben auch unschlagbar. Parser für XML gibt es unzählige, einige davon auch mit Unterstützung der anfangs genannten zusätzlichen Möglichkeiten. Ein internationaler Standard eben. Von einer solchen Unterstützung wie ich es bei der Entwicklung von XML von allen Seiten bekomme, kann man bei deinen Alternativen nur träumen. Bei denen ist es bereits ein absoluter Glücksfall, wenn es überhaupt einen Parser für die gewünschte Sprache gibt.

Genauso finde ich es einen Glücksfall, wenn man einen Parser für die gewünschte Sprache gibt, der eine der angeblichen Wunder-Technologien unterstützt. Zumindest bin ich damit oft auf die Nase gefallen. Sicher einen Parser zu finden, der dir XML in irgend eine Datenstruktur packt, das ist nicht schwer. Aber dann habe ich ja auch nichts der von dir besungenen Infrastruktur.

[Außenstehender]

lol, ihr seid aber auch blöd und selber schuld, wenn ihr in einem c++ forum mit neuen technologien ankommt. im dschungel von afrika will auch niemand nen auto

[SideWinder]

Außenstehender schrieb:

lol, ihr seid aber auch blöd und selber schuld, wenn ihr in einem c++ forum mit neuen technologien ankommt. im dschungel von afrika will auch niemand nen auto

MfG SideWinder

[http://www.c-plusplus.de/]

Außenstehender schrieb:

lol, ihr seid aber auch blöd und selber schuld, wenn ihr in einem c++ forum mit neuen technologien ankommt. im dschungel von afrika will auch niemand nen auto

Meinst du mit neuen technologien das alte xml zeugs?

[c.rackwitz]

er muss lisp meinen. lisp ist naemlich secret alien technology und der menschheit jahrtausende voraus. deswegen kapierts auch kaum jemand.

[Arno Nüm]

XML hat einen gravierenden Vorteil:

man kann Konfigurationsdateien einfach gegen ein Schema validieren und jedes Feld auf gültige Werte einschränken (z.B: Windowed darf nur einen bool-Wert besitzen). Heute liefert schon fast jede Programmiersprache einen Parser + Validator für XSD-Schema in der Standardbibliothek mit. Stellt euch mal vor wie fricklig sowas mit ini Dateien ist.

[c.rackwitz]

das schema musst du erstmal schreiben. die gleiche arbeit fuer ne ini datei muss man sich auch machen.

[Gast]

c.rackwitz schrieb:

das schema musst du erstmal schreiben. die gleiche arbeit fuer ne ini datei muss man sich auch machen.

Ne, ich schreib

new XmlSerializer(typeof(MyConfigClassWithGeilePropertiesType)).Serialize(stream, config);

Da muss ich kein Schema schreiben, weil die Properties vom passenden Typ sind und wenn ich den Wertebereich einschränken muss, muss ich sowieso die Validierung in die Properties einbauen, unabhängig davon was ich mit der Klasse dann mache. Aber für das XML ist der einzige Aufwand diese Zeile.

[Gast]

Schön peinliche Diskussion...

PS: foo_bar oder fooBar?

[c.rackwitz]

und wo steht, welches property welchen wertebereich oder typ haben darf?

[Gast]

c.rackwitz schrieb:

und wo steht, welches property welchen wertebereich oder typ haben darf?

Der Typ ergibt sich durch das Property selbst:

public class Configuration {
    public Size Resolution {
        get { return resolution; }
        set { resolution = value; }
    }

    public bool Windowed {
        get { return windowed; }
        set { windowed = value; }
    }
...
}

Daraus entsteht dann irgendwie sowas in der Art:

<Configuration>
    <Resolution type="System.Drawing.Size">
        <Width>800</Width>
        <Height>600</Height>
    </Resolution>
    <Windowed>True</Windowed>
</Configuration>

Den Wertebereich prüfst du im Code bei der Zuweisung der Properties und wirfst ggf. eine Exception. Du stellst also sicher, dass eine Instanz von Configuration immer gültige Werte hat. Beim Deserialisieren werden die ganzen Zuweisungen gemacht und ungültiges XML oder ungültige Werte führen so zu einem Fehler beim Deserialisieren (auch ein Einzeiler).

[Marc++us]

XMLSpy hat übrigens einen ganz hervorragenden Schema-Editor, dem man eine XML vorlegt, und man kann daraus mit einigen Zusatzeingaben ein (sehr striktes) Schema bauen. Selbst bei komplexeren Datenformaten Dauer < 1 Stunde.

[byto]

c.rackwitz schrieb:

das schema musst du erstmal schreiben. die gleiche arbeit fuer ne ini datei muss man sich auch machen.

Klar ist das Schreiben des Schemas ein Mehraufwand. Aber danach ist die Struktur der XML-Dateien klar definiert und Du kannst schon vor dem Parsen die Korrektheit des Formats prüfen. Das ist besonders nützlich, wenn mehrere Programme das gleiche Format verwenden. Wenn alle Programme das gleiche Schema zugrunde legen, ist die Interoperabilität gewährleistet.

Und was das Erzeugen angeht: Entweder man erzeugt das Schema automatisch aus bestehenden XML-Dateien und passt es noch ein wenig an (Kardinalitäten etc) oder man schreibt es kurz per Hand. Es gibt zahlreiche sehr gute Editoren mit Code-Completion, womit das recht fix von der Hand geht. Da hat man sich imo sehr schnell eingearbeitet. XML-Schema ist wesentlich weniger komplex als beispielsweise XSLT oder XPath.

[SideWinder]

Marc++us schrieb:

XMLSpy hat übrigens einen ganz hervorragenden Schema-Editor, dem man eine XML vorlegt, und man kann daraus mit einigen Zusatzeingaben ein (sehr striktes) Schema bauen. Selbst bei komplexeren Datenformaten Dauer < 1 Stunde.

Was heißt hier "< 1 Stunde"? Wie komplex sind die Datenformate die du mit XML verwaltest?

MfG SideWinder

[byto]

Das letzte XML-Schema habe ich im Laufe meiner Diplomarbeit geschrieben und waren von der Komplexität her etwa 30-40 Schema-Typen (~1000 Zeilen). Hat vielleicht einen Vormittag gedauert. Mit entsprechenden Editoren brauchste dabei nicht mal XML schreiben sondern kannst Dir die Typen und Attribute auch zusammenklicken.
XMLSpy bietet verdammt viele Möglichkeiten, ist mir persönlich aber schon fast zuviel. Habe Eclipse Webtools Plattform benutzt, ist umsonst und hat einen vernünftigen XML und Schema Editor.

[c.rackwitz]

Optimizer schrieb:

...

das ueberzeugt mich garnicht. typisch java.

erkennt keiner von euch, dass man genau das gleiche auch mit lisp machen kann?

[keine Angabe]

erkennt keiner von euch, dass man genau das gleiche auch mit lisp machen kann?

Solange du Java abwertest ohne es überhaupt zu erkennen (und das kann man von sich bei weitem nich behaupten, wenn man C# und Java Code verwechselt), hast du auch absolut keinen Anspruch Kenntnisse über Nischensprachen von anderen "Java"-Programmierern zu fordern.

[Gast]

c.rackwitz schrieb:

Optimizer schrieb:

...

das ueberzeugt mich garnicht. typisch java.

erkennt keiner von euch, dass man genau das gleiche auch mit lisp machen kann?

Ok. Du kritisiertest, dass man ein Schema schreiben muss. Ich zeigte, dass man das nicht muss (für Konfigurationsdateien, wofür man inis üblicherweise verwendet). Was ist an der Lösung genau schlecht? Geht sie am Thema vorbei? Willst du unbedingt ein freakiges Schema schreiben und alle XML-Tricks für was simples auspacken, dich endlos verkünsteln? Was hat das überhaupt mit einer Programmiersprache zu tun gehabt?

[nutzername:]

TactX schrieb:

Schön peinliche Diskussion...

PS: foo_bar oder fooBar?

fooBar natürlich sonst könnte man ja gleich noch ungarische notation verwenden.