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

Ich würde gleich alles in C++ Code speichern, da kannst da alles machen.

darthdespotism

KETRAXONTOR schrieb:

Ich würde gleich alles in C++ Code speichern, da kannst da alles machen.

Für einfache Programme vielleicht sinnvoll.

Aber:

Der User kann nichts anpassen
Nach jeder Anpassung muss der Quellcode neu compiliert werden
Modifizierungen (Fremdsprachliche Versionen ...) sind viel komplizierter als sie sein müssten
Andere können bestimmt andere Einschränkungen aufzählen
...

DEvent

schrieb:

# Messages_de_DE
hello_world=Hallo Welt

# Messages_en_US
hello_world=Hello World
Falls allerdings eine Sammlung von Konfigurationsoptionen benötigt wird, die nicht eine ähnlich starke Kohäsion aufweist, verwende ich eine eine XML Datei mit beispielsweise einzelnen Sektionen, die gegebenenfalls oben angeführte Property Dateien importieren.

Wie unterscheidest du ob hello_world nun _de_DE ist oder _en_US? Durch die Kommentare?
Grade dazu eignet sich XML doch super:

<sprachen>
    <item name="hellow_word" language="en_US">Hello World</item>
    <item name="hellow_word" language="de_DE">Hallo Welt</item>
</sprachen>

@c.rackwitz: genau das hat minhen gemeint. Einmal wird "" als Begrenzer eingesetzt, einmal nichts. Dann wird sogar no-name-Tags eingesetzt

(1280 1024)
(1280 960)
(1152 864)
(1024 768)
(800 600)
(640 480)

An dem Parser will ich nicht arbeiten wollen.

Regexps suck for processing XML.

Das wundert mich jetzt aber extrem. Ist das wahr und ich verstehe noch weniger von regexps als ich dachte?

Artchi

Wie unterscheidest du ob hello_world nun _de_DE ist oder _en_US? Durch die Kommentare?

Speichert man in unterschiedliche Dateien ab, somit ist eine Einteilung gegeben:

Dateien:
texte_de_DE.properties
texte_en_US.properties

Hat er nur nicht explizit angegeben. Bei Programmstart wird je nach locale die entsprechende Datei geladen.

Artchi schrieb:

Hat er nur nicht explizit angegeben. Bei Programmstart wird je nach locale die entsprechende Datei geladen.

Danke, dass du das ergänzt hast. Ich dachte eigentlich, dass es klar ist, aber ich hätte wohl im Code Block explizit die Dateiendung anführen sollen, um die letzten Zweifel restlos zu beseitigen.

c.rackwitz

DEvent:
lern scheme, dann wirst du merken, warum mein beispielcode sinn macht.
code und daten sind potentiell das gleiche. die daten koennen sich selbst "ausfuehren". modes z.b. koennte seine argumente eben so interpretieren. kein thema. kannst du mit xml nicht.

rexen und xml suckt, weil rexen und ungeparster quellcode suckt. deswegen gibts refactoring tools mit code-awareness. die schnibbeln nicht einfach nur am text rum, die sind sich der semantik bewusst. rexen sind sich der semantik hinter spitzen klammenr und slashes (=xml) nicht bewusst.

z.b. koennen rexen keine rekursiven klammernpaare matchen. geht nicht. dazu brauchst du was maechtigeres als rexen: z.b. PEGs oder normales BNF. sind eigentlich auch nur rexen, aber mit rekursion. und die brauchst du um rekursion zu matchen.
alle baumstrukturen sind inherent rekursiv. deswegen kannst du mit rexen da nix gross ausrichten.

scheme/lisp parser sind mit die einfachsten parser fuer irgendeine sprache die es gibt. und wenn du erstmal einen hast, dann hast du nicht nur einen config parser, du hast potentiell ein ganzes scripting system.

lies doch einfach mal, was der stevey da geschrieben hat. und lern scheme. mit "sicp" und "plt scheme". ist wichtig. glaub mir.

ernsthaft. lern scheme.

hustbaer

Weils hier gerade inetwa dazupasst: kennt jmd. denn eine gute XML Library für C++? Wobei "gut" im Sinne von einfach zu verwenden -- muss nicht allen Schnickschnack können, Validierung etc. bräuchte ich alles nicht.
Das Interface sollte halt einfach und halbwegs modern sein, also wenn geht mit std::string/wstring arbeiten etc. - keine Zeiger zurückgeben die man selbst löschen muss etc.

SideWinder

hustbaer schrieb:

