Vorteile eines xml-Austauschformats

jzedlitz · November 26, 2006, 11:06am

Nachdem neulich die Diskussion um ein xml-Austauschformat sich eher auf das
Datenmodell verlagerte, mï¿½chte ich nun doch nochmal einen Thread zum Thema
xml starten.

Hier sind ganz neutral die Vorteile aufgefï¿½hrt, die ein xml-Austauschformat
mit sich bringen wï¿½rde:

== Zeichensatzprobleme ==
Lï¿½sungen fï¿½r "nicht ASCII Zeichen" existieren bei der xml und sind ausgiebig
erprobt. Besonders elegant kommt man mit erweiterten Zeichen klar, wenn man
sie als numeric character references (&#1234 schreibt, dann kommen sie in
jedem Fall richtig an.

== Validierung ==
xml Dokumente lassen sich automatisch prï¿½fen. Man kann eindeutig sagen, ob
eine Datei gï¿½ltig ist oder nicht. Ein weiches "Vielleicht" wie bei Gedcom
gibt es nicht. Es gibt zwar auch eine Grammatik fï¿½r Gedcom, nur liegt die
nicht in einem ï¿½blichen Format vor, und man mï¿½ï¿½te sich erst einen eigenen
Validator schreiben. Auï¿½erdem wird bei Gedcom Struktur und Inhalt vermischt,
diese Vorgaben sind in der existierenden Grammatik nicht abgebildet.

== Erweiterungen ==
xml Dokumente lassen sich leicht mit Elementen aus anderen Namensrï¿½umen
erweitern. Man kï¿½nnte z.B. genealogische Informationen mit bestehenden
Techniken digital signieren. Es erhï¿½ht den "Wert" einer Information enorm,
wenn die Herkunft zweifelsfrei sichersteht und der Forscher als sorgfï¿½ltig
bekannt ist.

== Speicherung ==
Viele Datenbanken bieten die Mï¿½glichkeit an, xml-Dokumente direkt
abzuspeichern und darin zu Suchen. Es ist also nicht einfach nur ein Text,
sondern man kann gezielt (und schnell) auf einzelne Informationen zugreifen.

== Verarbeitung ==
Fï¿½r die Verarbeitung von xml-Dokumenten gibt es sehr gute Software. Je nach
Einsatzzweck kï¿½nnen das sehr einfache Pullparser sein, so daï¿½ man "dicht an
den Daten" ist oder Frameworks, die ganze Dokumente in Objekte der
Programmiersprache ï¿½bersetzen, so daï¿½ man mit den xml-Dokumenten selbst gar
nichts zu tun hat.

Gruï¿½
Jesper

- --
Jesper Zedlitz E-Mail : jesper@zedlitz.de
Homepage : http://www.zedlitz.de
ICQ# : 23890711

Gerd_Schmerse · November 26, 2006, 12:16pm

Moin Jesper Zedlitz,

zur Mail vom Sun, 26 Nov 2006 12:06:06 +0100:

Hier sind ganz neutral die Vorteile aufgef�hrt, die ein xml-Austauschformat
mit sich bringen w�rde:

Die Auflistung ist ganz sicherlich v�llig korrekt, und ebenso ist es
sicherlich wissenschaftlich korrekt, dies als bessere Methode vorzuschlagen
oder zu fordern. Was dagegen spricht, d�rfte die Macht des Marktes sein...
Ich sehe hier einen �hnlichen Widerspruch wie zwischen "guter" Software und
Microsoft (ohne hier einen Nebenkriegsschauplatz er�ffnen zu wollen) - man
kann sich zwar pers�nlich bem�hen, daran vorbeizukommen, aber an der
Tatsache des de-facto-Standards �ndert dies nichts. Kaum ein Autor wird ein
zus�tzliches Austauschformat implementieren, wenn es mit Gedcom doch auch
geht (vergi� nicht: "Wir haben uns immer irgendwie durchgewurschtelt" ist
entgegen allen gro�artigen Qualit�tsstatements immer noch das Grundprinzip
dieser Gesellschaft) und er seine (immer) knappe Zeit in (immer) notwendige
andere Verbesserungen des Programms stecken kann. Und auch das gro�e neue
PAF 6 (Arbeitstitel, ich wei� nicht ob es wirklich so hei�en wird), das
eine globale Datenbank mit online-Eingabe vorsieht (und sogar teilweise
Deinem weitergehenden Datenmodell folgt, Stichwort "dispute"), wird
weiterhin einen Gedcom-Upload unterst�tzen.

Gru�
Gerd (Schmerse)
Moderator Neumark-L/Leiter FST Neumark

Stefan_Mettenbrink1 · November 26, 2006, 12:32pm

Jesper Zedlitz wrote:

== Zeichensatzprobleme =Lösungen für "nicht ASCII Zeichen" existieren bei der xml und sind ausgiebig erprobt.

Das gilt ebenso für Unicode in Gedcom. Wenn manche Programme damit Probleme haben, liegt das nicht am Datenformat.

== Validierung =xml Dokumente lassen sich automatisch prüfen. Man kann eindeutig sagen, ob eine Datei gültig ist oder nicht. Ein weiches "Vielleicht" wie bei Gedcom gibt es nicht. Es gibt zwar auch eine Grammatik für Gedcom, nur liegt die nicht in einem üblichen Format vor, und man müßte sich erst einen eigenen Validator schreiben. Außerdem wird bei Gedcom Struktur und Inhalt vermischt, diese Vorgaben sind in der existierenden Grammatik nicht abgebildet.

Den Vorteil kann ich auch erkennen. Betrifft allerdings nur die Struktur. Wenn jemand in Gedcom als CHAR ANSI angibt ist das erkennbar falsch, es stört nur niemanden. Das könnte auch in XML passieren.

== Erweiterungen =xml Dokumente lassen sich leicht mit Elementen aus anderen Namensräumen erweitern. Man könnte z.B. genealogische Informationen mit bestehenden Techniken digital signieren. Es erhöht den "Wert" einer Information enorm, wenn die Herkunft zweifelsfrei sichersteht und der Forscher als sorgfältig bekannt ist.

Erweiterungen sind auch in Gedcom möglich.
Für beide gilt; es fehlt eine anerkannte Definition.

== Speicherung =Viele Datenbanken bieten die Möglichkeit an, xml-Dokumente direkt abzuspeichern und darin zu Suchen. Es ist also nicht einfach nur ein Text, sondern man kann gezielt (und schnell) auf einzelne Informationen zugreifen.

Dazu kann ich mangels Wissen nichts sagen. Ob das ein wirklicher Vorteil ist, wage ich anzuzweifeln.

== Verarbeitung =Für die Verarbeitung von xml-Dokumenten gibt es sehr gute Software. Je nach Einsatzzweck können das sehr einfache Pullparser sein, so daß man "dicht an den Daten" ist oder Frameworks, die ganze Dokumente in Objekte der Programmiersprache übersetzen, so daß man mit den xml-Dokumenten selbst gar nichts zu tun hat.

Hat mit Genealogie nichts zu tun.
Gedcomdateien sind Textdateien. Dafür gibt es auch reichlich Programme. Sie sind aber im Regelfall nur wenig geeignet zu Bearbeitung der enthaltenen Daten. Das erwarte ich auch von den meisten Programmen, die "XML verstehen".

*Mein* Fazit:
Kein Vorteil gegenüber Gedcom.
Größter Nachteil: Keine anerkannte Definition vorhanden.

MfG, Metti.

Herbert_Penke2 · November 26, 2006, 4:33pm

Hallo
ich bin der Meinung das hier ein guter Vorschlag von Jesper gemacht wurde.
Es ist schade dass er gleich wieder zerredet wird.
Irgendwie erinnert mich das mal wieder an das Gutachten eines Professors �ber die ersten Gl�hlampe, mit den Tenor "die Gl�hlampe hat keine Zukunft"
Ich weis nicht welche Kontakte zu Ausl�ndischen Vereinen bestehen?
Unser Verein sollte mal Vorreiter sein und einen gemeinsamen europ�ischen Vorschlag machen und nicht nur auf die Mormonen warten.
MfG Herbert Penke

EvRenesse · November 26, 2006, 4:41pm

Hallo,

in unserer Runde waren wir noch nicht einmal in der Lage, uns auf einen simplen Gedcom-Tag f�r den Status der Partnerschaft (verheiratet/nicht verheiratet) zu einigen. Wie sollen wir da Vorreiter f�r eine europ�ische Bewegung werden? Ich glaube nicht, dass wir das k�nnen.

Ekkehart v. Renesse

-----Urspr�ngliche Nachricht-----

Stefan_Mettenbrink1 · November 26, 2006, 5:08pm

Ekkehart v. Renesse wrote:

in unserer Runde waren wir noch nicht einmal in der Lage, uns auf einen simplen Gedcom-Tag für den Status der Partnerschaft (verheiratet/nicht verheiratet) zu einigen. Wie sollen wir da Vorreiter für eine europäische Bewegung werden? Ich glaube nicht, dass wir das können.

Schade eigentlich

Meiner Meinung nach wäre es das Beste, jemand macht sich wirklich Gedanken und erstellt eine Dokumentation für eine GedcomXML-Definition. Diese kann dann diskutiert werden und ggf. verbessert/geändert werden. Wichtig ist, die Dokumentation muss offen zugänglich und festgeschrieben sein.

Egal, ob alle der Meinung sind, dass alles gelungen ist, wenn diese Dokumentation als "gültige Definition" festgelegt wird (egal von wem, wage ich zu behaupten) wird man das auch nutzen. Es muss nur einer machen.
Geschickt wäre es, wenn es nicht ein Programmanbieter sondern eine Institution oder ein Verein macht.

MfG, Metti.

Stefan_Mettenbrink1 · November 26, 2006, 5:12pm

Herbert Penke wrote:

Unser Verein sollte mal Vorreiter sein und einen gemeinsamen europäischen Vorschlag machen und nicht nur auf die Mormonen warten.

Wär ich dafür!

MfG, Metti.

anon49534610 · November 26, 2006, 5:25pm

Hallo zusammen,
zweifellos ist das ein guter Vorschlag.

Leider geht er am Problem Datenaustausch v�llig vorbei.

Das Problem ist ja nicht Gedcom, sondern zum einen fehlende Felder ("was ich
nicht verarbeiten kann lese ich auch nicht ein"), zum anderen
unterschiedliche Auslegung eines zugegebenerma�en schwammigen Standards.

Da hilft es nichts, ein anderes Format zu nehmen.

Wenn schon unbedingt XML, dann soll doch Jesper hergehen und einen Entwurf
machen. Den k�nnen dann die deutschen Programmautoren begutachten und
erweitern. Dann verpflichten sich eine ausreichende Anzahl Programmautoren,
bis zu einem bestimmten Zeitpunkt f�r ihr Programm einen XML Im- und Export
zu machen.

F�llig werdende Erweiterungen k�nnen bekannt gegeben werden (von den
Autoren) und Teil des Standards werden.

Damit ist der Standard ohne gro�e B�rokratie flexibel.

Unter diesen Umst�nden w�re ich dabei. Ansonsten halte ich diese ganze
Diskusion f�r �berfl�ssig..

Viele Gr�sse

Gisbert (Berwe)

Stefan_Mettenbrink1 · November 26, 2006, 6:28pm

Gisbert Berwe wrote:

Unter diesen Umständen wäre ich dabei. Ansonsten halte ich diese ganze
Diskusion für überflüssig..

Dem könnte ich mich anschließen.

Da Jesper sich mit XML ja recht gut aus zu kennen scheint und für eine andere Art Implementierung wirbt, würde auch ich ihn bitten den Anfang zu machen.

Da wir hier ein deutsches Forum sind und es um deutsche Programme geht, würde ich eine deutsche Definition faforisieren.

MfG, Metti.

brudorf · November 26, 2006, 6:30pm

Hallo XML - Freaks,

XML ist eine Erweiterung von HTML, mit dem Zusatz, das
man Daten in Form einer Datenbank (mit vorher definierten Datenfeldern!)
ablegen kann. Der "Knackpunkt" ist die DATENSTRUCKTUR !!!!!.

Jedes Ahnenprogramm hat verschiedene Eingabefelder bzw. eine
UNTERSCHIEDLICHE Anzahl von Datenfeldern. Dadurch ist immer noch
nicht ein 100%iger Austausch m�glich.

Man kann nun ein XML-Datenformat definieren, das alle Felder ALLER
Ahnenprogramme beinhaltet. Dann mu� nat�rlich jeder Programmautor
sein Programm so "umr�sten" , das GENAU diese Datenfelder vorhanden
sind. Das w�rde hei�en 20 oder 30 Programmautoren "basteln" jeweils
Ihr eigenes Programm mit ein und der selben Datenstrucktur.

Dann kann sich auch eine Firma hinsetzen und ein v�llig neues
Programm erstellen, das dann auch wirklich alle Ahnenforscher nutzen,
und wenn es auch 1.000 Euro kostet.

Es ist nun mal so, das der Anwender entscheidet, wieviel Ihm das
Hobby wert ist. Der eine will am besten eins, das gar nichts kostet
(daf�r nat�rlich seine Einschr�nkungen hat), der andere kauft sich
eins f�r 100,- Euro und das ist nur in englisch.
�berhaupt wird immer wieder auf die Programme auf �bersee verwiesen,
und man m��te sich doch nach denen richten. Warum ?

XML braucht auch einen Browser (m��te also auch in jedem Programm
integriert werden). Ich glaube kaum, das sich ein Ahnenforscher
zus�tzlich noch eine gutes XML-F�higes Programm kauft, wobei hier
immer noch kein "Datenaustausch" zu seinem eigenen Programm m�glich ist.

Mit freundlichen Gr��en
Karsten Rudorf
Autor von "Ahnenforschung mit RS-AHNEN"

Jesper Zedlitz schrieb:

Stefan_Mettenbrink1 · November 26, 2006, 7:09pm

Karsten Rudorf wrote:

XML ist eine Erweiterung von HTML, mit dem Zusatz, das
man Daten in Form einer Datenbank (mit vorher definierten Datenfeldern!)
ablegen kann. Der "Knackpunkt" ist die DATENSTRUCKTUR !!!!!.

Deine Ausführungen sind richtig.
Es geht aber nicht vorrangig um einen universellen, überall funktionierenden Datenaustausch (so gern ich ihn hätte, auch ich sehe das als utopisch). Es geht darum, dass Gedcom 5.5 nicht alles bietet, was wünschenswert ist und die LDS kein Interesse an der Weiterentwicklung hat. Also wäre es naheliegend, ein Austauschformat zu definieren, dass die Unzulänglichkeiten von Gedcom nicht hat. Hier ist XML sicher ein guter Ansatz. Es fehlt aber die Definition der Struktur.

Gern würde ich auch einfach bei Gedcom bleiben und den Standard nur erweitern. So wie es mit Gedcom EL ja schon gemacht wird. Leider ist die Akzeptanz nicht sehr hoch. Gedcom selbst ist ja auch in der Hand der LDS und somit haben wir nicht wirklich die Möglichkeit einen neuen Gedcomstandard zu definieren. Bleibt also nur der Ausweg einer eigenen, offenen zugänglichen Definition.

MfG, Metti.

brudorf · November 26, 2006, 7:33pm

Stefan Mettenbrink schrieb:

Gisbert Berwe wrote:

Unter diesen Umst�nden w�re ich dabei. Ansonsten halte ich diese ganze
Diskusion f�r �berfl�ssig..

Wenn eine entsprechende Dateidefination erstellt wird, auch der
Quellcode zum einlesen und schreiben, habe ich kein Problem hier
mit zumachen.

Da Jesper sich mit XML ja recht gut aus zu kennen scheint und f�r eine andere Art Implementierung wirbt, w�rde auch ich ihn bitten den Anfang zu machen.

Einer mu� ja, am besten auch einen Tip dazu, wo welche Daten abgelegt
werden m�ssen, wenn das Programm die Felder nicht hat.
In ein Textfeld ? Wohin dann beim erneuten erstellen einer XML-Datei ?
(Ursprungsfeld ist ja dann nicht mehr bekannt!)

Da wir hier ein deutsches Forum sind und es um deutsche Programme geht, w�rde ich eine deutsche Definition faforisieren.

Bin ich auch daf�r ! Verwenden wir doch einfach eindeutige DEUTSCHE
TAG's oder Definationsfelder ! (�h..., was machen wir dann mit den
Nutzer von englichsprachiger Software ?)

Mit freundlichen Gr��en
Karsten Rudorf

brudorf · November 26, 2006, 7:53pm

Gern w�rde ich auch einfach bei Gedcom bleiben und den Standard nur erweitern. So wie es mit Gedcom EL ja schon gemacht wird. Leider ist die Akzeptanz nicht sehr hoch. Gedcom selbst ist ja auch in der Hand der LDS und somit haben wir nicht wirklich die M�glichkeit einen neuen Gedcomstandard zu definieren. Bleibt also nur der Ausweg einer eigenen, offenen zug�nglichen Definition.

MfG, Metti.

Ja, GEDCOM ist der Standart der Mormonen, gr��tenteils auf die
deutschen Anwender orientierten Programme nicht immer zutreffend.
Siehe hier nur die "Patenverwaltung". Oder die Schweizer mit ihren
"B�rgerorten" usw. Eine Erweiterung in EL hat auch nicht viel gebracht.

Mit freundlichen Gr��en
Karsten Rudorf

Stefan_Mettenbrink1 · November 26, 2006, 8:17pm

Karsten Rudorf wrote:

Wenn eine entsprechende Dateidefination erstellt wird, auch der
Quellcode zum einlesen und schreiben, habe ich kein Problem hier
mit zumachen.

Quelltexte kannst Du wohl vergessen. Oder hilft Dir REALBasic?
Ich bin schon mit einer ordentlichen Definition zurfieden.

Einer muß ja, am besten auch einen Tip dazu, wo welche Daten abgelegt
werden müssen, wenn das Programm die Felder nicht hat.
In ein Textfeld ? Wohin dann beim erneuten erstellen einer XML-Datei ?
(Ursprungsfeld ist ja dann nicht mehr bekannt!)

Das ist das Problem. Dafür wird es wohl keine Lösung geben.

Man könnte allenfalls programmintern die Original-xml-Datei zwischenspeichern und bei einem Export die veränderten und hinzugekommenen Daten in die xml-Datei einfügen ohne die unbekannten Informationen einer Person anzutasten. Ob und wie weit das machbar ist, kann ich noch nicht beurteilen.

Bin ich auch dafür ! Verwenden wir doch einfach eindeutige DEUTSCHE
TAG's oder Definationsfelder ! (Äh..., was machen wir dann mit den
Nutzer von englichsprachiger Software ?)

