GEDCOM/Syntax GEDCOM-Zeile

Name und Bedeutung

Strukturelement GEDCOM-Zeile

Eine GEDCOM-Datei setzt sich aus einzelnen Zeilen mit genau definiertem Aufbau (Syntax) zusammen.

Formale Beschreibung zulässiger Werte

GEDCOM-Zeilen sind Bestandteile der Datensatz-Struktur innerhalb einer GEDCOM-Datei. Die Struktur der Datensätze wird in einem gesonderten Artikel behandelt werden.

Die folgende Beschreibung basiert auf der Übersetzung des GEDCOM Standards Draft 5.5.1 von Jörn Daub.

Aussagen des Standards

Eine GEDCOM-Zeile hat folgende Syntax:

gedcom_zeile := ebenennummer + begrenzer + [optionale_querverweis_id] + kennzeichen + [optionaler_wert] + zeilenende

Beispiel:

• 1 NAME Will /Rogers/

Die einzelnen Bestandteile sind wie folgt im Standard erläutert und definiert:

Bemerkung zur Darstellung

Die Bestandteile des obigen Musters werden hier ... definiert. Einige der Komponenten werden durch primitive Muster definiert. Die Leerzeichen dienen hierbei nur dazu, sie voneinander abzusetzen, und sind nicht Bestandteil des resultierenden Musters. Zeichenkonstanten sind in hexadezimaler Form angegeben, (0x20) ist dabei der hexadezimale Wert des Leerzeichens. Zeichenkonstanten, die durch einen Bindestrich (-) getrennt sind, repräsentieren ein beliebiges Zeichen innerhalb des Bereiches zwischen der ersten angegebenen Zeichenkonstante und der zweiten.

ebenennummer

Ebenennummern müssen zwischen 0 und 99 liegen, und dürfen keine führenden Nullen beinhalten. Ebenennummer eins ist daher 1, und nicht 01. Jede neue Ebenennummer darf nicht höher sein als die der vorhergehenden Zeile plus 1

Bemerkung zu dieser Formulierung im Standard:

• Ebenennummer null wird also als 0 und nicht als 00 ausgegeben,
• Ebenennummer eins wird also als 1 und nicht als 01 ausgegeben,

usw.

begrenzer

begrenzer := [(0x20) ]

wobei: (0x20)=Leerzeichen

begrenzer := Der Begrenzer ist ein einzelnes Leerzeichen, und beendet sowohl die Ebene als auch Kennzeichen, die beide eine variable Länge haben. Hierbei ist zu beachten, dass auch der zeilen_wert Leerzeichen enthalten kann.

optionale_querverweis_id

optionale_querverweis_id := querverweis_id + begrenzer

Zur querverweis_id siehe Artikel GEDCOM/XREF_ID.

kennzeichen

kennzeichen := [alphanum | kennzeichen + alphanum ]

kennzeichen := Ein Kennzeichen ist eine Zeichenkette variabler Länge aus alphanum-Zeichen. Alle benutzerdefinierten Kennzeichen, die nicht im GEDCOM-Standard definiert sind, müssen mit einem Unterstrich (0x95) beginnen.

Das Kennzeichen bestimmt die Bedeutung des zeilen_wertes im Kontext der ihr übergeordneten Zeilen und trägt gleichzeitig zur Bedeutung der ihr untergeordneten Zeilen bei. Die einzelnen Kennzeichen werden im Anhang A definiert. Das Vorhandensein eines Kennzeichens zusammen mit einem zeilen_wert repräsentiert eine Annahme, die der Verfasser dem Empfänger mitteilen möchte. Ein Kennzeichen ohne zeilen_wert beinhaltet keine solche Annahme. Wenn ein Kennzeichen nicht angegeben wird, bedeutet dies, dass keine Annahme gemacht wird. Informationen negativer Natur (wie z. B. dass man mit Sicherheit weiß, dass ein bestimmtes Ereignis nicht stattgefunden hat) werden durch ein semantisch getrenntes Kennzeichen samt zugehörigem Wert explizit abgebildet.

