GEDCOM/Feldlängen

Name und Bedeutung

Feldlängen

Dieser Artikel behandelt das Thema der Feldlängen von Bestandteilen in einer GEDCOM-Datei.

Verwendung

Es geht um Mindestlängen und Maximallängen von Bestandteilen, Vorgaben des Standards und Empfehlungen

Formale Beschreibung zulässiger Werte

Aussagen des Standards

KONZEPTE

Eine GEDCOM Übertragung beinhaltet eine Datenbank in Form eines sequenziellen Datenstromes aus mit einander verbundenen Datensätzen. Ein Datensatz wird durch eine Abfolge von gekennzeichneten Zeilen variabler Länge repräsentiert, die in einer Hierarchie angeordnet sind.

GRAMMATIKREGELN

Lange Werte können in kürzere GEDCOM-Zeilen aufteilt werden, indem die untergeordneten Kennzeichen (Tags) CONC oder CONT benutzt werden. Das Kennzeichen CONC bedeutet, dass der untergeordnete Wert mit dem vorhergehenden ohne Zeilenumbruch zusammengefügt wird. Der Zeilenumbruch zwischen den beiden GEDCOM-Zeilen wird dabei ignoriert. Wenn eine Zeile an einem Leerzeichen aufgeteilt wird, muss dieses auf die Folgezeile übernommen werden. Das Kennzeichen CONT bedeutet, dass der Wert der Zeile mit der vorherigen zusammengefügt wird, nachdem ein Zeilenumbruch eingefügt wurde.

Logische Datensätze in GEDCOM sollten beschränkt werden, so dass sie in einen Speicherpuffer von weniger als 32K passen. GEDCOM-Dateien mit Datensätzen, die größer als 32K sind, laufen Gefahr, von einigen Programmen nicht verarbeitet werden zu können. Die Nutzung von Zeigern, insbesondere zu NOTE-Datensätzen sollten gewährleisten, dass diese Limitierung ausreichend ist.

Anmerkung des Übersetzers: Die Gefahr, Teile von Datensätzen aufgrund zu kleiner Lesepuffer zu verlieren ist historisch zu betrachten, und spielte auch 1999 keine praktische Rolle mehr.

Jede Längenbeschränkung wird in Zeichen angegeben, nicht Bytes. Wenn „wide characters“ (Zeichen, die breiter sind als 8 Bit) verwendet werden, sollten Pufferlängen entsprechend angepasst werden.

Die Querverweis-IDs haben eine maximale Länge von 22 Zeichen, inklusive der umrahmenden ‚at‘ Zeichen (@), und müssen innerhalb der GEDCOM-Übertragung eindeutig sein.

Die Länge eines GEDCOM Kennzeichens (Tags) ist auf 31 Zeichen beschränkt, wobei die ersten 15 eindeutig sein müssen.

Die Gesamtlänge einer GEDCOM-Zeile inklusive Ebenennummer, Querverweis-ID, Kennzeichen, Wert, Begrenzer und Zeilenabschluss darf 255 (wide) Zeichen nicht überschreiten.

SYNTAX DER GRAMMATIK

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.

PRIMITIVE ELEMENTE

Die Feldgrößen zeigen die empfohlene Minimalgröße für Datenbanken, die längenbegrenzte Felder haben. Sie verstehen sich zusätzlich zu der Ebenennummer und dem Kennzeichen (Tag). GEDCOM-Zeilen sind auf 255 Zeichen begrenzt, jedoch können die CONC und CONT-Kennzeichen dazu benutzt werden, ein Feld über dieses Limit hinaus zu verlängern. Eine CONT-Zeile impliziert einen Zeilenumbruch, um die Formatierung zu erhalten. CONC impliziert die Verknüpfung mit dem vorherigen Zeilenwert ohne einen Zeilenumbruch. Dies wird genutzt, um den dynamischen Zeilenumbruch anhand der Größe eines Textfeldes zu ermöglichen, ohne feste Zeilenumbrüche vorzugeben. Die CONT und CONC-Kennzeichen werden genutzt, um textlich angegebene Werte zu erweitern. [Letzter Satz im englischen Original: The CONT and CONC tags are being used to extend specified textual values.]