Denen stellen wir selbstverständlich unsere Dokumentation zur Verfügung. So macht es die LDS doch auch. Wer es nutzen möchte, darf es gern, übersetzen muss er selbst. Geht mir doch nicht anders.
Ich habe nichts gegen englische Tags, aber für mich ist eine deutsche Definition leichter verständlich.

MfG, Metti.

Stefan_Mettenbrink1 · November 26, 2006, 8:20pm

Karsten Rudorf wrote:

Ja, GEDCOM ist der Standart der Mormonen, größtenteils auf die
deutschen Anwender orientierten Programme nicht immer zutreffend.
Siehe hier nur die "Patenverwaltung". Oder die Schweizer mit ihren
"Bürgerorten" usw. Eine Erweiterung in EL hat auch nicht viel gebracht.

Das meinte ich. Darum wäre es auch sinnvoll, etwas komplett neues auf die Beine zu stellen, das diesese Probleme nicht hat.

Es fängt bei Gecom ja schon mit der Zeichenkodierung an. Da sind die europäischen Sprachen nur mit Unicode sinnvoll nutzbar.

MfG, Metti.

brudorf · November 26, 2006, 9:13pm

Stefan Mettenbrink schrieb:

Karsten Rudorf wrote:

Ja, GEDCOM ist der Standart der Mormonen, gr��tenteils auf die
deutschen Anwender orientierten Programme nicht immer zutreffend.
Siehe hier nur die "Patenverwaltung". Oder die Schweizer mit ihren
"B�rgerorten" usw. Eine Erweiterung in EL hat auch nicht viel gebracht.

