[TSC-public] Progress on ELF / user defined tags
Emmerich.Albert at t-online.de
Sat Oct 28 01:32:14 CDT 2017
In Gedcom-L we had four groups of "wild" tags:
1. tags without underscore as first character, not defined in GEDCOM standard, by that violating the standard. At import we recommend to replace these tags with other tags. We recommend not to export these tags.
2. tags with underscore as first character, user defined, because this tag is not defined in GEDCOM standard, however is needed. Some of these tags we recommended to use, and they are used very often (as _RUFNAME, _GODP, _WITN, _GOV, _LOC, _UID): de facto standard. These tags should be shown as standard elements in ELF.
3. tags with underscore as first character, defined in GEDCOM standard without underscore, however not allowed under another tag where we needed it. Example _POST: We use
2 PLAC <name of place>
3 _POST <postal code>
If GEDCOM standard would allow we had (and I think that to be the better version for ELF):
2 PLAC <name of place>
3 POST <postal code>
with POST as defined in GEDCOM standard. Other example is _ASSO / ASSO in FAM records / under event tags.
4. tags with underscore, user defined, however the same content can be described with structures and tags of GEDCOM standard. We recommend not to use these tags. Example: _MARN or _MARNM for the name after marriage. The multiple name structure in GEDCOM standard allows to show this name without any user defined tag.
As user defined tags may be defined in any way according to GEDCOM standard, and by this may be program specific, we recommend to explain the user defined tags in the HEAD record. This recommendation is found in
I think ELF will replace this definition by a more general one...
Von: TSC-public [mailto:tsc-public-bounces at fhiso.org] Im Auftrag von Richard Smith
Gesendet: Samstag, 28. Oktober 2017 00:50
An: tsc-public at fhiso.org
Betreff: Re: [TSC-public] Progress on ELF
On 27/10/17 20:41, Luther Tychonievich wrote:
> In general, non-documented tags appearing in the wild (and documented
> tags appearing out of place) are an expected part of GEDCOM, permitted
> in the specification, and we do not plan to change that (it would be a
> breaking change . We have discussed (many times, since long before we
> discussed ELF) creating a dictionary of these extensions, and some of
> the work we are doing now is anticipated to make that more feasible
> and useful (as will the several previous efforts to aggregate
> extension tags, including GEDCOM-L). However, we likely won't include
> most (if
> any) extensions we've seen "in the wild" in the initial release: only
> official ones and ones we feel necessary to enable future extensions.
I wonder how many of these extensions have multiple independent implementations which are mutually compatible? It seems to me that such extensions could be getting close to crossing the line between a vendor-specific extension and a de facto standard.
Richard Smith, FHISO <http://fhiso.org/>
FHISO Technical Co-Coordinator One Community, One Standard
More information about the TSC-public