GEDCOM/CONC-Tag

Name und Bedeutung

Tag

CONC

Formelle Bezeichnung

CONCATENATION

Deutsche Bezeichnung

Verkettung

Verwendung

CONC {CONCATENATION}:= (Textverknüpfung) Ein Indikator, dass weitere Daten zum übergeordneten Wert gehören.

Formale Beschreibung zulässiger Werte

Aussagen des Standards

CONC {CONCATENATION}:= (Textverknüpfung) Ein Indikator, dass weitere Daten zum übergeordneten Wert gehören. Die Information aus dem CONC-Wert soll dem Wert der übergeordneten, direkt voranstehenden Zeile ohne Leerzeichen und ohne Zeilenumbruch hinzugefügt werden. Werte, die für ein CONC-Kennzeichen aufgeteilt werden, müssen an einem nicht-Leerzeichen aufgetrennt werden. Wenn der Wert an einem Leerzeichen getrennt wird, so wird dieses Leerzeichen verloren gehen, wenn sie wieder zusammengefügt werden. Dies rührt daher, dass Leerzeichen in GEDCOM als Trennzeichen genutzt werden, für viele GEDCOM-Werte abschließende Leerzeichen abgeschnitten werden, sowie einige Systeme hinter dem Kennzeichen nach dem ersten nicht-Leerzeichen als Anfang des Wertes suchen.

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.

Bemerkung zur Notiz-Struktur: Es gibt besondere Dinge zu beachten, wenn das CONC-Kennzeichen eingesetzt wird. Es wird dazu benutzt, einen Notiztext anzugeben, der so zusammengefügt wird, dass das anzeigende Programm selbst abhängig von der Fenstergröße den Zeilenumbruch durchführen kann. Dafür ist es erforderlich, dass entweder die Zeilen mitten in einem Wort geteilt werden, oder am Ende eines Wortes, sodass das Leerzeichen in der nächsten CONC-Zeile vorangestellt wird. Ansonsten würden die meisten Betriebssysteme die Leerzeichen am Zeilenende entfernen, und das Leerzeichen geht beim Zusammensetzen der Notiz verloren.

Aussage aus den 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.

Das Folgende ist ein Beispiel für ein Quellzitat (SOURCE_CITATION) für die Geburt die keinen Zeiger auf einen Quelldatensatz (SOURCE_RECORD) enthält. (Es wird hierzu nicht ermutigt) [Dieses Beispiel wird hier gezeigt, weil es das Trennen der Zeilen durch CONC demonstriert: Immer zwischen zwei nicht-Leerzeichen]

0 INDI 
1 NAME Fred /Jones/ 
1 BIRT 
2 DATE 14 MAY 1812 
2 PLAC Tonbridge, Kent, England 
2 SOUR Waters, Henry F., Genealogical Gleanings in Englan 
3 CONC d: Abstracts of Wills Relating to Early Americ 
3 CONC an Families. 2 vols., reprint 1901, 190 
3 CONC 7. Baltimore: Genealogical Publishing Co., 1981. 
3 CONT Stored in Family History Library book 942 D2w 
3 CONC h; films 481,057-58 Vol 2, page 388.

Entscheidungsvorschläge für Vereinbarungen zu CONC beim Export

E1 Trennen von Text durch CONC

Laufender Text darf durch CONC nur an Stellen getrennt werden, die weder unmittelbar vor noch unmittelbar nach der Trennstelle ein Leerzeichen aufweisen.

E2 Anzahl der Begrenzer nach CONC

Nach dem Kennzeichen CONC darf nur genau ein Begrenzer stehen. Der Begrenzer ist ein einzelnes Leerzeichen. Unmittelbar danach beginnt der Zeilenwert (Text des Anwenders).

E3 Trennen von Text durch CONC, Ausnahme

Von der Vorschrift E1 darf nur abgewichen werden, wenn beim Trennen gemäß E1 Teiltexte entstehen, die zusammen mit den anderen Bestandteilen der GEDCOM-Zeile die maximal zulässige Anzahl von 255 Zeichen überschreiten. In diesem Fall soll nach Möglichkeit nach einem Zeichen getrennt werden, das kein Leerzeichen ist.

Entscheidungsvorschläge für Vereinbarungen zu CONC beim Import

I1 Zusammensetzen des Textes aus CONC-Zeilen

Es wird freigestellt, ob beim Zusammensetzen des Textes mit Teilen aus CONC-Zeilen der Textinhalt an der Trennstelle getrimmt wird, d.h. ob abschliessende Leerzeichen der vorherigen Zeile und auf das erste Leerzeichen nach CONC folgende weitere Leerzeichen entfernt werden.

I2 Empfehlung zum Zusammensetzen des Textes aus CONC-Zeilen

Für die Standardeinstellung beim Import wird unter Berücksichtigung von von den Exportvereinbarungen bzw vom GEDCOM Standard 5.5.1 abweichenden älteren Dateien oder Dateien von Drittprogrammen empfohlen, beim Zusammensetzen eines mit CONC getrennten Textes die abschliessenden Leerzeichen der vorhergehenden Zeile und die auf das erste Leerzeichen nach CONC folgenden weiteren Leerzeichen als Bestandteile des Zeilenwertes zu betrachten und damit als Dateninhalt zu erhalten.

