Diskussion:XML Format

Aus Eressea
Zur Navigation springenZur Suche springen

Zur Zeit findet die Diskussion auf der Magellan-Beta Mailingliste statt. Gib uns deine Email-Adresse hier als Kommentar, und wir fuegen dich dazu. Oder verlagern die Diskussion. Enno 10:58, 22. Apr 2008 (CEST)

Allgemeines

Historische Daten

Jedes XML-Dokument beschreibt den Spielstand zu einem Zeitpunkt (eine Runde), nicht mehrere. Es gibt kein @turn Attribut. Um historische Daten zu verwenden, liest der Client mehrere XML-Dokuemnte (die z.b. als ZIP-Datei kompiliert sein koennen). -- Enno 16:47, 22. Apr 2008 (CEST)

id vs. key

Wir benutzen das xml:id-Attribut, um die wichtigsten Spiel-Objekte eindeutig identifizieren zu können. Diese IDs werden vom Server vergeben, und der Client darf keinerlei Angaben ueber ihren Aufbau machen. Sie sind nicht identisch mit den Einheiten-Nummern, welche in einem key-Attribut gespeichert werden, welches keine eindeutige ID innerhalb des Dokuemntes ist (weil Parteien, Gebaeude, usw. den gleichen key haben koennen). Das key-Attribut ist ein alphanumerischer Wert, dessen Format fuer jedes Spiel anders aussehen kann. -- Enno 16:47, 22. Apr 2008 (CEST)

Ist xml_id und id eigentlich das gleiche? Ich glaube nicht. -- Darcduck
Ich denke schon - aus The xml:id Conundrum zitiert: "Perhaps unfortunately, the basic c14n specification says that all attributes in the XML namespace must be imported" -- Enno
Davon abgesehen sollte es eine Logik geben nach der der Client diese IDs aus den key erzeugen kann, damit auch alte CRs in XML umgewandelt werden können -- Darcduck

Die Elemente zum referenzieren tragen sinnvollerweise ebenfalls die endung ref -- Darcduck

Dann bekommt man aber Elemente, die in ihrem Namen keine Rolle haben. Und was ist denn die "shipref" einer Einheit? Das Schiff an dem sie gerade baut? Das auf dem sie steht? Das, welches sie verfolgt? Ich finde es besser, da nicht die Tatsache, dass das Element ein ref-Attribut hat, nochmal in den Namen reinzutun, und dafuer sonst kaum info zu haben. -- Enno
Ok, sehe ich ein, denken wir uns lieber Rollen aus. Ich habe halt im Hinterkopf nicht eine Inflation von Elementen auszulösen. die Rolle der Beziehung kann man theoretisch auch über ein Attribut mitgeben (Daten über Daten). -- Darcduck
Ja, das macht eventuell auch Sinn. Irgendwo muss man da einen halbwegs sauberen Bruch machen, sonst endet man bei der Form von XML-Report, die ich mal als 1:1 Umsetzung des CR-Formates entwichelt hatte: Wichtig: View Source. -- Enno
Jupp, das ist das andere Extrem. Das Problem ist halt, die Rolle in der eine Objektreferenz auftauchen kann, kann sehr vielfältig sein - und - wir kennen sie vielleicht noch gar nicht. Das gleiche Problem haben wir bei vielen kleinen Tags. Irgendwer kommt mal auf die Idee das eine Einheit eine Farbe haben kann ... was dann? -- Darcduck
Ich habe vorhin mal alle ids mit Punkten und Doppelpunkten im Namen ersetz. Das aktuelle Format "unit_enn0", ist nicht garantiert, der Server bestimmt, was er da benutzt. Wer Lookups in der XML-Datei machen will, um eine spezielle Einheit zu finden, soll te das mit //unit[@key='enn0'] machen, nicht ueber die ID. -- Enno

<group/>

Es ist einfacher, die Gruppen nicht hierarchisch von der Partei abzuleiten. Erstens tut es der Eressea-Server auch nicht. Zweitens ist es hierarchsich viel aufwaendiger, festzustellen ob man eine Permission hat oder nicht. Und drittens wird das Format einfacher, wenn man es flach haelt. -- Enno

Dem Server will ich auch keine zusätzliche Last aufbürden. Zur Verwaltung der Helfe Stati wären Hierarchien aber hilfreich. Jeder der mehr als 2-3 Gruppen hat die auch "Frontnah" genutzt werden, kennt das Spiel. Neu verfeindetes Bündnis - HELFE Stati in allen Gruppen abändern. Ich habe einige Gruppen, die sich sehr ähnlich sind, und nur durch "ohne Helfe Silber" oder "ohne Helfe Kämpfe" von meinen Parteistati unterscheiden.

<alliance/>

Ich würde alliance nicht als Element für die Helfe Stati verwenden sondern für richtige "Parteigruppen" reservieren. Auch sowas soll es ja in Vinyambar schon gegeben haben. d.h. Ein Volk ist dann Teil genau einer (oder mehrerer Allianzen). Möglicherweise ist Allianz auch ein Konstrukt des Clients zur einfacheren Verwaltung der Helfe-Stati. -- Darcduck

Genau dafuer war es gedacht. -- Enno