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

rüdiger

Optimizer schrieb:

So, dass die hunderttausend Sachen (hoffentlich) sinnvoll gruppiert sind. Klar, weniger wird es nicht, wenn es so viel zum Konfigurieren gibt, dann ist es so. Aber wenn ein übergeordneter Node schon mal nix ist, scrollst du du so lange runter, bis die Einrückung wieder zurückgeht, ist doch geil. Also ich finde sowas schon übersichtlicher...

die sind doch auch so gruppiert. Wie du sagst, die Nodes werden nicht weniger, dafür kommt mehr Text. Ich weiß nicht ob mehr Text wirklich eine Hilfe gegen Unübersichtlichkeit einer Datei ist. Aber da wir hier keinen Vergleich haben, können wir beide nur spekulieren.

byto

Spätestens, wenn Du einen XML-Editor benutzt, der Knoten auf- und zuklappen kann, wie es jeder moderne Browser bietet.

@rüdiger:
Das stimmt natürlich, es ist reine Spekulation. Man kann ja nicht mal davon ausgehen, dass die Gruppierung bei Verwendung einer Baumstruktur gleich ausgefallen wäre. Ich gebe zu, ich kann dir nicht beweisen, dass XML übersichtlicher ist, ist nur so ein Gefühl von mir.

Ich hab hier zwar nicht vor alles in XML zu gestalten, aber zumindestens ein Teil davon soll zeigen, dass die UT Konfigurations absoluter Müll ist.

[XInterface.MapListTeamDeathMatch]
MapNum=0
Maps=DM-RRAJIGAR
Maps=DM-RANKIN
Maps=DM-CORRUGATION
Maps=DM-DE-GRENDELKEEP
Maps=DM-DE-IRONIC
Maps=DM-DE-OSIRIS2
Maps=DM-GESTALT
Maps=DM-IRONDEITY
Maps=DM-METALLURGY
Maps=DM-Deck17
Maps=DM-Antalus
Maps=DM-Asbestos
Maps=DM-Curse4

....

[BonusPack.MapListMutant]
Maps=DM-RRAJIGAR
Maps=DM-RANKIN
Maps=DM-CORRUGATION
Maps=DM-DE-GRENDELKEEP
Maps=DM-DE-IRONIC
Maps=DM-DE-OSIRIS2
Maps=DM-GESTALT
Maps=DM-IRONDEITY
Maps=DM-METALLURGY
Maps=DM-Deck17
Maps=DM-Antalus
Maps=DM-Asbestos
Maps=DM-Curse4

[BonusPack.MapListLastManStanding]
Maps=DM-RRAJIGAR
Maps=DM-RANKIN
Maps=DM-CORRUGATION
Maps=DM-DE-GRENDELKEEP
Maps=DM-DE-IRONIC
Maps=DM-DE-OSIRIS2
Maps=DM-GESTALT
Maps=DM-IRONDEITY
Maps=DM-METALLURGY
Maps=DM-Deck17
Maps=DM-Antalus
Maps=DM-Asbestos
Maps=DM-Curse4 

...

[Skaarjpack.MapListSkaarjInvasion]
Maps=DM-RRAJIGAR
Maps=DM-RANKIN
Maps=DM-CORRUGATION
Maps=DM-DE-GRENDELKEEP
Maps=DM-DE-IRONIC
Maps=DM-DE-OSIRIS2
Maps=DM-GESTALT
Maps=DM-IRONDEITY
Maps=DM-METALLURGY
Maps=DM-Deck17
Maps=DM-Antalus
Maps=DM-Asbestos

<maps id="deathMatch">
    <include>DM-RRAJIGAR</include>
    <include>DM-RANKIN</include>
    <include>DM-CORRUGATION</include>
    <include>DM-DE-GRENDELKEEP</include>
    <include>DM-DE-IRONIC</include>
    <include>DM-DE-OSIRIS2</include>
    <include>DM-GESTALT</include>
    <include>DM-IRONDEITY</include>
    <include>DM-METALLURGY</include>
    <include>DM-Deck17</include>
    <include>DM-Antalus</include>
    <include>DM-Asbestos</include>
    <include>DM-Curse4</include> 