Obwohl formal definierte Kennzeichen nur drei oder vier Zeichen lang sind, sollten Systeme darauf vorbereitet sein, längere benutzerdefinierte Kennzeichen zu verarbeiten. Kennzeichen sind eindeutig innerhalb der ersten 15 Zeichen.

Gültige Kombinationen von spezifischen Kennzeichen, zeilen_werten, querverweis_ids und Zeigern werden durch die GEDCOM-Form eingeschränkt, um bestimmte Informationen abzubilden (siehe Kapitel 2 des Standards).

Hinweis zur Aufteilung des Themas in GenWiki: Die Kennzeichen (englisch: tag) werden jeweils einzeln behandelt und haben eigene Artikel in GenWiki.

optionaler_wert

optionaler_wert := begrenzer + zeilen_wert

zeilen_wert

zeilen_wert := Der zeilen_wert entstammt einer Menge von möglichen Werten, die im Kontext des Kennzeichens erlaubt sind. Die Kombination aus kennzeichen, zeilen_wert und dem hierarchischen Zusammenhang der zugehörigen gedcom_zeilen ermöglicht das Verständnis der beinhalteten Werte. Die Menge der möglichen Werte wird durch die GEDCOM-Form (Siehe Kapitel 2 des Standards) bestimmt. Werte, bei denen die Quellinformationen unleserliche Teile enthalten, sollten dadurch gekennzeichnet werden, dass der unleserliche Teil durch Auslassungszeichen ersetzt wird (…) Werte sind im Allgemeinen nicht binär zu kodieren, oder durch Abkürzungen zu ersetzen, um Platz zu sparen. Sie sind allgemein so zu halten, dass ein typischer Anwender ihre Bedeutung ohne Dekodierung verstehen kann. Dies soll den Dekodieraufwand der empfangenden Software klein halten. Ein GEDCOM-optimierter Datenkompressionsstandard wird in Zukunft definiert werden, um Platz zu sparen. In der Zwischenzeit können Anwender sich darauf einigen, eine bestimmte Kompression zu nutzen, die Verfasser und Empfänger beide verstehen. Der zeilen_wert im Kontext seiner Hierarchie von gedcom_zeilen repräsentiert ein Informationsstück, und korrespondiert mit einem Feld in traditioneller Datenbank- oder Dateiterminologie.

zeilenende

zeilenende := Ein Zeilenende begrenzt den zeilen_wert, der eine variable Länge hat, und signalisiert das Ende einer gedcom_zeile. Die möglichen Zeichen für ein Zeilenende sind:

[ carriage_return | line_feed | carriage_return + line_feed | line_feed + carriage_return ]

Mindestumfang einer GEDCOM-Zeile

Alle GEDCOM-Zeilen haben entweder einen zeilen_wert oder einen zeiger, es sei denn, die Zeile hat untergeordnete GEDCOM-Zeilen. In anderen Worten: Das Vorhandensein einer Ebenennummer und eines Kennzeichens allein darf nicht dazu benutzt werden, um daraus Daten abzuleiten (z. B.: 1 DEAT Y sollte benutzt werden, um anzuzeigen, dass der Tod einer Person bekannt ist, aber weder dessen Datum noch Ort – nicht: 1 DEAT). Diese Grammatik erlaubt es nicht, sowohl einen zeilen_wert als auch einen zeiger in der gleichen Zeile zu speichern.

Unzulässige Einrückungen / Zeilen in einer GEDCOM-Datei

Einige Systeme geben eingerückte GEDCOM-Zeilen aus, um für eine bessere Lesbarkeit zu sorgen, und geben Leerzeichen oder Tabulatorzeichen vor der Ebenennummer aus, um die Hierarchie sichtbar zu machen. Es wurde auch vorgeschlagen, zusätzliche Leerzeilen zwischen den Datensätzen auszugeben, um diese sichtbar zu trennen. GEDCOM-Dateien, die so erzeugt wurden, dürfen nicht dazu genutzt werden, diese an andere Systeme zu übermitteln.