Das meinte ich. Darum w�re es auch sinnvoll, etwas komplett neues auf die Beine zu stellen, das diesese Probleme nicht hat.

Es f�ngt bei Gecom ja schon mit der Zeichenkodierung an. Da sind die europ�ischen Sprachen nur mit Unicode sinnvoll nutzbar.

Das h�ngt sicherlich auch damit zusammen, welcher Tastaturteiber
in "Windows" installiert ist. Fr�her habe ich gerne
den deutschen Tastaturtreiber und den englischen Zeichensatz
installiert. Heute unter Windows beides nur deutsch. Daher diese
UNICODE u. ASCCI u. ANSI Unterscheidung. Das liegt aber im
ermessen des "Windowsanwenders".
Demnach m��te also der Zeichensatztreiber ber�cksichtigt werden,
der gerade installiert ist. Aber hier gibt es den DOS und den
Windows Treiber. Welcher soll verwendet werden ? Wie soll die
Abfrage geschehen, welcher auf dem jeweiligen PC installiert ist ?
Dem Anwender �berlassen ? Nein, der hat manchmal ja schon bei der
Eingabe im Ahnenprogramm Probleme. Also auch kein au�er acht
zu lassendes Problem (daher gibt es ja die vielen Schwierigkeiten
bei den Umlauten in den GEDCOM-Dateien!).