</maps>

...

<xInterfaces>
  <xInterface name="teamDeathMatch">
    <mapNumber>0</mapNumber>
    <maps refid="deathMatch" />
  </xInterface>
</xInterfaces>

<bonusPacks>
  <bonusPack name="mutant">
    <maps refid="deathMatch" />
  </bonusPack>
  <bonusPack name="lastManStanding">
    <maps refid="deathMatch" />
  </bonusPack>
</bonusPacks>

<skaarjpacks>
  <skaarjpack name="skaarjInvasion">
    <!-- enthält sämtliche deathMatch maps, bis auf DM-Curse4 -->
    <maps refid="deathMatch">
      <exclude>DM-Curse4</exclude>
    </maps>
  </skaarjpack>
</skaarjpacks>

Man sieht also, UT hätte besser eine XML Konfiguration verwenden sollen.

DEvent

c.rackwitz schrieb:

was ich meinte war:

die selbe arbeit, die ihr euch mit sun/MS java und XML machen muesst, um dateien zu validieren, die waere auch zu tun wenn man lisp daten validieren wollen wuerde. ich konnte es einfach nicht so stehen lassen, dass - ich weiss nicht mehr wer - xml schemas als etwas einfaches hinstellt, was man mit inis oder lisp daten nicht machen koennte. kann man naemlich. also ist es kein argument fuer xml.

Man könnte sicherlich auch einen Validierer für Lisp schreiben, aber für XML gibt es schon genügend, gibt es für Lisp auch schon einen?

c.rackwitz schrieb:

und weil hier doch von config dateien die rede ist, braucht man ja schon mal kein schema, weil nichts interoperieren muss. von mir aus kanns gerne auch ein binaerformat sein, so lange das programm sich selbst dann noch lesen kann.

Was ist mit verschiedenen Versionen eines Programmes? Oder was ist mit Config-Dateien, die ein Benutzer erstellt? Die müssen auch auf Gültigkeit überprüft werden und das kann man mittels XSL-Schema ganz leicht.

c.rackwitz schrieb:

das laesst sich dann aber schlecht vom menschen bearbeiten. deswegen bin ich auch gegen xml als config.
laesst sich mit primitiven texteditoren schwerer bearbeiten als conf oder ini.

Darüber lässt sich streiten.

c.rackwitz schrieb:

so lange die daten keine baumstruktur haben, sind doch conf und ini perfekt. und wenn doch baumstruktur verlangt ist, wuerde ich s-expressions (lisp) vorziehen. die strapazieren das auge nicht mit meta-text wie "<attribute>", "<property>" oder diesen redundanten schliessenden tags. ein einfaches </> koennte es doch auch tun, ist dann aber wieder zu "uneindeutig", und das scheint manche zu beunruhigen.

Nach 100 Zeilen Xml-Tags bin ich ganz froh, das am Ende der Node ein </liste> steht, weil ich dann leichter sehe "Aha hier ist die Liste zuende". Bei S-Exps musst du dann die Klammern zählen, ich bezweifle das man sofort sehen kann ob bei )))))))) nun eine Klammer zu viel oder zuwenig ist.

Was ist meta-text? Meta-Informationen kommt bei XML in die Attribute der Tags.

c.rackwitz

optimizer. ich glaub du verstehst mich falsch. wenn ich von baumstruktur rede, dann meine ich, dass daten entweder baumstruktur haben oder nicht. und wenn sie die haben (siehe UT conf), dann soll man die auch baumartig repraesentieren. ich weiss nicht, warum ich das noch erklaeren soll.

byto

