GEDCOM/UID-Tag - Versionsgeschichte

Hartenthaler: /* Aussagen des GEDCOM-Standards */ Link zum Artikel GEDCOM/UID

2025-01-08T13:16:02Z

Aussagen des GEDCOM-Standards: Link zum Artikel GEDCOM/UID

← Nächstältere Version		Version vom 8. Januar 2025, 15:16 Uhr
Zeile 19:		Zeile 19:
	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 [https://tools.ietf.org/html/rfc4122 RFC 4122] (englisch) beschrieben, nicht erfüllt.		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 [https://tools.ietf.org/html/rfc4122 RFC 4122] (englisch) beschrieben, nicht erfüllt.

	Erst in der Version 7 des GEDCOM-Standards wurde das GEDCOM-Kennzeichen UID eingeführt und ersetzt nun das zuvor verwendete _UID.		Erst in der Version 7 des GEDCOM-Standards wurde das [[GEDCOM/UID\|GEDCOM-Kennzeichen UID]] eingeführt und ersetzt nun das zuvor verwendete _UID.

	== Vereinbarungen zu UID ==		== Vereinbarungen zu UID ==

Hartenthaler: /* Formale Beschreibung zulässiger Werte */ Minimale Anpassungen an GEDCOM 7.0 damit man es noch versteht.

2025-01-08T13:05:50Z

Formale Beschreibung zulässiger Werte: Minimale Anpassungen an GEDCOM 7.0 damit man es noch versteht.

Dhesmer: Engl Link entfernt

2023-09-19T15:46:59Z

Engl Link entfernt

← Nächstältere Version		Version vom 19. September 2023, 17:46 Uhr
Zeile 153:		Zeile 153:
	=== Abweichungen vom Standard bei der Verwendung ===		=== Abweichungen vom Standard bei der Verwendung ===
	_UID ist ein Nutzerdefiniertes Kennzeichen, seine Bedeutung wird über keine im GEDCOM 5.5.1 Standard festgelegte Struktur unterstützt. Somit kann es zu _UID auch keine Abweichungen vom Standard geben.		_UID ist ein Nutzerdefiniertes Kennzeichen, seine Bedeutung wird über keine im GEDCOM 5.5.1 Standard festgelegte Struktur unterstützt. Somit kann es zu _UID auch keine Abweichungen vom Standard geben.
	~~<!-- Sortierfolge auf der Kategorienseite gemäß letzten Teil des Titelpfades -> also dem Tagnamen -->~~
	[[Kategorie:GEDCOM-Tag\|{{SUBPAGENAME}}]]		[[Kategorie:GEDCOM-Tag\|{{SUBPAGENAME}}]]
	[[Kategorie:GEDCOM-Tag-Fertig abgestimmt\|{{SUBPAGENAME}}]]		[[Kategorie:GEDCOM-Tag-Fertig abgestimmt\|{{SUBPAGENAME}}]]<!-- Sortierfolge auf der Kategorienseite gemäß letzten Teil des Titelpfades -> also dem Tagnamen -->

	~~[[en:{{PAGENAME}}]]~~

AEmmerich: /* Abweichungen vom Standard bei der Verwendung */ Status "In Diskussion" entfernt

2020-03-01T10:34:22Z

Abweichungen vom Standard bei der Verwendung: Status "In Diskussion" entfernt

← Nächstältere Version		Version vom 1. März 2020, 12:34 Uhr
Zeile 156:		Zeile 156:
	[[Kategorie:GEDCOM-Tag\|{{SUBPAGENAME}}]]		[[Kategorie:GEDCOM-Tag\|{{SUBPAGENAME}}]]
	[[Kategorie:GEDCOM-Tag-Fertig abgestimmt\|{{SUBPAGENAME}}]]		[[Kategorie:GEDCOM-Tag-Fertig abgestimmt\|{{SUBPAGENAME}}]]
	~~[[Kategorie:GEDCOM-Tag-In Diskussion\|{{SUBPAGENAME}}]]~~

	[[en:{{PAGENAME}}]]		[[en:{{PAGENAME}}]]

AEmmerich: /* Abweichungen vom Standard bei der Verwendung */ Kategorie fertig abgestimmt hinzugefügt

2019-10-30T21:54:24Z

Abweichungen vom Standard bei der Verwendung: Kategorie fertig abgestimmt hinzugefügt

← Nächstältere Version		Version vom 30. Oktober 2019, 23:54 Uhr
Zeile 155:		Zeile 155:
	<!-- Sortierfolge auf der Kategorienseite gemäß letzten Teil des Titelpfades -> also dem Tagnamen -->		<!-- Sortierfolge auf der Kategorienseite gemäß letzten Teil des Titelpfades -> also dem Tagnamen -->
	[[Kategorie:GEDCOM-Tag\|{{SUBPAGENAME}}]]		[[Kategorie:GEDCOM-Tag\|{{SUBPAGENAME}}]]
			[[Kategorie:GEDCOM-Tag-Fertig abgestimmt\|{{SUBPAGENAME}}]]
	[[Kategorie:GEDCOM-Tag-In Diskussion\|{{SUBPAGENAME}}]]		[[Kategorie:GEDCOM-Tag-In Diskussion\|{{SUBPAGENAME}}]]

	[[en:{{PAGENAME}}]]		[[en:{{PAGENAME}}]]

AEmmerich: Abstimmungsergebnis 2. Runde (2019) eingebaut

2019-01-14T19:21:49Z

Abstimmungsergebnis 2. Runde (2019) eingebaut

← Nächstältere Version		Version vom 14. Januar 2019, 21:21 Uhr
Zeile 28:		Zeile 28:
	=== U1 Einsatz und Struktur für _UID ===		=== U1 Einsatz und Struktur für _UID ===
	Das Kennzeichen _UID darf beliebig oft {0:M} in jedem Datensatz verwendet werden, es steht dabei auf der Ebene 1 direkt dem Datensatz zugeordnet. Die ersten 36 Zeichen einer _UID beschreiben die Kennzeichnung. Ggfs. weitere vorhandene Zeichen sind nicht signifikant.		Das Kennzeichen _UID darf beliebig oft {0:M} in jedem Datensatz verwendet werden, es steht dabei auf der Ebene 1 direkt dem Datensatz zugeordnet. Die ersten 36 Zeichen einer _UID beschreiben die Kennzeichnung. Ggfs. weitere vorhandene Zeichen sind nicht signifikant.

			=== U2 _UID und UUID ===
			Die Erzeugung der Datensatzkennzeichnung erfolgt in der Regel auf Basis von 16 Byte langen Bitfolgen, die nach bestimmten Vorschriften erzeugt werden (UUID). Für den Export in GEDCOM-Dateien müssen diese Bitfolgen in einen Text-Wert (String) überführt werden, wofür wiederum verschiedene Darstellungsformen möglich sind. Um eine möglichst hohe Kompatibilität der Darstellung zu erreichen, wird für neu erzeugte _UID die folgende Form empfohlen:
			Der Wert der _UID 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 wird eine 2 Bytes lange Prüfsumme in Hexadezimaldarstellung angehängt, 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)

	=== U5 Empfehlungen zur Erzeugung und Verwendung der 16 Byte Bitfolgen ===		=== U5 Empfehlungen zur Erzeugung und Verwendung der 16 Byte Bitfolgen ===