Behandlung/Darstellung schwieriger Situationen

Vorschlag für Länge eines Zeilen_Wertes

Die GEDCOM-Zeile darf maximal 255 Zeichen lang sein. Darin sind alle Bestandteile der Zeile unterzubringen, von der einleitenden Ebenennummer angefangen bis hin zum abschliessenden Zeilenende.

Beispielzeile:

n Begrenzer TAGx Begrenzer Zeilen_Wert Zeilenende

So kann gerechnet werden:

• 255 Zeichen zulässig
• - 1 Zeichen für die Ebenennummer (diese kann die Werte kann 0 - 99 annehmen, bei größer 9 ist daher eine 2 einzusetzen)
• - 4 Zeichen für ein fest definiertes Kennzeichen (ggfs Länge des konkreten Kennzeichen einsetzen)
• - 2 Zeichen für die beiden Begrenzer
• - 2 Zeichen für das Zeilenende (sollte hier immer mit 2 angesetzt werden, damit ggfs ein Import in Systeme, die CR/LF verwenden, möglich bleibt)
• 246 Zeichen verbleiben für den Zeilen_Wert

Zeilen_Werte sollten daher auf 246 Zeichen begrenzt sein (ggfs noch ein längeres Kennzeichen berücksichtigen), um einen Import in möglichst viele Systeme zu gewährleisten. Längere Zeilen_Werte sollten nur dort zugelassen werden, wo mit CONC und/oder CONT umgebrochen wird.

Empfohlene Mindestgröße von Feldern - gleichzeitig auch als Maximalwert nehmen ?

Feldgrößen sind im Standard nicht bindend vorgeschrieben. Der Standard selbst sagt dazu, dass es sich um eine Empfehlung handelt für eine Mindestgröße bei Datenbanken, die längenbegrenzte Felder haben.

Beispiel OCCU: {size=1:90}

Das ist so zu lesen, dass der Standard mindestens die Unterstützung von Zeilenwerten zum Kennzeichen OCCU mit 90 Zeichen Länge empfiehlt. Mal abgesehen davon, dass einige Programme diese Empfehlung nicht umsetzen und die Feldgröße auf weniger Zeichen ( z.B. 80 Zeichen ) begrenzen, kommt die Frage, ob auch mehr Zeichen zugelassen werden sollen (es gibt Programme, die beliebig viele Zeichen zulassen und ggfs auch exportieren). Im Rahmen der bindenden Zeilenlängenbegrenzung wären immerhin bis zu 246 Zeichen im Zeilen_Wert möglich.

Aus der Formulierung des Standards heraus muss aber damit gerechnet werden, dass die Verwendung von längeren Zeilenwerten beim Datentransfer in andere Programme zum Datenverlust führt - die Programme schneiden in der Regel nach Erreichen der ihnen zur Verfügung stehenden Feldgröße ab, die restlichen Dateninhalte gehen verloren. Und keiner kann sich darauf verlassen, dass die anderen Programme längere Feldgrößen unterstützen als den im Standard empfohlenen Mindestwert. Für den Anwender kommt erschwerend hinzu, dass keine Übersicht bekannt ist, welches Programm welche Feldgrößen unterstützt. Damit ist der Datentransfer längerer Dateninhalte eines der kritischsten Themen im Bereich der GEDCOM-Übertragungen.