Die ganze Dikussion ist mittlerweile irgendwie ziemlich sinnlos geworden, weil jeder auf gewisse Weise Recht hat. Es wurde nach einfachen Konfigurationsdateien gefragt. Die kann man natürlich weiterhin als ini Dateien mit flachen Name-Wert-Paaren schreiben. Natürlich macht auch XML Sinn bei größeren Datenmengen aufgrund der Möglichkeiten zur Strukturierung. Sicherlich ist aber XML auch nicht der heilige Gral. Es gibt sicher pro und contra für oder gegen XML und es bleibt jedem frei, eine alternative Datenbeschreibungssprache zu benutzen.

XML ist halt sehr anpassungsfähig, hat eine große Akzeptanz und einen riesigen Toolsupport. Das macht den Einsatz sehr attraktiv.

Optimizer schrieb:

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?

Jetzt mal langsam... Schön für dich, dass es so einfach mit .NET geht. Ich kann mich aber nicht erinnern, dass es in diesem Thread um die Vorteile von .NET geht oder das wir hier gar im .NET Forum sind...

Für andere Sprachen bleibt einen nunmal nichts anderes übrig, als über ein XSD-Schema / DTD etc. zu validieren. Und warum ein Schema schreiben? Es gibt eine Latte von Programmen, die dir zu einer XML-Datei sehr strikte Schema generieren und das kostenlos!! Oder man klickt das Schema mit XMLSpy zusammen...

THX 1138

Jetzt mal im Ernst, bei über 1000 Zeilen Konfigurationen, da wird einem so oder so übel von Hand zu editieren.
Für so viele Einstellung wär ein GUI a la Systemsteuerung einfach das einfachste.

minhen

c.rackwitz schrieb:

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.$

Da hast du durchaus recht. An eine Verschachtelung in der Tags sich selbst enthalten, habe ich in der Tat nicht gedacht, da ich damit praktisch auch nie zu tun hatte. Zumindest in Perl kann man dieses Problem aber auch einfach lösen ohne auf reguläre Ausdrücke verzichten zu müssen. Denn in Perl kann man auch Programmcode in reguläre Ausdrücke einbetten welcher auf das bisher gerade Gematchte zugreifen kann als auch das weitere Matching, das weitere Suchmuster beliebig verändern kann. Damit ist es relativ einfach einen Zähler für öffnende und schließende Tags in den regulären Ausdruck einzubauen und das Problem somit zu lösen.
Der Grundgedanke bei einem solchen Zähler ist letztlich der selbe wie beim Parsing mit einem Kellerautomaten, was ich ja schon angesprochen hatte. Einen solchen oder einen ähnlichen Mechanismus - man muss ja bei weitem keinen formalen Kellerautomaten implementieren nur um XML zu parsen - kann man relativ einfach implementieren. Das ist ja nun wirklich keine große Sache. Ich würde sogar behaupten, dass ein solcher auf keinen Fall komplizierter als die Lösung mit den regulären Ausdrücken ist. Selbige bieten sich in Perl halt schlicht an, aber das bedeutet nicht, dass man es in anderen Sprachen auch mit regulären Ausdrücken lösen muss oder kann. Ich würde sogar so weit gehen und behaupten, dass es ohne reguläre Ausdrücke vielleicht sogar einfacher zu lösen sein könnte. Denn was braucht man schon großartig um XML einzulesen? Einfachste String-Funktionen und eine Stack-artige Datenstruktur wie z.B. vector der STL reichen völlig aus. Damit kann man auch und gerade die von dir genannte "kompliziertere" Verschachtelung einwandfrei parsen.
Und darum ging es letztlich ja auch. Denn die Behauptung war doch, dass es wenige brauchbare Parser für XML gebe (was schlicht falsch ist) und dies daran liege, dass XML so ungeheuer schwer zu parsen sei. Mittlerweile sollte ja klar sein, dass dem nicht so ist.