MfG Karsten Rudorf

Stefan_Mettenbrink1 · November 26, 2006, 9:34pm

Karsten Rudorf wrote:

Es fängt bei Gecom ja schon mit der Zeichenkodierung an. Da sind die europäischen Sprachen nur mit Unicode sinnvoll nutzbar.

Das hängt sicherlich auch damit zusammen, welcher Tastaturteiber
in "Windows" installiert ist.

Nein!
Das hängt davon ab, welches Betriebsysytem man nutzt, welches Programm man nutzt und was das Progamm kann.

Auch unter Windows gibt es Programme, die den vollen Zeichenumfang von Unicode unterstützen. Wie sich die Eingabe gestaltet hängt wiederum vom Betriebssystem und dem Programm ab. Da spielt dann möglicherweise die Tastatureinstellung/Landeseinstellung mit rein.

Früher habe ich gerne
den deutschen Tastaturtreiber und den englischen Zeichensatz
installiert. Heute unter Windows beides nur deutsch. Daher diese
UNICODE u. ASCCI u. ANSI Unterscheidung

ANSI gibt es in Gedcom nicht.

Das liegt aber im ermessen des "Windowsanwenders".

Nein. (s.o.)
Aus den folgenden Fragen entnehme ich, dass Du Dich noch nicht genauer mit der Zeichencodierung befasst hast und von festen Vorgaben ausgehst. Das solltest Du vermeiden.
Du kannst davon ausgehen, dass es in Europa viele verschiene Sprachen gibt und viele Anwender mit tschechischen, polnischen, russischen, frazösischen, deutschen und vielen anderen Sonderzeichen arbeiten müssen, weil sie die entsprechenden Namen in ihrer Forschung finden. Sich hier auf etwas anders als Unicode/UTF-8 zu verlassen wäre sehr kurzsichtig.