Beispiele aus dem Standard

Die folgenden Zeilen sind voneinander unabhängige Beispiele gültiger GEDCOM-Zeilen.

• 0 @1234@ INDI
• …
• 1 AGE 13y
• …
• 1 CHIL @1234@
• …
• 1 NOTE Dies ist ein Notizfeld, das
• 2 CONT auf der nächsten Zeile fortgesetzt wird

Die erste Zeile hat die ebene 0, die querverweis_id @1234@, ein INDI-kennzeichen und keinen zeilen_wert.

Die zweite Zeile hat die ebene 1, keine querverweis_id, ein AGE-kennzeichen und einen zeilen_wert von 13y.

Die dritte Zeile hat die ebene 1, keine querverweis_id, ein CHIL-kennzeichen, und einen zeilen_wert, bestehend aus einem zeiger auf die querverweis_id @1234@.

Vereinbarungen zur Syntax von GEDCOM-Zeilen

Per Abstimmung der Programmautoren wurden die folgenden Vereinbarungen getroffen.

Zum Umgang mit dem Zeichen @ im Export und Import wird es in einem Gesamtreview am Projektende noch einmal einen Aufruf zur Diskussion geben, da hier das Abstimmungsergebnis zwar eine Mehrheit brachte, aber doch in nennenswertem Umfang auch Stimmen "könnte damit leben" und "dagegen" abgegeben wurden. Dies betrifft E6 und I3.

E1 Regeln zur Syntax

Folgende Vorgaben des Standards müssen beim Export eingehalten werden:

• Vor der Ebenennummer sind keine Zeichen zulässig (Ausnahme: BOM in der allerersten Zeile der Datei)
• Die Ebenennummer muss eine Zahl im Bereich (0-99) sein, sie darf keine führende Null vor einer zweiten Ziffer enthalten.
• Der Begrenzer zwischen den anderen Bestandteilen der GEDCOM-Zeile besteht aus genau einem Leerzeichen (0x20)
• Leere Zeilen (also nur aus einem Zeilenende bestehende Zeilen) sind nicht zulässig
• Jede GEDCOM-Zeile muss entweder einen Zeilen_Wert oder einen Querverweis_Zeiger enthalten, es sei denn, ihr sind weitere GEDCOM-Zeilen untergeordnet

E2 Zusammensetzung der GEDCOM-Zeile

Die GEDCOM-Zeile muss beim Export den im Standard vorgeschriebenen Aufbau aufweisen:

• Gedcom_zeile := Ebenennummer + Begrenzer + [optionale_Querverweis_ID] + Kennzeichen + [optionaler_Wert] + Zeilenende

mit

• optionale_Querverweis_ID := Querverweis_ID + Begrenzer
• optionaler_Wert := Begrenzer + Zeilen_wert

Für die Bestandteile gelten die im Standard festgelegten Bestimmungen.

E3 Zeilenende

Das Zeilenende muss gemäss einer der Alternativen exportiert werden:

• CR/LF | LF | CR | LF/CR

Im Standardexport wird die Verwendung von CR/LF oder LF empfohlen. LF/CR sollte nicht verwendet werden.

E4 Abweichung vom Standard zur Darstellung von Leerzeilen in Notizen

Eine Leerzeile in Notizen führt im GEDCOM-Code zur Darstellung:

• n+1 CONT

Diese Zeile hat weder einen Zeilen_Wert, noch einen Querverweis_Zeiger und kann auch keine Folgezeilen anführen. Nach Standard-Vorgaben ist sie daher nicht zulässig. Abweichend von E1 wird diese Darstellung zum Export von Leerzeilen in Notizen geduldet.

E5 Verwendung von UNICODE-Zeichen