Zeile 33:		Zeile 39:
	*Zumindest für Personendatensätze sollten _UID unterstützt werden. Programme, die Verschmelzungen von Datensätzen unterstützen, sollten mehrere _UID pro Datensatz unterstützen und bei den Verschmelzungen alle _UID erhalten.		*Zumindest für Personendatensätze sollten _UID unterstützt werden. Programme, die Verschmelzungen von Datensätzen unterstützen, sollten mehrere _UID pro Datensatz unterstützen und bei den Verschmelzungen alle _UID erhalten.

	== ~~Neue Entscheidungsvorschläge~~ ==		=== U7 Erhalt der _UID bei Import/Export ===
			Sofern ein Programm _UIDs unterstützt, müssen die ersten 36 Zeichen von importierten _UIDs im Export unverändert erhalten bleiben.

	==~~= U2~~ _UID ~~und UUID =~~==
	~~Die Erzeugung~~ der ~~Datensatzkennzeichnung erfolgt~~ in ~~der Regel auf Basis von 16 Byte langen Bitfolgen~~, ~~die nach bestimmten Vorschriften erzeugt~~ werden ~~(UUID)~~. ~~Für den~~ Export ~~in GEDCOM~~-~~Dateien~~ müssen ~~diese Bitfolgen in einen Text-Wert (String) überführt werden~~, ~~wofür wiederum verschiedene Darstellungsformen möglich sind~~. Um eine ~~möglichst hohe Kompatibilität der Darstellung zu erreichen~~, wird ~~für neu erzeugte~~ _UID die folgende ~~Form empfohlen~~:		== Nicht verabschiedete Entscheidungsempfehlungen für Vereinbarungen zu _UID ==
	~~Der Wert der~~ _UID ~~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 wird~~ eine ~~2 Bytes lange~~ Prüfsumme ~~in Hexadezimaldarstellung angehängt~~, die nach ~~folgender Vorschrift berechnet wird:~~		In der Abstimmung unter den Programmautoren wurde der Entscheidungsvorschlag U4 klar abgelehnt und muss daher in einer erneuten Bearbeitungsrunde neu gefasst werden. U2 und U3 haben zwar eine einfache Mehrheit erhalten, sollen aber wegen zu vieler Gegenstimmen in einem weiteren Arbeits-Durchlauf optimiert werden und erneut zur Abstimmung gestellt werden. U2 wird nun erneut zur Diskussion / Abstimmung gestellt, U3 ist aufgeteilt in U7 bis U9 und wird hier nur noch zur Dokumentation des Ablaufes gezeigt.
	*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 _UID bei Import/Export [aufgeteilt als U7-U9 neu zur Abstimmung] ===
			Sofern ein Programm _UIDs unterstützt, müssen die ersten 36 Zeichen von importierten _UIDs im Export unverändert erhalten bleiben. Werden mehrere _UID pro Datensatz unterstützt, muss auch die importierte Reihenfolge der _UID erhalten bleiben. Wird nur eine _UID je Datensatz unterstützt, so wird die zuerst aufgeführte _UID des Datensatzes importiert und die anderen werden verworfen.

			=== U4 Änderungen an _UID ===
			Für den in U3 vorgeschriebenen Erhalt der Werte der _UID werden folgende Ausnahmen zugelassen:
			*Besteht die _UID aus 36 hexadezimalen Zeichen, aber die letzten 4 Zeichen stellen keine der Berechnungsvorschrift U2 entsprechende Prüfsumme dar, so dürfen die ersten 32 Zeichen als signifikant gewertet und die letzten 4 Zeichen dürfen durch eine nach der Empfehlung in U2 neu berechnete Prüfsumme ersetzt werden.
			*Programme, die mehrere _UID pro Datensatz verwalten können, dürfen dem Datensatz eine nach der Empfehlung in U2 neu gebildete _UID an letzter Stelle hinzufügen, wenn keine _UID vorliegt oder alle _UID eine von der Empfehlung in U2 abweichende Darstellung haben.


			== Nicht verabschiedete Entscheidungsempfehlungen für Vereinbarungen zu _UID in der 2. Abstimmrunde (2019) ==

			Die Vereinbarungen U2 und U7 (ausgegliedert aus dem ursprünglichen U3) wurden in der 2. Runde verabschiedet. Keine ausreichende Mehrheit fanden dagegen die folgenden Vorschläge:

	=== U6 _UID auf Ebene 2 ===		=== U6 _UID auf Ebene 2 ===