Was deine Schwärmerei für S-Expressions angeht, so frage ich mich doch, weshalb - sofern man der Wikipedia glauben schenken kann - es zwar als Standardvorschlag eingereicht aber nie als Standard angenommen wurde. Wenn es so unglaublich viele tolle Vorteile hat, stellt sich auch die Frage, weshalb es praktisch nicht verwendet wird und warum es lediglich einen Parser nur in C gibt. Aber auch wenn das Fragen sind, die einem sofort durch den Kopf gehen, ist deren Beantwortung letztlich doch nur von akademischen Interesse.
Denn Fakt ist einfach, dass die Unterstützung für XML einfach in allen Bereichen unglaublich riesig ist, während es für Alternativen wie S-Expressions praktisch nichts gibt. Alleine deshalb ist XML schon die erste Wahl.

rüdiger schrieb:

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.

Was ist der Sinn von C++ wo es doch Objective-C gibt?
Oder wo soll der Sinn von verschiedenen Brotsorten liegen?
Dass es verschiedene Möglichkeiten gibt, etwas zu tun, ist nicht nur gut, sondern auch kein technisches Problem, und erst recht keins von XML, sondern ein menschliches.

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.

Die XSLT-Unterstützung bei Browsern ist deutlich besser als z.B. die Unterstützung bzw das Vorhandensein von Flash-Plugins. Und dennoch reicht die Unterstützung von Flash offenbar für einen kommerziellen Einsatz aus. (Ich will jetzt nicht Flash gut reden, denn Flash ist schrecklich ;))
Das heißt die Verbreitung von XSLT bei Browsern ist mehr als ausreichend und sollte ohnehin irgendwo nahe bei 99% Verbreitungsgrad beim Endanwender liegen. Warum man XSLT dennoch nicht so einsetzen sollte, wie dir es vorschwebt, ist eine andere (auch ideologische) Sache, zu der es schon genug Threads gab.
Neben dem Internet Explorer und dem Firefox beherrschen zum Beispiel auch Opera und Safari einwandfrei XSLT. Opera, welcher jetzt schon seit geraumer Zeit XSLT unterstützt, hat dabei sogar die beste XSLT-Unterstützung überhaupt und Firefox dagegen eher eine zwar völlig ausreichende aber doch ziemlich minimale.

XSLT ist nebenbei eine wirklich feine Sache, von der ich gerne Gebrauch mache. Meine private Webseite wird zum Beispiel auch aus XML+XSLT serverseitig erzeugt. Für Kleinigkeiten, die ich in XML abspeichere, verwende ich auch gerne XSLT.
So ist es einfach ungeheuer praktisch, wenn man einfach mal eben

<veranstaltung>
	<titel>Irgendeine Vorlesung</titel>
	<dozent>Irgendein Professor (optional)</dozent>
	<url>Eine optionale URL-Angabe</url>
	<termin> <!-- gerne auch mehrere -->
		<tag>di</tag>
		<von>12</von>
		<bis>14</bis>
		<ort>Irgendwo in Europa</ort>
	</termin>
</veranstaltung>

ausfülle und daraus automatisch mittels XSLT ein einwandfreier, schöner XHTML-Stundenplan generiert wird, der einem nicht nur alle Termine in üblicher Form (Uhrzeit für die Zeilen, Tage für die Spalten) präsentiert sondern auch Zusatzkram wie z.B. die Semesterwochenstundenzahl ausrechnet. Oder fand hier irgendjeman die Standard-Pläne seiner Uni brauchbar? Natürlich kannst du das auch mit einer anderen Programmiersprache erledigen. Aber XML+XSLT ist eben auch eine feine und direktere Möglichkeit.

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.

Da verstehst du etwas falsch. XSL-FO ist für den Druck, also für Print-Medien gedacht. Im Gegensatz dazu ist CSS für den Einsatz im WWW gedacht. XSL-FO und CSS sind also zwei Möglichkeiten XML zu visualisieren, aber mit zwei völlig verschiedenen Einsatzgebiet.

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.