Formal erlaubt der Standard nur die Verwendung von Zeichen des ANSEL-Umfanges, da bei der Grammatik-Beschreibung zur Syntax der GEDCOM-Zeile der Einsatz von UNICODE noch nicht eingearbeitet ist. Um die UNICODE-Zeichen sinngemäß einsetzen zu können, wird vereinbart, die Definition der zulässigen Zeichen im sonstigen_Zeichen um die UNICODE-Zeichen >= U+00A0 zu ergänzen. Damit sind diese Zeichen in den Zeilen_werten zulässig.

E6 Umgang mit dem @ in Zeilen_elementen beim Export

In Zeilen_elementen darf in der exportierten GEDCOM Datei kein einfaches @ stehen. Um dennoch Anwendereingaben von einfachen @ eindeutig und standardgemäß über Zeilen_elemente transferieren zu können, wird beim Standard-Export die Vorgehensweise des Standards GEDCOM 5.5. übernommen: Jedes @ in den Zeilen_elementen wird beim Export zu einem @@ gedoppelt.

Eine Exportoption mit Verzicht auf die Doppelung der @ ( z.B. für Ziel-Programme, die die @@ beim Import nicht rückwandeln ), darf dem Anwender angeboten werden. Diese Option kann insbesondere für E-Mail-Adressen nach dem Kennzeichen (Tag) EMAIL angeboten werden.

I1 Umfang des Importes

Nach den Regeln E1 bis E3 gebildete GEDCOM-Zeilen müssen grundsätzlich unterstützt werden. Bezüglich der Kennzeichen, Querverweiszeiger und Zeilenwerte gelten die gesonderten Vereinbarungen.

I2 Vorgehensweise bei Abweichungen vom Standard in der Importdatei

• Alle Zeichen vor der Ebenennummer, insbesondere Tabulatoren und Leerzeichen, werden ignoriert (mit Ausnahme des BOM in der ersten Zeile der Datei)
• Mehrere Leerzeichen an Stelle eines Begrenzers dürfen wie ein Begrenzer behandelt werden (Sonderreglung zu CONC siehe Vereinbarungen zu CONC)
• Leere Zeilen (nur aus dem Zeilenende bestehend) werden ignoriert
• Zeilen, die weder einen Zeilenwert, noch einen Querverweiszeiger haben und auch keine untergeordneten Zeilen aufweisen, werden ignoriert. Ausnahme hierzu ist die in E4 dargestellte Version zur Darstellung von Leerzeilen in Notizen.

I3 Umgang mit dem Zeichen @ beim Import

Bei Standardimport von Zeilen_elementen müssen die @@ wieder in einfache @ verwandelt werden. Kommen vom Standard abweichende einfache @ in den Zeilen_elementen vor, so werden diese unverändert übernommen.

Eine Importoption ohne Ersetzen der @@ durch @ darf dem Anwender angeboten werden, insbesondere für Dateien aus Programmen, die nicht nach E6 die @ beim Export gedoppelt haben.

Hinweis:

Die Vereinbarungen über die zulässige Länge der GEDCOM-Zeile sowie die Feldgrößen innerhalb der Zeile werden unter GEDCOM/Feldlängen dokumentiert.

Behandlung/Darstellung schwieriger Situationen

Doppelbedeutung des Leerzeichens: Begrenzer und Dateninhalt

Das Leerzeichen in einer GEDCOM-Zeile hat doppelte Bedeutung: Einerseits ist es als begrenzer ein Strukturelement, um die anderen Bestandteile der GEDCOM-Zeile voneinander zu trennen, andererseits kann es zum zeilen_wert und damit zum zu transferierenden Dateninhalt der GEDCOM-Datei gehören.

Für einen eindeutigen, fehlerfreien Datentransfer muss die Vorgabe eingehalten werden, dass der begrenzer aus (genau!) einem Leerzeichen besteht. Würde diese Vorgabe nicht eingehalten, könnten die Dateninhalte zu Beginn und am Ende des zeilen_wertes nicht mehr eindeutig interpretiert werden, wenn der zeilen_wert aus Text besteht. Dann wäre nämlich unklar, ob bei mehreren Leerzeichen an dieser Stelle ein mehrfacher begrenzer exportiert wurde oder auch Leerzeichen zum zeilen_wert gehören.

