Unterschiede (Vor- und Nachteile) vom XML gegenüber Ini-Dateien
-
.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
-
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?
-
.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.
-
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.
-
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>)*
-
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
-
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
-
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?
-
er muss lisp meinen. lisp ist naemlich secret alien technology und der menschheit jahrtausende voraus. deswegen kapierts auch kaum jemand.
-
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.
-
das schema musst du erstmal schreiben. die gleiche arbeit fuer ne ini datei muss man sich auch machen.
-
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.
-
Schön peinliche Diskussion...
PS: foo_bar oder fooBar?
-
und wo steht, welches property welchen wertebereich oder typ haben darf?
-
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).
-
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.
-
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.
-
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
-
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.