Die Probleme liessen sich eingrenzen, wenn eine Vereinbarung getroffen wird, genau die im Standard empfohlenen Mindestlängen als Feldlängen zu verwenden. Es darf aber nicht übersehen werden, dass dann eine Lösung für solche Programme gebraucht wird, die bislang längere Feldgrößen unterstützen. Deren Anwender wollen ja beim Übergang zu neueren Versionen erst recht keine Datenverluste erleiden. Und wie die Diskussion bei den Klartexten zu Datumsangaben schon gezeigt hat, ist die dortige "Mindestlänge" von 35 Zeichen ( DATE_VALUE : {size=1:35} ) schon eine starke Einschränkung der Gestaltunsgmöglichkeiten, wenn sie auch als Maximallänge definiert wird.

Lösungsansätze aus der Liste

Vor dem Hintergrund der Feldgrößenproblematik, einschließlich des Themas der Zeilenlängen, werden in der Gedcom-L folgende Lösungsvorschläge diskutiert:

Fortsetzung von Zeilen mit CONC/CONT

Hier wird vorgeschlagen, alle textlichen Zeilen_Werte bei Erreichen der Maximalzahl von Zeichen (oder einer im Programm favorisierten Zeilenlänge) mit CONC/CONT umzubrechen. Befürworter verweisen darauf, dass so beim Export die Zeilenlänge klein gehalten werden kann und die Importmodule dies verarbeiten könnten. Dagegen stehen die Argumente, dass die meisten Programme an den Stellen, wo der Standard die Fortsetzung der Zeilen per CONC oder CONT nicht explizit erwähnt, dies beim Import auch nicht verarbeiten können. Zumindest bei Drittprogrammen wird sich das auch bei entsprechender Vereinbarung der hier vertretenen Programme wohl leider so schnell nicht ändern. In der Liste gab es hierzu schon den Vorschlag, über ein Verbot der CONC/CONT-Verlängerungen an den im Standard nicht explizit zugelassenen Stellen abzustimmen, da viele Programme auf eine solche Vorgehensweise nicht eingestellt sind.

Festlegung auf die im Standard empfohlene Mindest-Feldgröße

Vorteil wäre einerseits eine weitgehende Kompatibilität eines so entstehenden Exports untereinander und beim Export für bisherige Programme/Drittprogramme, Nachteil die starke Einschränkung gegenüber bisherigen Lösungen - und die fehlende Kompatibilität beim Import von Dateien und Datenumfängen vieler bisheriger Programme, die längere Felder erzeugten, oft einschliesslich früherer Versionen der hier vertretenen Programme.

Festlegung auf den durch die festgeschriebene Zeilenlänge sich ergebende maximal zulässige Feldgröße

Vorteil ist die größere Freiheit für Eingaben längerer Texte z.B. bis 246 Zeichen sowie eine Kompatibilität der Programme untereinander bei einer gemeinsamen Vorgehensweise. Ein großer Teil der heute existierenden GEDCOM Dateien könnte eingelesen werden - nicht jedoch solche mit längeren Zeile als 255 Zeichen (die entsprechen aber auch nicht dem Standard). Nachteil ist die fehlende Kompatibilität zu Drittprogrammen, die eine entsprechende Erweiterung über die empfohlenen Mindestgröße, möglicherweise nicht mitmachen.

Eine Abwägung der Vorschläge muss noch erfolgen.

Status:

In Diskussion

Abweichungen vom Standard bei der Verwendung

Abweichende Zeilenlängen in heutigen Programmen

Die Diskussion zeigte bislang auf, dass die Vorgabe des GEDCOM Standards zur Maximallänge nicht von allen Programmen eingehalten wird. Es gibt Programme, die Zeilen unbegrenzter Länge erzeugen können und sie - falls der Anwender entsprechende Daten eingibt - auch exportieren. Andere Programme nutzen den vorgesehenen Spielraum nicht aus, und exportieren z.B. Zeilen mit einer Maximallänge von 80 Zeichen. Diese haben dann Probleme, die Empfehlung des Standards zur Feldgröße einiger Zeilen_werte umzusetzen, wo der Standard Mindestfeldgrößen oberhalb 80 Zeichen empfiehlt: z.B. OCCU {size=1:90} oder NAME_PERSONAL {size=1:120}.