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.]

Vereinbarungen zu Feldlängen

Vorbemerkung

Die Diskussion in der Gedcom-L hat deutlich aufgezeigt, dass es in den Programmen sehr unterschiedliche Vorgehensweisen bezüglich der möglichen Länge einzelner Datenfelder gibt. Dabei gibt es sowohl Programme, die die mögliche Länge der Felder wie z.B. Namen, Berufe, Orte usw beschränken (die jeweilige Maximallänge schwankt je nach Programm sehr stark) als auch Programme, die beliebig viele Zeichen in den Feldern verarbeiten können. Die Gedcom-L hat sich zur Aufgabe gestellt, den Datentransfer zwischen den Programmen zu verbessern, es ist aber nicht Aufgabe dieser Liste, programminterne Spezifika zu regeln oder zu vereinbaren.

Bezüglich der Datenfeldlänge in den Programmen wird daher hier nur auf den GEDCOM-Standard verwiesen, der eine EMPFEHLUNG für Mindestlängen der Datenfelder für solche Programme ausspricht, die längenbegrenzte Felder verwenden. Ob dieser Empfehlung jeweils gefolgt wird, ist Entscheidung der Programmautoren und nicht Gegenstand der hier zu treffenden Vereinbarungen.

Damit sind in den folgenden Entscheidungsvorschlägen solche Punkte aus der Listendiskussion aufgegriffen, die den Datentransfer zwischen den Programmen für den Anwender möglichst problemlos gestalten. Es sei jedoch gleich darauf hingewiesen, dass der Transfer von Daten zwischen Programmen mit unterschiedlich langen Datenfeldern nicht 1:1 funktionieren kann. Je stärker ein Programm die Feldlängen begrenzt, um so mehr muss der Anwender damit rechnen, dass Daten aus anderen Programmen nicht vollständig oder nicht richtig zugeordnet importiert werden können. Und je längere Felder ein Programm zuläßt, um so mehr muss der Anwender damit rechnen, das er bei Ausnutzung dieser Feldlängen seine Daten nicht mehr vollständig oder nicht richtig zugeordnet in andere Programme übertragen kann.

Die vorgeschlagenen Regelungen sollen zumindest sicherstellen, dass zwischen Programmen mit gleichen Feldlängen (begrenzt oder unbegrenzt) der Datentransfer klappt. Weiterhin sind Empfehlungen formuliert, wie dem Anwender der Umgang mit nicht importierbaren Datenteilen ermöglicht werden soll.

Vereinbarungen bezüglich Feldlängen beim Export

Durch Abstimmung unter den in der Gedcom-Liste beteiligten Programmautoren sind folgende Vereinbarungen getroffen worden:

E1 Vorgaben des GEDCOM Standard 5.5.1

Die Vorgaben des Standards müssen eingehalten werden. Dies gilt insbesondere für folgende Punkte:

• Die Querverweis-IDs haben eine maximale Länge von 22 Zeichen, inklusive der umrahmenden 'at' Zeichen (@).
• 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.

Alle Längenbegrenzungen sind hier als Zeichen und nicht als Bytes angegeben. Wenn „wide characters“ (Zeichen, die breiter sind als 8 Bit) verwendet werden, liegt die Anzahl der Bytes entsprechend höher.

E2 Umfang des Exportes

Der komplette Inhalt der Datenfelder muss exportiert werden. Wo dies zur Überschreitung der Zeilenlänge von 255 Zeichen führen würde, muss ( bei allen Kennzeichen ) mit CONC oder CONT umgebrochen werden. Die Vereinbarungen zur Zeilentrennung mit CONC sind dabei einzuhalten. CONT sollte nicht verwendet werden ausser bei den im GEDCOM Standard explizit genannten Fällen:

• Im HEADER nach COPR und NOTE,
• in NOTE_RECORD nach NOTE,
• in SOURCE_RECORD nach AUTH, TITL, PUBL, TEXT
• in INDIVIDUAL_ATTRIBUTE_STRUCTURE nach DSCR
• in NOTE_STRUCTURE nach NOTE
• in SOUR_CITATION nach TEXT und SOUR

Weiterhin ist CONT zulässig {0:3}:

• In ADDRESS_STRUCTURE nach ADDR

Zeilen mit einer Länge von unter 255 Zeichen dürfen auch mit CONC ( oder mit CONT ) umgebrochen werden. Dies wird wegen des Risikos des Datenverlustes in Drittprogrammen aber nicht empfohlen, insbesondere dann nicht, wenn diese Verwendung von CONC und CONT im Standard nicht explizit genannt ist.

E3 Verwendung von NOTE für sehr lange Inhalte

Im Hinblick auf Zielprogramme mit längenbegrenzten Datenfeldern darf der Dateninhalt beim Export auch in Notizen ( NOTE, ggfs mit CONC | CONT verlängert ) ausgelagert werden. Dabei wird empfohlen, dem Inhalt einen kurzen Hinweis auf seine Zuordnung voranzustellen, z.B. so:

• n NOTE Beruf: ....hier folgt nun ein sehr langer Text aus dem Berufsfeld....

Vereinbarungen bezüglich Import

I1 Umgang mit längeren Datenihalten beim Import

Wo immer möglich soll der zu importierende Dateninhalt komplett in die richtigen Datenfelder übernommen werden. Ist dies nicht möglich, weil der (ggfs durch CONC | CONT verlängerte) Dateninhalt nicht in das zugehörige Datenfeld des Programmes passt oder das Datenfeld nicht zum Funktionsumfang des Programmes gehört, dann muss der Anwender hierüber informiert werden. Empfohlen wird, dem Anwender einen Zugriff auf die nicht in das Datenfeld importierten Anteile zu ermöglichen. Das kann wahlweise durch Ablegen unter Notizen ( NOTE ) oder in einer gesonderten Fehlerdatei erfolgen.

I2 Behandlung der Verlängerungen mit CONC | CONT

Inhalte aus CONC-Zeilen sind ohne Einfügen eines Leerzeichens oder Zeilenumbruchs an den vorhergehenden Inhalt anzufügen. Inhalte aus CONT-Zeilen sind mit einem Zeilenumbruch anzufügen. In allen Fällen ausser den in E2 bzw im GEDCOM-Standard explizit genannten Verlängerungen darf dieser Zeilenumbruch auch durch ein Leerzeichen ersetzt werden ( insbesondere bei einzeiligen Datenfeldern als Ziel ). Unterstützt das Programm nicht die Verlängerung von Dateninhalten durch CONC bzw CONT bzw nicht alle solche Verlängerungen, so müssen dem Anwender beim Auftreten nicht unterstützter Verlängerungen Fehlermeldungen gegeben werden.

I3 Zuordnung von nicht importierten Anteilen

Es wird empfohlen, die nach I1 bzw I2 nicht in die zugehörigen Datenfelder importierten Anteile für den Anwender zusammen mit entsprechenden Hinweisen zur Verfügung zu stellen, wohin diese Anteile gehören. Bei Notizen kann dies wie in E3 vorgeschlagen erfolgen, bei Einspeicherung in Fehlerdateien sollen Hinweise aufgenommen werden, die die Zuordnung zum betroffenen Datensatz und betroffenen bzw. übergeordneten Datenfeld ermöglichen.

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, wurden in der Gedcom-L folgende Lösungsvorschläge diskutiert, aus denen dann die Vereinbarungen hergeleitet und durch Abstimmung in Kraft gesetzt wurden (s.o.):

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.

Status:

Vereinbarung getroffen