Ich finde es zumindest nicht schwer. Wenn ich etwas für Browser mache, schreibe ich es standardkonform und damit sind automatisch Browser wie Opera und Firefox abgedeckt und glücklich. Wenn ich es veröffentlichen will, gibt's einfach ein CSS für den Internet Explorer dazu, welches die standardkonforme CSS überschreibt und für den IE hinhackt. Fertig. Ist nicht wirklich wild. Klar, die Extra-Wurst für den völlig verkorksten IE ist nervig, aber es hält sich in Grenzen.
Das betrifft aber ohnehin nur (X)HTML+CSS. Ich finde es interessant, dass du das hier als Kritikpunkt an XML darstellst.

byto

minhen schrieb:

Das heißt die Verbreitung von XSLT bei Browsern ist mehr als ausreichend und sollte ohnehin irgendwo nahe bei 99% Verbreitungsgrad beim Endanwender liegen.

Sehen die Jungs von Blizzard wohl genauso (nur um mal ein Beispiel zu nennen):

http://www.worldofwarcraft.com/index.xml

Dauercoder

ich würde einfachmal sagen, dass die maximale größe einer ini-datei auf 64 KB festgelegt ist! siehe: http://support.microsoft.com/kb/78346/de

xml-dateien können belibig groß werden, zum editieren werden keine administratorrechte benötigt und die syntax (aufbau) ist wesentlich flexibler. xml-dateien sind ebenfalls leicht zu parsen, z.b. beim .net framework, das ist alles dabei was man mit xml alles so anstellen könnte!

Höh, also jetz wird's ja schon konfus. Was hat das denn mit Administrator-Rechten zu tun?

Dauercoder schrieb:

ich würde einfachmal sagen, dass die maximale größe einer ini-datei auf 64 KB festgelegt ist! siehe: http://support.microsoft.com/kb/78346/de

xml-dateien können belibig groß werden, zum editieren werden keine administratorrechte benötigt und die syntax (aufbau) ist wesentlich flexibler. xml-dateien sind ebenfalls leicht zu parsen, z.b. beim .net framework, das ist alles dabei was man mit xml alles so anstellen könnte!

lol, ich bin super, ich kann ne datei auch einlesen, wenn sie größer ist als 64KB obwohl .ini hintendran steht

Artchi

64 KB ist das Limit, wenn eine Anwendung die Standardanwendungsprogrammaufrufe mit Windows-Benutzeroberfläche (AP

Hat nichts mit diesem Thread zutun! In diesem Thread gehts allgemein um das Format einer Cfg-Datei.

THX 1138

Abgesehen davon, denke mit 64000 Zeichen kannst du einiges konfigurieren..

minhen

Dauercoder schrieb:

ich würde einfachmal sagen, dass die maximale größe einer ini-datei auf 64 KB festgelegt ist! siehe: http://support.microsoft.com/kb/78346/de

Das Lesen von Dokumenten der "Knowledge Base" von Microsoft solltest du aber besser noch üben.

Die Informationen in diesem Artikel beziehen sich auf:

Microsoft Windows 3.0 Standard Edition
Microsoft Windows 3.1 Standard Edition
Microsoft Windows 3.11 Standard Edition
Microsoft Windows for Workgroups 3.1
Microsoft Windows for Workgroups 3.11

THX 1138 schrieb:

Abgesehen davon, denke mit 64000 Zeichen kannst du einiges konfigurieren..

Wenn dann sind es ohnehin eher 65536 Zeichen.

THX 1138

minhen schrieb:

THX 1138 schrieb:

Abgesehen davon, denke mit 64000 Zeichen kannst du einiges konfigurieren..

Wenn dann sind es ohnehin eher 65536 Zeichen.

ich bin so dumm..

Zeus

Ausserdem:

Wenn diese Dateien größer als 32 KB sind, treten Probleme jedoch in einigen Fällen auf