Weils hier gerade inetwa dazupasst: kennt jmd. denn eine gute XML Library für C++? Wobei "gut" im Sinne von einfach zu verwenden -- muss nicht allen Schnickschnack können, Validierung etc. bräuchte ich alles nicht.
Das Interface sollte halt einfach und halbwegs modern sein, also wenn geht mit std::string/wstring arbeiten etc. - keine Zeiger zurückgeben die man selbst löschen muss etc.

TinyXML

MfG SideWinder

minhen

DEvent schrieb:

Grade dazu eignet sich XML doch super:

<sprachen>
    <item name="hellow_word" language="en_US">Hello World</item>
    <item name="hellow_word" language="de_DE">Hallo Welt</item>
</sprachen>

Da bietet sich aber xml:lang als Attribut schon an. Bei einer Aufteilung in eine Sprache pro Datei würde ich auch xml:id verwenden und sowas hier basteln:

<strings xml:lang="de_DE">
    <s xml:id="1001">Hallo Welt</s>
    <s xml:id="1002">Servus</s>
</strings>

Oder wenn's unbedingt in einer Datei sein soll auch sowas hier:

<strings>
    <string xml:id="1001">
        <s xml:lang="de_DE">Hallo Welt</s>
        <s xml:lang="en_US">Hello World</s>
    </string>
</strings>

Wenn man's in XML macht, sollte man schon die Standard-Attribute verwenden, wenn man deren Semantik meint. Hat einfach auch den Vorteil, dass eventuelle Editoren und sonstige Tools dann bereits automatisch wissen, was du meinst.

Regexps suck for processing XML.

Das wundert mich jetzt aber extrem. Ist das wahr und ich verstehe noch weniger von regexps als ich dachte?

Nein, ist nicht wahr.
Als "Beweis der Einfachheit" habe ich mir gestern nachmittag einen Parser für XML in Perl geschrieben. Und da hab ich selbstverständlich auch auf die regulären Ausdrücke von Perl zurückgegriffen. Das Ausgabeformat ist ein Hash, der Code ist also ein "Mapping" eines XML-Dokuments auf eine Standard-Datenstruktur von Perl. (Perl kennt drei Datenstrukturen: Skalare, Arrays und besagten Hash.)
Der Parser verarbeitet beliebig verschachtelte Tags korrekt, hat keine Probleme mit gemischtem Inhalt (Zeichendaten und Tags gemischt auf einer Ebene), verwurschtelt die ach so bösen Attribute korrekt und weil's so schön ist erkennt und verwendet er sogar die in der internen DTD definierten Standardwerte für Attribute.
Arbeitsaufwand: ungefähr 40 Zeilen Programmcode.
Der Code ist relativ simpel und besteht letztlich aus 5 regulären Ausdrücken. Ohne denen müsste es sich eigentlich auch brauchbar mit einem einfachen Kellerautomaten lösen lassen. Zwar ist der Parser nicht konform im Sinne der XML-Spezifikation, da er sich nur brauchbaren Kram heraussucht und z.B. keinerlei Fehlermeldungen ausspuckt, er ist auch kein Performancewunder, aber das soll er auch gar nicht sein. Es ging ja nur darum, dass XML eben doch nicht unglaublich schwer zu verarbeiten ist - selbst wenn man keinen der unzähligen existierenden Parser verwenden will. Eine Sprache, für die ich mir in kürzester Zeit ohne großem Nachdenken einen Parser aus dem Ärmel schütteln kann, finde ich nun wirklich nicht schwer zu parsen.

DrGreenthumb

SideWinder schrieb:

hustbaer schrieb:

Weils hier gerade inetwa dazupasst: kennt jmd. denn eine gute XML Library für C++?

TinyXML

TinyXML++ ist besser.

.filmor

DEvent schrieb:

<sprachen>
    <item name="hellow_word" language="en_US">Hello World</item>
    <item name="hellow_word" language="de_DE">Hallo Welt</item>
</sprachen>

Und warum benutzt du nicht xml:lang?!
Mal im Ernst, sowas schreibt doch kein Mensch freiwillig. Haufenweise inhaltsleerer Datenµll (item, name, language, /item, sprachen, /sprachen). Und selbst wenn man sich ein besseres Dateiformat ausdenkt, was ja durchaus möglich ist, ist das ganze für Menschen immernoch schwer zu bearbeiten.
Mehrere primitive Dateien und gut ist. Oder noch besser, was Fertiges wie gettext benutzen.

DEvent schrieb:

Regexps suck for processing XML.

Das wundert mich jetzt aber extrem. Ist das wahr und ich verstehe noch weniger von regexps als ich dachte?