Was das für den Anwender bedeutet, hängt vom Betriebssystem ab. Ich denke, DOS scheidet aus (oder unterstützt DOS Unicode?). Generell ist es bei einem aktuellen Betriebssystem aber kein Problem.

MfG, Metti.

ulrichk · November 26, 2006, 11:20pm

Hallo,
einige Anmerkungen eines nichtahnenprogrammierenden, von XML wenig Ahnung
habenden Anwenders:

Ein sehr lobenswerter Vorschlag, nicht nur zum x-ten Mal über die Begrenzungen
von Gedcom zu lamentieren, sondern das Problem konkret anzupacken und etwas
(hoffentlich) Besseres/Leistungsfähigeres auf die Beine zu stellen.

Wenn schon unbedingt XML, dann soll doch Jesper hergehen und einen Entwurf
machen.

Der Vorschlag ist ungemein naheliegend, aber: greift er nicht ein bißchen zu
kurz? Möglicherweise schüttelt Jesper sich, obwohl Informatiker, nicht mal so
eben auf die Schnelle einen Entwurf aus dem Ärmel.
Wie so oft im Leben und auch in der EDV, gibt es vermutlich mehrere Wege, das
Ziel zu erreichen. Also muß man sich erst mal über die genauen (Detail-)Ziele
und mögliche Wege dorthin (und deren jeweilige Vor- und Nachteile) klar
werden. Auf dieser Basis kann wohl ein fundierterer Vorschlag erstellt
werden.

