[TSC-public] Progress on ELF / user defined tags
Emmerich.Albert at t-online.de
Sat Oct 28 13:47:50 CDT 2017
1. I do not know any program which cannot handle GEDCOM files with
"unknown" tags. The most common reactions are to ignore, to wrap in
NOTE, and/or to create a problem list for the import.
2. I will discuss this with the Gedom-L group. I think we will propose
to add some more tags to this group.
I agree to your point with _UID. The Gedcom-L group has different
solutions within the group, and we have not agreed for a common solution
how to handle this. However most programs of the group use _UID.
4. We had a discussion in our group about how to handle _MARN, however I
do not know how often it is used. I do know about _MREL and _FREL in
Family Tree Maker declaring the relationship of a child to its parents,
which makes a lot of headaches as the program Family Tree Maker does not
import correctly GEDCOM standard files using PEDI, however every
relation is put to _MREL natural, _FREL natural, which often is the
wrong information. Every FTM file has theses tags in FAM records; and
the information should be formed by PEDI in the INDI record of the child.
Am 28.10.2017 um 18:15 schrieb Richard Smith:
> On 28/10/17 07:32, Albert Emmerich wrote:
>> 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
> Are you aware of any applications that fail to import GEDCOM files
> containing such tags? We're currently planning to add several new
> tags without underscores to ELF, and so far as we're aware current
> applications will just ignore such tags, or perhaps preserve wrapped
> in a NOTE field. If that assumption is wrong, we may need to rethink
>> 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.
> Would you be willing to produce a list of tags that you think belong
> in this category? Or do you think it's just these six? It would also
> be helpful to know to what extent these have multiple independent and
> mutually compatible implementations. We haven't definitely decided
> that's a criterion for inclusion in ELF, but I think knowing that
> would help.
> I have some concerns about standardising _UID, due to the way it has
> been used somewhat incompatibly by various providers, e.g. as
> documented by Tamura Jones, here:
> I'm not saying that means we can't include it in ELF, but we will need
> to take care how we do it.
>> 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.
> I agree. If any of these uses are to be included in ELF, I'd rather
> it was with the natural spelling (i.e. without an underscore).
>> 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.
> Have any of these have been widely used? I can't immediately think of
> any that have.
>> 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...
> Interestingly, we were discussing this only two days ago. Our current
> feeling is that there should be something like this, and that it may
> well use SCHEMA tag form GEDCOM 5.3 but it will certainly go beyond
> the facilities that facilities of the GEDCOM 5.3 SCHEMA tag.
> We haven't really discussed how much we care about about compatibility
> with the GEDCOM 5.3 SCHEMA tag syntax. How many applications actually
> read it?
More information about the TSC-public