Einige wenige Programme halten diese Vorgabe des Standards nicht ein und verursachen somit Importprobleme für die mit ihnen erzeugten Dateien. Zur tieferen Diskussion dieses Aspektes wird auf den Artikel GEDCOM/CONC-Tag verwiesen.

Wegen erneuter Diskussion dieses Punktes im Jahr 2020 hier die Ableitung, in welchen Fällen am Anfang bzw. am Ende eines Zeileninhaltes Leerzeichen zulässig sind:

Syntax der Grammatik, ab S.11 der Übersetzung, mit meinen eingerückten Kommentaren:

• Gedcom_Zeile := Ebene + Begrenzer + [optionaler_Querverweis_ID] + Kennzeichen + [optionaler_Wert] + Zeilenende
• optionaler_Wert := Begrenzer + Zeilen_wert
• Begrenzer := [(0x20) ] wobei: (0x20)=Leerzeichen

==> nach einem Kennzeichen muss entweder ein Begrenzer (=Leerzeichen) plus weiterer Inhalt kommen oder gar nichts vor dem Zeilenende. Damit ist z.B. nach 1 BIRT kein Leerzeichen zulässig, es sei denn es folgt das zugelassene Y: 1 BIRT Y

• Zeilenwert := [ Zeiger | Zeilenelement ]
• Zeiger := [(0x40) + Alphanum + Zeiger_zeichenkette + (0x40) ]

==> (0x40) = @, vor und nach dem Zeiger darf also kein Leerzeichen stehen, sondern vorher genau nur ein Begrenzer

• Zeilenelement := [ beliebiges_Zeichen | Escape | Zeilenelement + beliebiges_Zeichen | Zeilenelement + Escape ]
• beliebiges_Zeichen := [ Alpha | Ziffer | sonstiges_Zeichen | (0x23) | (0x20) | (0x40)+(0x40) ] wobei: (0x23)=# (0x20)=Leerzeichen (0x40)+(0x40)=@@

Damit sind wir am Ziel: In "beliebiges Zeichen" ist das Leerzeichen explizit zugelassen, ein Zeilenelement darf u.a. aus beliebig vielen beliebigen Zeichen bestehen - und es gibt keine Regel außer dem Text bei der Trennung mit CONC, dass am Anfang oder am Ende des Zeilenelementes das Leerzeichen ausgeschlossen ist.

Zeilenende

Die Diskussion zum Zeilenende war in der Liste vorübergehend zurückgestellt, ist jetzt aber wieder aufgerufen. Es wurde schon darauf hingewiesen, dass je nach Betriebssystem die nach GEDCOM-Standard zulässigen Zeilenenden erhebliche Importprobleme bereiten können.

Zugelassen laut Standard sind alternativ: LF, CR, CR/LF, LF/CR (letztere Version ist wahrscheinlich nicht in Verwendung).

Nicht zulässige Zeilenenden wie UNICODE-Zeichen FF, NEL, LS, PS wurden bislang in der GEDCOM-Praxis auch nicht beobachtet.

Einige Windows-Textverarbeitungsprogramme kommen mit den Alternativen zu CR/LF nicht zurecht.

Die bisherige Diskussion hat im wesentlichen zu folgenden Vorschlägen geführt:

• a) Beim Export nur die Kombination CR/LF berücksichtigen
• b) Beim Export als Standardversion CR/LF, aber auch andere - insbesondere LF - als Option anbieten
• c) Beim Export unter den Systemen Unix und MacOS als Standardversion LF exportieren, unter Windows CR/LF
• d) Möglichst ohne vom Anwender einzustellende Option exportieren, da der Anwender sich oft nicht mit dieser Materie auskennt

Vorschlag a) hat wegen der Verwendung von LF als Zeilenende unter Unix und MacOS weniger Zustimmung gefunden.

Für den Import wurde vorgeschlagen, dass ein Programm alle nach Standard zulässigen Zeilenenden unterstützen muss.

