GEDCOM/CONC-Tag: Unterschied zwischen den Versionen
(→Abweichungen vom Standard bei der Verwendung: Text eingefügt, zusätzl.Anbindung an Kategorie ...In Abstimmung) |
(Abstimmungsergebnis eingepflegt) |
||
Zeile 44: | Zeile 44: | ||
3 CONC h; films 481,057-58 Vol 2, page 388.</source> | 3 CONC h; films 481,057-58 Vol 2, page 388.</source> | ||
== | == Vereinbarungen zu CONC beim Export == | ||
Folgende Vereinbarungen zum Export und zum Import haben die Programmautoren getroffen: | |||
'''E1 Trennen von Text durch CONC''' | '''E1 Trennen von Text durch CONC''' | ||
Zeile 60: | Zeile 62: | ||
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. | 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. | ||
== | == Vereinbarungen zu CONC beim Import == | ||
'''I1 Zusammensetzen des Textes aus CONC-Zeilen''' | '''I1 Zusammensetzen des Textes aus CONC-Zeilen''' | ||
Zeile 75: | Zeile 77: | ||
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 | 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 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. | 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 | In der Liste wurde 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 (was weiterhin bei älteren Dateien und bei DAteien von Drittprogrammen der Fall sein kann), darf in diesem Fall beim Import nicht "getrimmt" werden. | ||
Eine weitere Stellungnahme in der Liste befürwortete 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. | |||
Die im vorhergehden Abschnitt gezeigten Vereinbarungen E1, E2, E3, I1 und I2 wurden von den Programmautoren bei der Abstimmung mit großer Mehrheit getroffen. | |||
Der Entscheidungsvorschlag E1, E2, I1 | Der Entscheidungsvorschlag E1, E2, I1 war in der Liste so begründet worden: | ||
''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).'' | ''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).'' | ||
Zeile 100: | Zeile 104: | ||
Status: | Status: | ||
'' | ''Vereinbarungen getroffen'' | ||
=== Abweichungen vom Standard bei der Verwendung === | === Abweichungen vom Standard bei der Verwendung === | ||
Zeile 107: | Zeile 111: | ||
Restliche Punkte sind keine Abweichungen, sondern Unsicherheiten aufgrund nicht eindeutiger Standardvorgaben: | Restliche Punkte sind keine Abweichungen, sondern Unsicherheiten aufgrund nicht eindeutiger Standardvorgaben: | ||
* Fortsetzung jeder Zeile mit Text als Zeilen_Wert zulässig, oder nur nach solchen Kennzeichen, bei denen das explizit im Standard gezeigt wird? | * Fortsetzung jeder Zeile mit Text als Zeilen_Wert zulässig, oder nur nach solchen Kennzeichen, bei denen das explizit im Standard gezeigt wird? | ||
<!-- 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-In Abstimmung|{{SUBPAGENAME}}]] | [[Kategorie:GEDCOM-Tag-In Abstimmung|{{SUBPAGENAME}}]] |
Version vom 26. Januar 2010, 23:06 Uhr
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.
Vereinbarungen zu CONC beim Export
Folgende Vereinbarungen zum Export und zum Import haben die Programmautoren getroffen:
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.
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 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 wurde 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 (was weiterhin bei älteren Dateien und bei DAteien von Drittprogrammen der Fall sein kann), darf in diesem Fall beim Import nicht "getrimmt" werden.
Eine weitere Stellungnahme in der Liste befürwortete 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.
Die im vorhergehden Abschnitt gezeigten Vereinbarungen E1, E2, E3, I1 und I2 wurden von den Programmautoren bei der Abstimmung mit großer Mehrheit getroffen.
Der Entscheidungsvorschlag E1, E2, I1 war in der Liste so begründet worden:
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:
Vereinbarungen getroffen
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:
- Fortsetzung jeder Zeile mit Text als Zeilen_Wert zulässig, oder nur nach solchen Kennzeichen, bei denen das explizit im Standard gezeigt wird?