Zeile 47:		Zeile 65:
	</source>		</source>
	exportieren. Die Vereinbarungen für die _UID auf Ebene 1 gelten auch für die Ebene 2.		exportieren. Die Vereinbarungen für die _UID auf Ebene 1 gelten auch für die Ebene 2.

	~~=== U7 Erhalt der _UID bei Import/Export ===~~
	~~Sofern ein Programm _UIDs unterstützt, müssen die ersten 36 Zeichen von importierten _UIDs im Export unverändert erhalten bleiben.~~

	=== U8 Reihenfolge bei mehreren _UID ===		=== U8 Reihenfolge bei mehreren _UID ===
Zeile 59:		Zeile 74:
	[Hinweis: U7 - U9 wurden aus dem ursprünglich vorgestellten U3 durch Trennung der Aussagen gebildet]		[Hinweis: U7 - U9 wurden aus dem ursprünglich vorgestellten U3 durch Trennung der Aussagen gebildet]

	~~== Nicht verabschiedete Entscheidungsempfehlungen für Vereinbarungen zu _UID ==~~
	In der Abstimmung unter den Programmautoren wurde der Entscheidungsvorschlag U4 klar abgelehnt und muss daher in einer erneuten Bearbeitungsrunde neu gefasst werden. U2 und U3 haben zwar eine einfache Mehrheit erhalten, sollen aber wegen zu vieler Gegenstimmen in einem weiteren Arbeits-Durchlauf optimiert werden und erneut zur Abstimmung gestellt werden. U2 wird nun erneut zur Diskussion / Abstimmung gestellt, U3 ist aufgeteilt in U7 bis U9 und wird hier nur noch zur Dokumentation des Ablaufes gezeigt.


	~~=== U3 Erhalt der _UID bei Import/Export [aufgeteilt als U7-U9 neu zur Abstimmung] ===~~
	Sofern ein Programm _UIDs unterstützt, müssen die ersten 36 Zeichen von importierten _UIDs im Export unverändert erhalten bleiben. Werden mehrere _UID pro Datensatz unterstützt, muss auch die importierte Reihenfolge der _UID erhalten bleiben. Wird nur eine _UID je Datensatz unterstützt, so wird die zuerst aufgeführte _UID des Datensatzes importiert und die anderen werden verworfen.

	~~=== U4 Änderungen an _UID ===~~
	~~Für den in U3 vorgeschriebenen Erhalt der Werte der _UID werden folgende Ausnahmen zugelassen:~~
	*Besteht die _UID aus 36 hexadezimalen Zeichen, aber die letzten 4 Zeichen stellen keine der Berechnungsvorschrift U2 entsprechende Prüfsumme dar, so dürfen die ersten 32 Zeichen als signifikant gewertet und die letzten 4 Zeichen dürfen durch eine nach der Empfehlung in U2 neu berechnete Prüfsumme ersetzt werden.
	*Programme, die mehrere _UID pro Datensatz verwalten können, dürfen dem Datensatz eine nach der Empfehlung in U2 neu gebildete _UID an letzter Stelle hinzufügen, wenn keine _UID vorliegt oder alle _UID eine von der Empfehlung in U2 abweichende Darstellung haben.

	== Behandlung/Darstellung schwieriger Situationen ==		== Behandlung/Darstellung schwieriger Situationen ==