Problem mit dem Standard GEDCOM 5.5.1 und den zulässigen Zeichen

Der Standard beschreibt im Abschnitt Syntax der Grammatik in formalen Ausdrücken, wie die Bestandteile der GEDCOM Zeile aufgebaut werden müssen. Das geht so weit, dass im einzelnen die zulässigen Zeichen angegeben werden. Hier macht sich jedoch bemerkbar, dass die Version 5.5.1 nicht ganz zu Ende entwickelt wurde: Während bei der Kodierung der Zeichen u.a. der Zeichensatz UTF-8 ausdrücklich zugelassen wurde (und hier bereits unter dem Kennzeichen CHAR die Vereinbarung getroffen wurde, UTF-8 zukünftig im Standardexport einzusetzen), verbieten die Grammatikregeln bei Zeilen_Werten und Zeigern die Verwendung von anderen Zeichen als solchen, die im ANSEL-Zeichensatz enthalten sind.

Aus diesem Grund besteht Bedarf, den Umfang zulässiger Zeichen in der GEDCOM-Zeile unter Berücksichtigung von UTF-8 neu festzulegen.

Mit Unterstützung von Jörn Daub wurde hierzu der Vorschlag erarbeitet, die auf Basis von ANSEL-Zeichen beschriebene Grammatik des GEDCOM-Standards grundsätzlich unverändert zu lassen, da sie weitestgehend auf der Verwendung sieben-bittiger Zeichen beruht ( die in ANSEL und UTF-8 gleich kodiert werden ). Einzig das sonstige_Zeichen, welches im Standard 5.5.1 explizit mit Hilfe des ANSEL-Zeichenvorrates definiert wird, ist um die UNICODE-Zeichen im Bereich oberhalb des Zeichens U+00A0 (dieses Zeichen eingeschlossen) zu ergänzen.

Als Auswirkung sind damit alle diese UNICODE-Zeichen in Zeigern und Zeilen_elementen zulässig, und damit also in allen Zeilen_werten.

Diese Vorgehensweise ist als Entscheidungsvorschlag E5 hinzugefügt worden.

Zur Information hier die Zusammenstellung der Grammatikregeln, auf die sich obige Aussagen beziehen:

Zeilen_wert := [ Zeiger| Zeilen_element ]

Zeilen_element := [ beliebiges_Zeichen | Escape | Zeilen_element + Beliebiges_zeichen | Zeilen_element + Escape ]

Escape := [(0x40) + (0x23) + Escape_text + (0x40) + nicht_at_Zeichen]

• wobei:
• (0x40)=@
• (0x23)=#

Escape_text := [ beliebiges_Zeichen | Escape_text + beliebiges_Zeichen ]

• Der Escape_text wird so kodiert, dass er die GEDCOM-Regeln einhält.

beliebiges_Zeichen := [Alpha | Ziffer | sonstiges_Zeichen | (0x23) | (0x20) | (0x40)+(0x40) ]

• wobei:
• (0x23)=#
• (0x20)=Leerzeichen
• (0x40)+(0x40)=@@

Alpha := [(0x41)-(0x5A)|(0x61)-(0x7A)|(0x5F)]

• wobei :
• (0x41)-(0x5A) = A bis Z
• (0x61)-(0x7A) = a bis z
• (0x5f) = (_) Unterstrich

Ziffer := [(0x30)-(0x39) ]

• wobei:
• (0x30)-(0x39) = eine der Ziffern 0,1,2,3,4,5,6,7,8,9

sonstiges_Zeichen := [(0x21)-(0x22) | (0x24)-(0x2F) | (0x3A)-(0x3F) | (0x5B)-(0x5E) | (0x60) | (0x7B)-(0x7E) |(0x80)-(0xFE) | >=(U+00A0) ]