Mein Vorschlag: Es sollen sich einige Interessierte als kleines
Arbeitskränzchen zusammentun; weitere Diskussion evtl. auf einer gesonderten,
neu einzurichtenden Mailingliste (da dieses Thema die einen oder anderen
Nur-Anwender auf dieser Liste möglicherweise überfordert bzw. schlicht und
einfach nicht interessiert).

Den können dann die deutschen Programmautoren begutachten und
erweitern.

(...)

Da wir hier ein deutsches Forum sind und es um deutsche Programme geht,
würde ich eine deutsche Definition favorisieren.

Bin ich auch dafür ! Verwenden wir doch einfach eindeutige DEUTSCHE
TAG's oder Definationsfelder ! (Äh..., was machen wir dann mit den
Nutzer von englichsprachiger Software ?)

Denen stellen wir selbstverständlich unsere Dokumentation zur
Verfügung. So macht es die LDS doch auch. Wer es nutzen möchte, darf
es gern, übersetzen muss er selbst. Geht mir doch nicht anders.

Der Unterschied ist: Englisch ist eine Weltsprache und außerdem die Sprache
der EDV. Deutsch ist keines von beiden. (Man mag das bedauern oder nicht, es
ist halt einfach so.)

Ich habe nichts gegen englische Tags, aber für mich ist eine deutsche
Definition leichter verständlich.