AEmmerich: /* Diskussionen zur Umstellung in der Vorgehensweise zu _UID */ _UID auf Ebene 2 eingefügt

2019-01-10T01:40:19Z

Diskussionen zur Umstellung in der Vorgehensweise zu _UID: _UID auf Ebene 2 eingefügt

← Nächstältere Version		Version vom 10. Januar 2019, 03:40 Uhr
Zeile 136:		Zeile 136:

	Keine in der Diskussion gemeinsam getragene Lösung gibt es für die Frage des Umganges mit dem "Altbestand" bzw. von der LDS-Darstellung abweichenden Inhalten der _UID. Der Vorschlag, das Ersetzen fehlerhafter Prüfbytes durch neu berechnete zu erlauben, ist inzwischen abgelehnt worden (U4). Per Abstimmung muss nun entschieden werden, ob der Inhalt der _UID gar nicht verändert werden darf (U7) und die Neuerzeugung eine Empfehlung zur Verwendung der LDS-Darstellung ist (U2). Als Alternative könnte man die LDS-Darstellung bei Neuerzeugung verbindlich machen, und bei Import anderer Darstellungen versuchen, die UUID zu identifizieren und in die LDS-Darstellung umzuwandeln. Zur Abstimmung steht zunächst die von mehr Programmautoren befürwortete, in U2 und U7 beschriebene Vorgehensweise.		Keine in der Diskussion gemeinsam getragene Lösung gibt es für die Frage des Umganges mit dem "Altbestand" bzw. von der LDS-Darstellung abweichenden Inhalten der _UID. Der Vorschlag, das Ersetzen fehlerhafter Prüfbytes durch neu berechnete zu erlauben, ist inzwischen abgelehnt worden (U4). Per Abstimmung muss nun entschieden werden, ob der Inhalt der _UID gar nicht verändert werden darf (U7) und die Neuerzeugung eine Empfehlung zur Verwendung der LDS-Darstellung ist (U2). Als Alternative könnte man die LDS-Darstellung bei Neuerzeugung verbindlich machen, und bei Import anderer Darstellungen versuchen, die UUID zu identifizieren und in die LDS-Darstellung umzuwandeln. Zur Abstimmung steht zunächst die von mehr Programmautoren befürwortete, in U2 und U7 beschriebene Vorgehensweise.

			=== _UID auf Ebene 2 ===

			Es sind bislang 2 Programme bekannt (mit GEN_DO! davon eines aus dieser Liste), die auch Elemente innerhalb der Datensätze kennzeichnen. Auch diese Kennzeichnung wird mit UUID durchgeführt, wobei unter dem Element auf Ebene 1 die UUID mit einer _UID auf Ebene 2 dargestellt wird. Beispiel:
			<source lang="gedcom">
			1 BIRT
			2 DATE 1 AUG 1827
			2 _UID 161C15D03ECE47968211BBB2E9EE7F4FA5A6
			</source>
			Vorgeschlagen ist mit U6, für solche _UID auf Ebene 2 dieselben Regeln gelten lassen, wie sie für die Ebene 1 vereinbart werden.

	=== Abweichungen vom Standard bei der Verwendung ===		=== Abweichungen vom Standard bei der Verwendung ===

