GEDCOM/UID-Tag: Unterschied zwischen den Versionen
(→Diskussionsstand in der Arbeitsgruppe der Programmautoren: Regelung für GUID eingefügt) |
|||
Zeile 63: | Zeile 63: | ||
=== Umgang in PAF mit den UUID === | === Umgang in PAF mit den UUID === | ||
PAF hat einige Besonderheiten beim Umgang mit den UUID: | PAF hat einige Besonderheiten beim Umgang mit den UUID: | ||
*PAF bildet die UUID mit einer von RFC4122 abweichenden Routine und stellt sie ohne Bindestriche dar. | *PAF bildet die UUID mit einer von RFC4122 abweichenden Routine und stellt sie ohne Bindestriche und mit Großbuchstaben dar. | ||
*PAF exportiert seit Version 5.0 zusätzlich eine Prüfsumme mit 4 hexadezimalen Zeichen, so dass die UUID bei PAF auf 36 Zeichen (18 Byte) kommt. Das Berechnungsverfahren der Prüfsumme ist in [https://devnet.familysearch.org/docs/gedcom/ GEDCOM Global Unique Identifier] als Programm zu finden. Diese Berechnung wurde in programmunabhängiger Form in U2 übernommen und wird auch von anderen Programmen wie z.B. Legacy genutzt. | *PAF exportiert seit Version 5.0 zusätzlich eine Prüfsumme mit 4 hexadezimalen Zeichen, so dass die UUID bei PAF auf 36 Zeichen (18 Byte) kommt. Das Berechnungsverfahren der Prüfsumme ist in [https://devnet.familysearch.org/docs/gedcom/ GEDCOM Global Unique Identifier] als Programm zu finden. Diese Berechnung wurde in programmunabhängiger Form in U2 übernommen und wird auch von anderen Programmen wie z.B. Legacy genutzt. | ||
*PAF ergänzt die Prüfsumme, wenn eine UUID mit 32 hexadezimalen Zeichen angeboten wird. | *PAF ergänzt die Prüfsumme, wenn eine UUID mit 32 hexadezimalen Zeichen angeboten wird. |
Version vom 6. Mai 2011, 01:12 Uhr
Name und Bedeutung
Tag
_UID
Formelle Bezeichnung
unique ID for records
Deutsche Bezeichnung
Universelle Identifikationsnummer für Datensätze
Verwendung
Universelle Identifikationsnummern (UUID) werden verwendet, um Datensätze auch nach Weiterbearbeitung oder Export/Import wieder auffinden zu können. Eine UUID erhebt den Anspruch, dass sie weltweit und für alle Zeiten eindeutig vergeben wird, dass also keine Kollisionen ( = mehrfache Vergabe desselben Wertes ) erfolgen. Dabei erfolgt die Vergabe der UUID dezentral, d.h. durch kein übergeordnetes System koordiniert. Die Erzeugung von UUID ist in RFC4122 beschrieben. UUID können nur so lange ihre Funktion erfüllen, wie sie bei Export und Import von GEDCOM-Dateien unverändert bleiben. Aufgrund der Anforderung einer dezentralen Erzeugung und einer Kollisionsfreiheit sind UUID komplex und als direkt vom Anwender verwendetes Erkennungsmerkmal kaum geeignet. Ihre Anwendung ist daher auf die durch Programme durchgeführten Vergleiche, ob zwei Datensätze den identischen Ursprung haben, konzentriert.
Formale Beschreibung zulässiger Werte
Aussagen des GEDCOM-Standards
Der GEDCOM-Standard enthält kein explizites Kennzeichen, welches den Anforderungen an den Umgang mit UUID genügt. Daher hat zuerst PAF ein Nutzerdefiniertes Kennzeichen _UID eingeführt, welches inzwischen von einer ganzen Reihe Programmen übernommen wurde.
Am ehesten entspricht das im GEDCOM-Standard mit Version 5.5 eingeführte Kennzeichen RIN noch den Anforderungen für eine UUID. Jedoch hat RIN eine empfohlene Mindestlänge von nur 12 Zeichen, es soll eine Zahl beinhalten und es darf in Datensätzen nur maximal einmal {0:1} eingesetzt werden. Damit sind wesentliche Anforderungen an eine UUID wie in RFC4122 beschrieben nicht erfüllt.
Entscheidungsempfehlungen für Vereinbarungen zu _UID
U1 Kennzeichen für UUID
Für den GEDCOM-Export von UUID wird das Kennzeichen _UID verwendet. Dieses Kennzeichen darf beliebig oft {0:M} in jedem Datensatz verwendet werden, es steht dabei auf der Ebene 1 direkt dem Datensatz zugeordnet.
U2 Format der UUID
Die UUID besteht aus 16 Bytes (32 Hexadezimalziffern) und wird mit den Zeichen 0-9 und A-F (Großbuchstaben!) dargestellt. An diese 16 Bytes B1 bis B16 darf eine 2 Bytes lange Prüfsumme in Hexadezimaldarstellung angehängt werden, die nach folgender Vorschrift berechnet wird:
- Prüfbyte 1: [ SUMME AUS ( Bn ) ] MODULO 256 , (für n=1 bis 16)
- Prüfbyte 2: [ SUMME AUS ( (17-n) * Bn ) ] MODULO 256 (für n=1 bis 16)
U3 Erhalt der UUID bei Import/Export
Sofern ein Programm UUIDs unterstützt, müssen importierte UUIDs im Export erhalten bleiben. Werden mehrere UUID pro Datensatz unterstützt, muss auch die importierte Reihenfolge der UUID erhalten bleiben. Wird nur eine UUID je Datensatz unterstützt, so wird die zuerst aufgeführte UUID des Datensatzes importiert und die anderen werden verworfen.
U4 Umgang mit UUID, die nicht U2 entsprechen
Werden beim Import UUID vorgefunden, die nicht den Vorgaben von U2 entsprechen, so wird folgende Vorgehensweise empfohlen:
- Ist die Länge der UUID weder 32 noch 36 Zeichen, oder treten andere Zeichen als 0-9, A-F, a-f oder der Bindestrich auf, so darf die UUID verworfen werden (Abweichung von U3), sie darf durch eine neu erzeugte UUID ersetzt werden. Es wird empfohlen, dass Programme, die mehr als eine UUID pro Datensatz unterstützen, den bisherigen Inhalt unter _UID vollständig erhalten und zusätzlich eine neue _UID erzeugen, die sie als erste _UID des Datensatzes exportieren.
- Ist die Länge der UUID entweder 32 oder 36 Zeichen, und sind alle Zeichen aus dem Umfang 0-9, A-F, a-f oder Bindestrich, so wird die UUID unverändert übernommen und wieder exportiert. Es bleibt dem Programm freigestellt, intern bei der Verarbeitung der UUID Bindestriche zu entfernen oder Kleinbuchstaben in Großbuchstaben zu verwandeln. Dies darf aber die exportierte UUID nicht verändern.
- Besteht die UUID aus 36 hexadezimalen Zeichen, aber die letzten 4 Zeichen stellen keine der Berechnungsvorschrift U2 entsprechende Prüfsumme dar, so werden die ersten 32 Zeichen als signifikant gewertet und die letzten 4 Zeichen dürfen durch eine nach U2 neu berechnete Prüfsumme ersetzt oder gelöscht werden.
U5 Empfehlungen zur Erzeugung und Verwendung der UUID
- Bei der Erzeugung von UUID wird empfohlen, diese gemäß Version 1 oder vorzugsweise gemäß Version 4 der RFC4122 zu bilden. Windows-Systeme können auf CoCreateGuid() zurückgreifen.
- Zumindest für Personendatensätze sollten UUID unterstützt werden. Programme, die Verschmelzungen von Datensätzen unterstützen, sollten mehrere UUID pro Datensatz unterstützen und bei den Verschmelzungen alle UUID erhalten.
Behandlung/Darstellung schwieriger Situationen
Diskussionsstand in der Arbeitsgruppe der Programmautoren
LDS: Regelung für GUID
Von der LDS (Mormonen) wird auf der Seite der GEDCOM Spezifikationen auch eine Empfehlung gezeigt, wie eine GUID (UUID) erzeugt und angewendet werden sollte. Die in dem zitierten Dokument angegebenen "Spielregeln" für GEDCOM-UUID lauten frei ins deutsche übersetzt wie folgt:
- 1. Jeder Personen- und Familiendatensatz in der Datenbasis sollte mit einer UID versehen sein.
- 2. Diese UID sollte mit exportiert werden und bei einem Import unverändert bleiben, selbst wenn es sich um Programme unterschiedlicher Hersteller handelt.
- 3. Die UID sollte eine 16-Byte Zahl sein.
- 4. Für Windows-Anwendungen wird die CoCreateGuid() API zur Erzeugung der UID empfohlen. Für andere Plattformen wird gebeten eine Methode zu wählen, die die universelle Eindeutigkeit der UID garantiert.
- 5. Beim Verschmelzen sollen alle UID erhalten bleiben. Daraus folgt, dass ein Datensatz n UID enthalten kann.
- 6. Beim Export sollte die UID mit dem Kennzeichen _UID versehen werden und als textliche Hexadezimal-Zahl dargestellt werden. Die bei PAF mit Version 5.0 eingeführte Checksumme ist nicht vorgeschrieben, aber ihr Einsatz wird empfohlen.
Wie eine UUID gebildet werden kann
Die Aufgabe, ohne zentrale Steuerung in dezentralen Programmeinheiten Identnummern zu erzeugen, die mit außerordentlich hoher Wahrscheinichkeit weltweit einmalig sind und bleiben, kann entsprechend der in Wikipedia zu UUID beschriebenen Methoden erfolgen, Details sind in der englischsprachigen Beschreibung zu RCF 4122 zu finden. Ein UUID besteht aus einer 16-Byte-Zahl, die hexadezimal notiert und in fünf Gruppen unterteilt wird. In ihrer Normalform sieht eine UUID beispielsweise so aus:
- 550e8400-e29b-11d4-a716-446655440000
Umgang in PAF mit den UUID
PAF hat einige Besonderheiten beim Umgang mit den UUID:
- PAF bildet die UUID mit einer von RFC4122 abweichenden Routine und stellt sie ohne Bindestriche und mit Großbuchstaben dar.
- PAF exportiert seit Version 5.0 zusätzlich eine Prüfsumme mit 4 hexadezimalen Zeichen, so dass die UUID bei PAF auf 36 Zeichen (18 Byte) kommt. Das Berechnungsverfahren der Prüfsumme ist in GEDCOM Global Unique Identifier als Programm zu finden. Diese Berechnung wurde in programmunabhängiger Form in U2 übernommen und wird auch von anderen Programmen wie z.B. Legacy genutzt.
- PAF ergänzt die Prüfsumme, wenn eine UUID mit 32 hexadezimalen Zeichen angeboten wird.
- PAF verwirft die UUID, wenn die Prüfsumme nicht korrekt ist oder in der Hexadezimaldarstellung kleine Buchstaben verwendet werden. In diesen Fällen erzeugt PAF eine neue UUID.
- PAF unterstützt nur eine UUID je Datensatz (abweichend von den Empfehlungen in GEDCOM Global Unique Identifier). Enthält ein zu importierender Datensatz mehrere UUID, so wird nur die zuletzt aufgeführte UUID importiert.
In der GEDCOM-Liste wurde diskutiert, welche dieser Besonderheiten aus Kompatibilitätsgründen übernommen werden sollten.
Abweichungen vom Standard bei der Verwendung
- derzeit nicht besetzt -