Behandlung/Darstellung schwieriger Situationen

Wo trennt CONC den Text?

Die Aussage aus den Grammatikregeln und die Bemerkung zur Notiz weicht von der Aussage bei der Definition von CONC (Textverknüpfung) im Standard insofern ab, als sie die Trennung an einem Leerzeichen zulassen würde, und dabei das Leerzeichen an den Beginn des Wertes in der Folgezeile stellt. Da die Definition von CONC inkl einer passenden Begründung das Trennen an einer Leerstelle ausschliessen, ist das Verbot des Trennens an einer Leerstelle auch in die Entscheidungsvorschläge zu Vereinbarungen der Programmautoren aufgenommen worden.

Ein Verbot des Trennens an Leerstellen läßt beim Import dann ein "Trimmen" der Texte zu, d.h. zu Beginn und am Ende stehende Leerzeichen und Zeilenumbrüche werden komplett entfernt.

In der Liste wird aber auch die Position vertreten, das Trennen abweichend vom der Liste zugrundeliegenden Standard überall zuzulassen. Da dann Leerzeichen auch am Anfang bzw am Ende des Textes innerhalb einer GEDCOM-Zeile stehen können, darf in diesem Fall beim Import nicht "getrimmt" werden. Eine weitere Stellungnahme in der Liste befürwortet die Verwendung der in der Grammatikregel/Bemerkung zur Notiz beschriebenen Variante, dass bei Trennung an einem Leerzeichen dieses in die Folgezeile (also hinter CONC und dem Begrenzer) zu plazieren ist. Es ist dabei jedoch nicht mehr eindeutig zu erkennen, ob mehrfache Leerzeichen zwischen CONC und dem ersten nicht-Leerzeichen als Begrenzer (delimiter) oder als zum Dateninhalt ( =Text ) gehörende Leerzeichen zu interpretieren sind. Daher muss in diesem Fall auch beim Export explizit vorgeschrieben werden, dass nach dem Kennzeichen ( tag ) jeweils nur genau ein Leerzeichen als Begrenzer exportiert werden darf.

Da die Diskussion in der Liste uneinheitlich ist, wird die Entscheidung in der Abstimmung herbeigeführt.

Der Entscheidungsvorschlag E1, E2, I1 wurde in der Liste so begründet:

Wegen der Historie der GEDCOM-Standardversionen und der unterschiedlichen Realisierungen gibt es jetzt sowohl Dateien, die an Leerzeichen getrennt werden ( beim Import würde Trimmen den Verlust dieser zum Text gehörenden Leerzeichen bedeuten ) als auch Dateien, die mehr als ein Leerzeichen zwischen Kennzeichen und Zeileninhalt schreiben (beim Import ohne Trimmen würden zusätzliche Leerzeichen im Text auftauchen).

Die Kompatibilität zu allen diesen Dateien ist also nicht mit einer einheitlichen Importregel zu erreichen. Das beste Resultat muss notfalls mit einer eingestellten Option Trimmen aus oder Trimmen ein "ausprobiert" werden, wenn das importierende Programm diese Optionen anbietet. Jedenfalls brauchen wir je nach Fall einmal einen Import mit Trimmen und einmal einen Import ohne. Trimmen, um das "richtige" Ergebnis für den zusammengesetzten Text zu erzielen. Daher sollten wir freistellen, ob getrimmt wird oder nicht ( ==> I1 ).

Unser Ziel ist es, unsere Anwender von Datentransfer-Problemen zu befreien. Dies sollten wir insbesondere erreichen, wenn ein Anwender von einem der den Vereinbarungen folgenden Programm seine Daten in ein anderes, ebenfalls den Vereinbarungen folgenden Programm transferiert. Daher habe ich die Exportregeln nun so formuliert, dass das Datentransfer-Ergebnis ok ist, egal ob beim Import getrimmt wird oder nicht, d.h. beim Datentransfer zwischen "unseren" Programmen braucht der Anwender nichts auszuprobieren, da es sofort funktionieren würde:

• E1 stellt sicher, dass durch das Trimmen beim Import keine Leerzeichen aus dem Text verloren gehen.
• E2 stellt sicher, dass beim Import ohne Trimmen keine Leerzeichen in den Text eingefügt werden.

Wir hätten mit den Vereinbarungen E1, E2 und I1 einen Standard-konformen, unter unseren Programmen fehlerfrei funktionierenden Weg gefunden und gleichzeitig erhalten wir beim Import von älteren Dateien / Dateien von Drittprogrammen die notwendige Flexibilität.

Status:

Entscheidungsvorschlag formuliert

Abweichungen vom Standard bei der Verwendung

Leerzeichen am Ende der Zeile vor dem CONC-Kennzeichen sind nach Standard unzulässig, werden aber von einigen Programmen so exportiert.

Restliche Punkte sind keine Abweichungen, sondern Unsicherheiten aufgrund nicht eindeutiger Standardvorgaben:

• Leerzeichen zu Beginn des Zeilen_Wertes in einer CONC-Zeile?
• Fortsetzung jeder Zeile mit Text als Zeilen_Wert zulässig, oder nur nach solchen Kennzeichen, bei denen das explizit im Standard gezeigt wird?