Eine deutsche Doku ist natürlich hilfreich und wünschenswert, aber die Debatte
zu diesem Punkt greift insgesamt zu kurz.
Wenn eine XML-Definition wirkliche Akzeptanz finden soll, kann sie keine
deutsche Speziallösung sein (wie Gedcom EL), sondern sollte von vornherein so
angelegt sein, daß sie leicht Internationalisierbar ist.
Zumindest die Tags sollten englisch sein.

Ich weiß nicht welche Kontakte zu Ausländischen Vereinen bestehen?
Unser Verein sollte mal Vorreiter sein und einen gemeinsamen europäischen
Vorschlag machen und nicht nur auf die Mormonen warten.

Spätestens sobald eine erste Diskussionsgrundlage auf dem Tisch liegt, sollte
der Kontakt mit ausländischen Vereinen o.ä. gesucht werden, um eine möglichst
breite Akzeptanzbasis zu erreichen. (Kein rein deutsches "Gewächs"
produzieren!)

Viele Grüße
Ulrich Kretschmer

((PS: die gekennzeichneten Zitate stammen von verschiedenen Autoren aus diesem
Diskussionsfaden))

Stefan_Mettenbrink1 · November 27, 2006, 3:51am

Ulrich Kretschmer wrote:

Mein Vorschlag: Es sollen sich einige Interessierte als kleines Arbeitskränzchen zusammentun; weitere Diskussion evtl. auf einer gesonderten, neu einzurichtenden Mailingliste (da dieses Thema die einen oder anderen Nur-Anwender auf dieser Liste möglicherweise überfordert bzw. schlicht und einfach nicht interessiert).