AEmmerich: /* Umgang in PAF mit den UUID */ Akzeptanz einer UUID, die von RFC 4122 abweicht

2019-01-08T19:39:39Z

Umgang in PAF mit den UUID: Akzeptanz einer UUID, die von RFC 4122 abweicht

← Nächstältere Version		Version vom 8. Januar 2019, 21:39 Uhr
Zeile 100:		Zeile 100:

	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 [http://tools.ietf.org/html/rfc4122 RFC 4122] (englisch) abweichenden Routine und stellt sie ohne Bindestriche und mit Großbuchstaben dar.		*PAF bildet die UUID mit einer von [http://tools.ietf.org/html/rfc4122 RFC 4122] (englisch) abweichenden Routine und stellt sie ohne Bindestriche und mit Großbuchstaben dar. PAF akzeptiert auch UUID, die abweichend von den Vorgaben der RFC 4122 erstellt wurden.
	*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://archive.fhiso.org/BetterGEDCOM/files/GEDCOMUniqueIdentifiers.pdf 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://archive.fhiso.org/BetterGEDCOM/files/GEDCOMUniqueIdentifiers.pdf 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.

AEmmerich: /* LDS: Regelung für GUID */ PAF ohne Prüfbytes, Rückfrage zu Berechnungsmethode Prüfbytes

2019-01-08T19:37:39Z

LDS: Regelung für GUID: PAF ohne Prüfbytes, Rückfrage zu Berechnungsmethode Prüfbytes

← Nächstältere Version		Version vom 8. Januar 2019, 21:37 Uhr
Zeile 93:		Zeile 93:
	Das Dokument enthält auch eine Routine, wie eine erhaltene _UID auf Konformität mit der LDS-Version geprüft werden kann. Das ist eine sehr restriktive Variante, nach der jede andere Darstellung einer UUID beim Import verworfen wird: Verwendung von Kleinbuchstaben a-f führt ebenso wie fehlende oder nicht genau nach der von LDS vorgeschlagenen Berechnung ermittelten Prüfbytes führen dazu, dass die übermittelte _UID verworfen wird und durch eine neue ersetzt wird. Die zu Zwecken der Rückverfolgung übermittelte _UID ist damit hinfällig.		Das Dokument enthält auch eine Routine, wie eine erhaltene _UID auf Konformität mit der LDS-Version geprüft werden kann. Das ist eine sehr restriktive Variante, nach der jede andere Darstellung einer UUID beim Import verworfen wird: Verwendung von Kleinbuchstaben a-f führt ebenso wie fehlende oder nicht genau nach der von LDS vorgeschlagenen Berechnung ermittelten Prüfbytes führen dazu, dass die übermittelte _UID verworfen wird und durch eine neue ersetzt wird. Die zu Zwecken der Rückverfolgung übermittelte _UID ist damit hinfällig.

	LDS hat diese Version in PAF umgesetzt.		LDS hat diese Version in PAF umgesetzt, allerdings akzeptiert PAF _UIDs ohne Prüfbytes. Diese werden dann von PAF hinzugefügt, der Export enthält also auf jeden Fall die Prüfbytes.

			Weil es dazu eine Rückfrage gab: Die in U2 vorgeschlagene Berechnungsmethode führt zu denselben Prüfbytes wie die LDS-Version, die bei BetterGEDCOM hinterlegt ist. Beides sind nur unterschiedliche Darstellungen der gleichen Berechnungsmethode für die Prüfbytes.

	=== Umgang in PAF mit den UUID ===		=== Umgang in PAF mit den UUID ===

AEmmerich: /* Wie eine UUID gebildet werden kann */ Formulierung zu RFC 4122 nochmals angepasst

2019-01-06T21:36:27Z

Wie eine UUID gebildet werden kann: Formulierung zu RFC 4122 nochmals angepasst

← Nächstältere Version		Version vom 6. Januar 2019, 23:36 Uhr
Zeile 77:		Zeile 77:

	Die Aufgabe, ohne zentrale Steuerung in dezentralen Programmeinheiten Identnummern zu erzeugen, die mit außerordentlich hoher Wahrscheinlichkeit weltweit einmalig sind und bleiben, kann entsprechend der in [http://de.wikipedia.org/wiki/Universally_Unique_Identifier Wikipedia zu UUID] beschriebenen Methoden erfolgen, Details sind in der englischsprachigen [http://tools.ietf.org/html/rfc4122 Beschreibung zu RFC 4122] zu finden.		Die Aufgabe, ohne zentrale Steuerung in dezentralen Programmeinheiten Identnummern zu erzeugen, die mit außerordentlich hoher Wahrscheinlichkeit weltweit einmalig sind und bleiben, kann entsprechend der in [http://de.wikipedia.org/wiki/Universally_Unique_Identifier Wikipedia zu UUID] beschriebenen Methoden erfolgen, Details sind in der englischsprachigen [http://tools.ietf.org/html/rfc4122 Beschreibung zu RFC 4122] zu finden.
	~~Ein~~ UUID ~~besteht aus einer 16~~-~~Byte~~-~~Zahl~~, die ~~hexadezimal notiert und~~ in fünf Gruppen unterteilt wird. ~~In ihrer Normalform nach RFC 4122 wird eine UUID~~ folgendermaßen ~~dargestellt~~:		Eine UUID ist eine 128 Bit Zahl. Zwecks Darstellung und Übergabe muss sie in eine Darstellung umgewandelt werden. RFC 4122 beschreibt als Normalform eine hexadezimale Darstellung mit 32 Bytes (mit Kleinbuchstaben a-f neben 0-9), die durch Bindestriche in fünf Gruppen unterteilt wird und z.B. folgendermaßen aussieht:
	*550e8400-e29b-11d4-a716-446655440000		*550e8400-e29b-11d4-a716-446655440000

← Nächstältere Version		Version vom 8. Januar 2025, 15:05 Uhr
Zeile 15:		Zeile 15:
	== Formale Beschreibung zulässiger Werte ==		== Formale Beschreibung zulässiger Werte ==
	=== Aussagen des GEDCOM-Standards ===		=== 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.		Die früheren Versionen des GEDCOM-Standards enthielten kein explizites Kennzeichen, welches den Anforderungen an den Umgang mit UUID genügt. Daher hat zuerst PAF ein Nutzerdefiniertes Kennzeichen _UID eingeführt, welches dann von einer ganzen Reihe von 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 [https://tools.ietf.org/html/rfc4122 RFC 4122] (englisch) beschrieben nicht erfüllt.		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 [https://tools.ietf.org/html/rfc4122 RFC 4122] (englisch) beschrieben, nicht erfüllt.

			Erst in der Version 7 des GEDCOM-Standards wurde das GEDCOM-Kennzeichen UID eingeführt und ersetzt nun das zuvor verwendete _UID.

	== Vereinbarungen zu UID ==		== Vereinbarungen zu UID ==
	Mit einer Abstimmung durch die in der Gedcom-L mitarbeitenden Programmautoren wurden folgende Vereinbarungen zu eindeutigen Kennzeichnungen von Datensätzen getroffen:		Mit einer Abstimmung durch die in der Gedcom-L mitarbeitenden Programmautoren wurden folgende Vereinbarungen zu eindeutigen Kennzeichnungen von Datensätzen getroffen:
	Hinweis: U5 bezieht sich auf U2, welches wegen zu vieler Gegenstimmen noch einmal in eine Bearbeitungsrunde aufgenommen werden ~~soll~~.		Hinweis: U5 bezieht sich auf U2, welches wegen zu vieler Gegenstimmen noch einmal in eine Bearbeitungsrunde aufgenommen werden sollte.

	=== U0 Eindeutige Kennzeichnung von Datensätzen mit _UID ===		=== U0 Eindeutige Kennzeichnung von Datensätzen mit _UID ===
Zeile 152:		Zeile 154:

	=== Abweichungen vom Standard bei der Verwendung ===		=== Abweichungen vom Standard bei der Verwendung ===
	_UID ist ein Nutzerdefiniertes Kennzeichen, seine Bedeutung wird über keine im GEDCOM 5.5.1 Standard festgelegte Struktur unterstützt. Somit kann es zu _UID auch keine Abweichungen vom Standard geben.		_UID ist ein Nutzerdefiniertes Kennzeichen, seine Bedeutung wird über keine im GEDCOM 5.5.1 Standard festgelegte Struktur unterstützt. Somit kann es zu _UID auch keine Abweichungen vom Standard 5.5.1 geben. Bei Nutzung des Standards in der Version 7.0 darf _UID nicht mehr verwendet werden. Stattdessen ist das Kennzeichen UID zu verwenden.
	[[Kategorie:GEDCOM-Tag\|{{SUBPAGENAME}}]]		[[Kategorie:GEDCOM-Tag\|{{SUBPAGENAME}}]]
	[[Kategorie:GEDCOM-Tag-Fertig abgestimmt\|{{SUBPAGENAME}}]]<!-- Sortierfolge auf der Kategorienseite gemäß letzten Teil des Titelpfades -> also dem Tagnamen -->		[[Kategorie:GEDCOM-Tag-Fertig abgestimmt\|{{SUBPAGENAME}}]]<!-- Sortierfolge auf der Kategorienseite gemäß letzten Teil des Titelpfades -> also dem Tagnamen -->