Sanddorn wrote:
Ich denke aber, dass man solche Dinge auch anders realisieren kann - z.B.
mit XML oder vielleicht doch mit "C"?
XML ist keine Programmiersprache sonderen eine Textdatei mit besonderem Aufbau.
Dieses Genealogie-Programm hat bereits heute die Fähigkeit, Daten aus vielen
anderen Genealogie-Programmen direkt auszulesen.
Klar, weil es des Aufbau der Daten kennt (entweder beim Programmhersteller erfragt oder selber erarbeitet) und entsprechende Routinen eingebaut hat. Das kann im Prinzip jeder Programmierer. Nur wozu, wenn es ein definiertes Austauschformat gibt?
Und das (soweit ich weiß) mit Hilfe von XML.
Nein.
XML hat damit nichts zu tun.
Es mag allenfalls sein, dass deren GenBridge Laderoutinen der entsprechenden Programme enthält und als Ergebnis eine XML-Datei erzeugt. Genausogut könnten sie auch eine Gedcomdatei erstellen.
Doch möglicherweise beherrschen diese Programme ja neben der
Genbridge-Technologie auch noch GEDCOM.
Die besagten Programme kennen möglicherweise die GenBidge gar nicht, nötig ist es jedenfalls nicht. GenBidge ist nicht einmal ein Standard. Das ist etwas, was sich eine Firma ausgedacht hat und vermarktet. Womit ich kein Problem habe.
Es aber als Weg der Zukunft zu erklären, halte ich für völligen Nonsens. GenBridge hat dieselbe Problem wie Gedcom. Sie fallen nur nicht auf, weil nur wenige Programme/Programmformate unterstützt werden. Diese haben dann auch keine Funktionen, die in TMG nicht vorhanden sind. So fallen die Probleme auch nicht auf.
Im übrigen bietet GenBridge keinen Export. Wie willst Du da einen Austausch erreichen?
Und - was in den Staaten machbar ist, müßte man doch hier auch mal versuchen
zu realisieren.
Was ist denn da machbar?
Der Programmierer baut Laderoutinen anderer Programme ins Programm. Toll. Hatte ich auch schon. Was bringt das? Ist doch alles eine Einbahnstraße.
Noch ein par Sätze zur relationalen Datenbank MS ACCESS:
Aus dieser Datenbank kann man den Inhalt der Datenfelder in einer Textdatei
speichern.
Es müßte sodann möglich sein, aus dieser Textdatei (die ja einer
GEDCOM-Datei ähnlich ist) in andere Genealogie-Programme zu importieren.
Klar.
Bieten viele als Excel- oder CSV-Import (und Export) an.
Insofern wären wir wieder bei XML.
Erklär mir doch mal den großen Vorteil von XML und was davon nicht mit Gedcom 5.5 machbar ist.
MfG, Metti.
PS: Da Du immer TMG erwähnst, habe ich mir kurz die Demo angesehen. Der Gedcomexport kann kein UNICODE, lediglich ANSEL entspricht der Gedcomdefinitio, IBM-PC und ANSI sind sogar definitif nicht erlaubt. Ansel hilt nur, wenn man keine Zeichen benötigt, die in Ansel nicht vorkommen. Wie soll man damit einen vernünftigen Datenaustausch hinbekommen?
Beim Import funktioniert anscheinend auch nur ANSEL (ANSI und IBM-PC habe ich nicht getestet)
Mich wundert nicht, dass die Hersteller für den Import zusätzliche Möglichkeiten bieten.
Ich habe eine Person mit einem Rufnamen versehen und beim Export zugegebenermaßen auf eine Krücke zurückgegriffen, die aber viele deutsch Programme beherrschen. Der Rufname ist in _ (Unterstrich) gefasst. TMG kennt das nicht und importiert "fehlerhaft".
Damit möchte ich sagen, auch TMG kann nicht raten, was gemenit ist, wenn es das nicht weiß. Immer wenn unbenakkte Daten auftauchen kommt es zu Problemen. Mal Kleinere mal Größere. Da hilft werder GenBidge noch XML sondern nur eine gute Definition und der Wille der Programmierer diese umzusetzen. Wenn ich aber sehe, wie wenig Genealogieprogramme sich an die Gedomdefinition halten (allein schon bei der Zeichenkodierung, s.o.) und kaum Unicode unterstützen, sehe ich hier noch einen weiten, steinigen Weg.