Es gibt die Liste "programmierer@genealogy.net". Ich schlage diese vor.

Einwände?

Generell bin ich der Ansicht, ein komplett neues Austauschformat ist gut und wünschenswert. Aber nicht kompatibel zu Gedcom 5.5 und wird es schwer haben. Eine Erweiterung wie Gedcom EL ist einfacher und man könnte damit ebenfalls die Lücken von Gedcom schließen.
Leider wurde es nicht angenommen.

Derzeit sehe ich nicht (und mache mir auch nicht die Hoffnung), dass wir über mehr als den frommen Wunsch herauskommen.

Wenn eine XML-Definition wirkliche Akzeptanz finden soll, kann sie keine deutsche Speziallösung sein (wie Gedcom EL), sondern sollte von vornherein so angelegt sein, daß sie leicht Internationalisierbar ist.

Was ist an Gedcom EL eine deutsche Speziallösung und nicht internationalisierbar?

Spätestens sobald eine erste Diskussionsgrundlage auf dem Tisch liegt, sollte der Kontakt mit ausländischen Vereinen o.ä. gesucht werden, um eine möglichst breite Akzeptanzbasis zu erreichen. (Kein rein deutsches "Gewächs" produzieren!)

So gern auch ich dieses befürworte. Ich befürchte, wir schaffen es nicht einmal zu einer Diskussionsgrundlage.

MfG, Metti.

jzedlitz · November 27, 2006, 4:30pm

Ulrich Kretschmer wrote:

> Wenn schon unbedingt XML, dann soll doch Jesper hergehen und einen
> Entwurf machen.

Der Vorschlag ist ungemein naheliegend, aber: greift er nicht ein biï¿½chen
zu kurz? Mï¿½glicherweise schï¿½ttelt Jesper sich, obwohl Informatiker, nicht
mal so eben auf die Schnelle einen Entwurf aus dem ï¿½rmel.

Gerne nehme ich den mir zugespielten Ball an und erarbeite einen ersten
Entwurf fï¿½r ein Transferformat. Natï¿½rlich fange ich nicht bei Null an,
sondern schaue mich mal um, was es bereits an sinnvollen Ideen gibt.

Parallel werde ich Verbindung zu den Kollegen aus dem Ausland (nach Nordeuropa
habe ich bereits einige Kontakte) aufnehmen und nachfragen, ob es dort
Aktivitï¿½ten auf dem Bereich "Austauschformat" gibt.

Es macht nicht wirklich Sinn, den Entwurf in dieser groï¿½en Runde zu
diskutieren, dafï¿½r haben wir - wir Metti bereits anmerkte - die Mailingliste
http://list.genealogy.net/mailman/listinfo/programmierer
Zu der mï¿½chte ich ï¿½brigens alle an den technischen Details Interessierten
einladen. Auch wer jetzt noch kein Entwickler eines Genealogieprogrammes ist,
kann das ja noch werden. Auï¿½erdem ist es gut, wenn man weitere Leute von Fach
dabei hat - allerdings dï¿½rfen die sich nicht von sehr technischer Diskussion
abschrecken lassen.

Gruï¿½
Jesper

- --
Jesper Zedlitz E-Mail : jesper@zedlitz.de
Homepage : http://www.zedlitz.de
ICQ# : 23890711