Grundsätzlich sollte dann das Programm auf nicht importierte Daten
hinweisen! Steht das eigentlich im Standard von GEDCOM 7?
Du übersiehst einen wichtigen Aspekt.
Da kommt ein engagierter Hobbyprogrammierer und möchte auch ein
Genealogieprogramm schreiben. Der fängt an das für seinen Bedarf
anzupassen und kennt GEDCOM gar nicht. Er bietet das Programm dann auch
über seine Homepage der Öffentlichkeit an.
Irgendwann kommt ein Anwender, der schon die ersten paar Hundert
Datensätze eingegeben hat an die Grenzen des Programms. Der möchte die
Daten dann in ein anderes Programm übernehmen.
Wie stellst Du Dir das vor?
Genauso auch anders herum. Das Programm hat genau die
Ausgabedarstellung, die ich mir seit langem wünsche. Für meinen Bedarf
sind die vorhandenen Eingabefelder im Programm vorhanden, tiefgreifende
Einzelinformationen (UID, Geolokationen, etc.) sind dafür nicht
erforderlich.
Da wäre es doch super, wenn beim Import diese Daten aus den deutlich
umfangreicheren GEDCOM 7 Daten übernommen werden und ich nicht alle
Daten neu eingeben muss.
So ist mein Verständnis und so arbeitet mein Programm.
Wenn ich irgendwann auch den Im-/Export nach dem Standard von GEDCOM 7
anbiete, steht irgendwo die Angabe zum verwendeten Standard. Ich werde
sicher nicht behaupten, alles zu unterstützen. Aber das Programm
unterstützt dann sehr wohl GEDCOM 7. Halt nicht vollständig.
Nur so ist (aus meiner Sicht) gewährleistet, dass Anwender überhaupt
Daten austauschen können und nicht immer wieder von vorn beginnen müssen.
Im Extrembeispiel einer GEDCOM Datei ohne jegliche genealogische Daten wird zwar formal der GEDCOM Standard erfüllt. Zu unterscheiden von der Konformität einer Datei mit dem Standard ist der Umfang an den Strukturen des Standards, den ein Programm unterstützt.
Wer einmal probieren will, inwieweit sein Programm den aktuellen Standard GEDCOM 7.0 unterstützt, kann die vom GEDCOM Team bereitgestellte Datei
https://gedcom.io/testfiles/gedcom70/maximal70.ged
in sein Programm importieren, und dann mal sehen, ob er alle Elemente, die in der Datei vorhanden sind, in seinem Programm wiederfindet - und wie das dann nach Änderungen genealogischer Daten (erlaubt das Programm das für die Inhalte der Datei überhaupt??) die wieder exportierte Datei aussieht. In der Datei wurde versucht, jede im Standard GEDCOM 7.0 definierte Struktur mindestens einmal auftreten zu lassen.
Wer sich direkt auf den Seiten für den GEDCOM Standard ansehen will, was zur Konformität gesagt wird:
https://gedcom.io/compatibility/
Der Standard legt fest, wie die GEDCOM Dateien auszusehen haben. Es gibt einige Empfehlungen im Standard, was in bestimmten Situationen gemacht wreden soll (wenn z.B. Informationen in einem Standard-Kennzeichen solchen in einer Erweiterung widersprechen: Dann hat das Standard-Kennzeichen Priorität).
Der Standard legt aber weder fest, welche Strukturen ein Programm unterstützen muss (Ausnahme HEAD und TRLR) oder wie mit nicht unterstützten Strukturen umzugehen ist. Das ist Sache des Programmautors.
Auch die Gedcom-L hat in ihrem ADDENDUM nichts darüber vereinbart, was mit nicht unterstützen Umfängen beim Import gemacht werden soll.
Die Idee finde ich gut!
Allerdings wäre es nicht einfach, die Beiden Dateien danach wieder zu
vergleichen, da ich nicht direkt mit der GEDCOM-Datei arbeite sondern
die Daten in meine interne Struktur übernehme und die Daten dann neu
(und ggf. in anderer Reihenfolge) wieder in eine GEDCOM-Datei schreiben
würde.
Ein Vergleich wäre dann nicht ganz einfach.
„Der Anbieter muss die Fähigkeit nachweisen, eine FamilySearch
GEDCOM-Datei zu lesen und zu schreiben, und nachweisen, dass das
Ergebnis gültig ist FamilySearch GEDCOM 7.“
Wem gegenüber muss ich das den nachweisen?
„Der Anbieter muss nachweisen, dass er die Datei maximal70.ged lesen und
den Inhalt in seiner eigenen Umgebung anzeigen kann.“
Gleiche Frage.
Hinzu kommt, wieviel der Datei muss ich denn anzeigen können? Den
kompletten Inhalt?
„Der Anbieter muss nachweisen, dass er in der Lage ist, eine
Beispiel-FamilySearch GEDCOM-Datei zu schreiben und zu beweisen, dass
sie gültig ist FamilySearch GEDCOM 7. Beispielsweise kann der
GEDCOM-Validator verwendet werden, obwohl er sich noch in der Beta-Phase
befindet.“
Auch hier. Es wird nicht über den Inhalt ausgesagt. Reicht es, wenn ich
eine Person (ein INDI-Record) und einen Submitter-Record exportiere?
Zu GEDZIP:
Bin ich nicht GEDCOM 7-konform, wenn ich nur die Textvariante ohne ZIP
unterstütze?
Das kann alles lediglich zu dem auf der Seite erwähnten
Kompatibilitätswert führen. Finde ich OK.
Wenn ich den kleinsten Kompatibilitätswert erhalte, habe ich dann einen
GEDCOM 7 Export?
Ich denke, es ist müßig hier solche Spitzfindigkeiten zu diskutieren.
Der Ansatz, einen Kompatibilitätswert zu generieren dient allenfalls dem
Anwender als Anhaltspunkt wie vollständig seine Daten von einem in ein
anderes Programm übertragen werden kann.
Allerdings habe ich keine Ahnung, wie der Kompatibilitätswert errechnet
wird. So würde ich erwarten, dass die Unterstützung der wesentlichen
Personendaten einen größeren Anteil am Kompatibilitätswert haben sollte
und somit eine Art Gewichtung der GEDCOM-Information erfolgt. - Auch
hier wieder ein Punkt, der eine Menge Diskussionsstoff liefert.
Dem Anwender gegenüber, der den Test ausführt.
Genau vor dem Hintergrund gibt es keine allgemein gültige Aussage zur Konformität, die für alle Anwender gleichermaßen gilt. Da die Anwender sehr unterschiedliche Erwartungen an Programme haben, kann ein Programm für einen Anwender völlig ausreichend sein, für den nächsten völlig unzureichend.
Um beim Hauptthema UID zu bleiben: Wenn der Anwender häufiger Daten mit Kollegen in beiden Richtungen austauscht und dabei auf beiden Seiten an den Daten weitergearbeitet wird, ist die UID eine sehr wesentliche Struktur, um die Datensätze wiedererkennen zu können. Diese Anwender werden also Wert darauf legen, dass die UID unterstützt werden.
Wer GEDBAS und/oder Online-OFB bedienen möchte, wird Wert darauf legen, dass zumindest die UID bei Personendatensätzen unterstützt werden.