• wobei respektive:
• (0x21)-(0x22)=! "
• (0x24)-(0x2F)=$ % & ' ( ) * + , - . /
• (0x3A)-(0x3F)=: ; < = > ?
• (0x5B)-(0x5E)=[ \ ] ^
• (0x60)=`
• (0x7B)-(0x7E)={ | } ~
• (0x80)-(0xFE)=ANSEL Zeichen über 127 --- und hier ergänzen wir: zusätzlich jedes UNICODE-Zeichen >= (U+00A0)
• Jedes 8bittige ASCII Zeichen außer den Steuerzeichen (0x00-0x1F), Alphanum, der Raute (#), dem At-Sign (@), _ Unterstrich und dem DEL Zeichen (0x7F)

Zeiger := [(0x40) + Alphanum + Zeiger_zeichenkette + (0x40) ]

• wobei:
• (0x40)=@

Alphanum :=[Alpha | Ziffer ]

Zeiger_zeichenkette := [Null | Zeiger_zeichen | Zeiger_zeichenkette + Zeiger_zeichen]

Zeiger_zeichen := [nicht_At_Zeichen]

nicht_At_Zeichen := [Alpha | Ziffer | sonstiges_Zeichen | (0x23) | (0x20 ) ]

• wobei:
• (0x20)=space character
• (0x23)=#

Abweichungen vom Standard bei der Verwendung

siehe Doppelbedeutung des Leerzeichens: Die Vorschrift, dass der begrenzer nur aus einem Leerzeichen besteht, wird von einigen wenigen Programmen nicht eingehalten.

Behandlung des Zeichens @

Der GEDCOM Standard 5.5.1 schließt wie schon GEDCOM 5.5 die Verwendung eines einfachen Zeichens @ in den sonstigen_Zeichen aus, bei der Bildung des beliebigen_Zeichens wird dann stattdessen das doppelte @@ zugelassen. Damit verbietet der GEDCOM-Standard den Export von einem einfachen @ in Anwenderdaten ( = Zeilen_element ) und reserviert das einfache @ für die Kennzeichnung von Zeigern und Querverweis_ID sowie für Escapes (in Fall des Escapes folgt auf das führende @ einer Escapesequenz immer ein #).

Diese Regelung des Standards wird von vielen Programmen nicht eingehalten, sie exportieren vom Anwender eingegebene Zeichen @ unverändert. Eine Verwechslung von Anwendereingaben z.B. unter NOTE oder SOUR mit den vom Programm erzeugten Zeigern und Escapes kann daher bei einem darauffolgenden Import nicht ausgeschlossen werden.

Der Standard GEDCOM 5.5. hatte zu diesem Thema explizit vorgeschrieben, das Zeichen @ aus Anwendereingaben beim Export zu doppeln ( also als @@ zu exportieren ) und beim Import entsprechend wieder in ein einfaches @ zurückzuverwandeln:

• If an @ is desired as part of the line_value, it must be written in GEDCOM as a double @, i.e., §3 doz. @ $20.00" must be stored as "3 doz. @@ $20.00".

Dies wird von einigen Programmen auch so gemacht. Die Vorgabe über die Doppelung ist im GEDCOM Standard 5.5.1 entfallen, so dass hier zwar weiter das Verbot des einfachen @ beim Export von Anwenderdaten besteht, aber keine Handlungsempfehlung des Standards zum Umgang mit dem @ mehr vorhanden ist. Es sind daher in GEDCOM 5.5.1 auch andere Ersetzungslösungen für das @ zulässig, was jedoch die Eindeutigkeit der Lösung gefährdet.

Als Entscheidungsvorschlag E6 wurde daher nach kontroverser Diskussion in der Gedcom-L eine Vorgehensweise formuliert, die die Vorgaben des Standards erfüllt (keine einfachen @ in den sonstigen_Zeichen), und mit der Vorgehensweise aus GEDCOM 5.5. die Eindeutigkeit des Datentransfers auch für einfache @ in Anwenderdaten sicherstellt: Doppelung der @ außerhalb von Zeiger, Querverweis_ID und Escapes beim Export (also in allen Zeilen_elementen), Rückwandeln beim Import.