Naja, eigentlich sind reguläre Ausdrücke doch per Definition nicht für Klammersprachen geeignet...

c.rackwitz

minhen schrieb:

Regexps suck for processing XML.

Das wundert mich jetzt aber extrem. Ist das wahr und ich verstehe noch weniger von regexps als ich dachte?

Nein, ist nicht wahr.
Als "Beweis der Einfachheit" habe ich mir gestern nachmittag einen Parser für XML in Perl geschrieben.

es gibt nen unterschied zwischen "parser bauen mit regexen" und "mit regexen xml zerlegen". regex ist kein xpath, xquery, etc.

minhen

.filmor schrieb:

DEvent schrieb:

Regexps suck for processing XML.

Das wundert mich jetzt aber extrem. Ist das wahr und ich verstehe noch weniger von regexps als ich dachte?

Naja, eigentlich sind reguläre Ausdrücke doch per Definition nicht für Klammersprachen geeignet...

Falsch. Reguläre Ausdrücke wie sie bei Programmiersprachen meistens implementiert sind, sind echt und deutlich mächtiger als Typ-3-Grammatiken. Das trifft besonders auf die regulären Ausdrücke von Perl zu - aber auch auf alle Implementierungen, die sich an Perl oder an der POSIX Extended Syntax orientieren. Und das sind praktisch alle Implementierungen. Egal ob bei PHP oder Boost für C++.
Das Grundmuster um Tags damit sinnvoll erkennen zu können, sieht so aus:
<(name)...> ... name ist dabei ein Teilausdruck, der gültige Namen für Tags gemäß XML-Spezifikation erkennt. Die runden Klammern drumherum halten den so erkannten Namen als erstes Teilergebnis (in der Variabel $1) fest. Der wichtige Punkt ist jetzt \1, was schlicht eine Backreference auf den Teilausdruck in $1 ist. Jetzt noch auf die Greediness achten und fertig ist ein regulärer Ausdruck, der zu einem beliebigen öffnenden Tag das passende schließende Tag (und alles was dazwischen steht) findet. Wie gesagt, ziemlich einfach und überhaupt kein Thema. Das Werkzeug "regulärer Ausdruck in der realen Welt" muss man dafür aber durchaus kennen

.filmor

Mir ist durchaus bewusst, dass man mit Perl-RegExes solche Sachen machen kann, aber nochmal, reguläre Ausdrücke an sich können keine Klammersprachen implementieren. Und nur, weil ihnen das mit derartigen Erweiterungen gelingt, heißt das nicht, dass sie dafür geeignet wären. Was macht dein Parser eigentlich, wenn man ihm Fehler unterjubelt?

minhen

.filmor schrieb:

Mir ist durchaus bewusst, dass man mit Perl-RegExes solche Sachen machen kann, aber nochmal, reguläre Ausdrücke an sich können keine Klammersprachen implementieren. Und nur, weil ihnen das mit derartigen Erweiterungen gelingt, heißt das nicht, dass sie dafür geeignet wären.

Wie bereits angedeutet, reguläre Ausdrücke der theoretischen Informatik und reguläre Ausdrücke in Programmiersprachen sind zwei paar Schuhe. Es geht hier - wie ebenfalls schon gesagt - nicht alleine um Perl. Sachen wie Backreferences beherrschen praktisch alle Implementierungen. PHP, Pyhton, Perl, Java - und das sind rein zufällig auch die regulären Ausdrücke, die man meint, wenn man vom Verwenden von regulären Ausdrücken einer Sprache spricht

Den letzten Satz musst du allerdings erklären. Die geforderte Aufgabe gelingt zwar einwandfrei mit regulären Ausdrücken aber reguläre Ausdrücke sind dennoch grundlegend nicht dafür geeignet? Alles klar ...

Was macht dein Parser eigentlich, wenn man ihm Fehler unterjubelt?

Steht bereits im entsprechenden Beitrag.

DEvent

lies doch einfach mal, was der stevey da geschrieben hat. und lern scheme. mit "sicp" und "plt scheme". ist wichtig. glaub mir.

Ich habe den Artikel gelesen, naja flüchtig, aber gelesen. Ehrlich gesagt ist mir dieser Stevey suspekt.

Unless "we" are C++ programmers, in which case "we" like to write 2500-line clones of the Unix 'grep' utility whenever "we" need to do a text search

Dieser Satzt am Anfang des Artikels legt schon mal einen derben Beigeschmack.

Stimmt, man sollte xml:id und xml:lang benutzen, habe daran nicht gedacht.

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.

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