[TSC-public] Progress on ELF

Louis Kessler lkessler at lkessler.com
Fri Oct 27 12:12:00 CDT 2017


Since ELF is supporting both GEDCOM 5.5. and GEDCOM 5.5.1, I think it will be very important to explicitly list all the differences between the two standards, and for each difference state if both will be supported or only one.  E.g.  CHAR UTF-8 is supported in GEDCOM 5.5.1 but not in GEDCOM 5.5.  ELF will support it.

You should also make clear that the GEDCOM 5.5 ELF is using is the Revised 10 January 1996 version and not the 2 January 1996 version. See:
http://blog-en.coret.org/2014/12/which-gedcom-55-grammar-is-correct.html

Also, the following tags are of concern and are seen "in the wild" and used or misused occasionally.  What is ELF's position on these:   AKA,  _AKA, URL, _URL, WITN, _WITN

Also, I am concerned about the ALIA tag:  http://www.beholdgenealogy.com/blog/?p=1074

I expect that BLOB will not be required to be handled in ELF.

Are GEDCOM EL extensions going to be considered or allowed in ELF 1.0?  GEDCOM EL should be acknowledged in ELF and either be specifically allowed or not allowed in 1.0.

Louis


-----Original Message-----
From: TSC-public [mailto:tsc-public-bounces at fhiso.org] On Behalf Of Luther Tychonievich
Sent: Fri, Oct 27, 2017 8:31 AM
To: Nick Hall <nick-h at gramps-project.org>
Cc: tsc-public <tsc-public at fhiso.org>
Subject: Re: [TSC-public] Progress on ELF

We are currently trying to document and restrict ELF to deviations from GEDCOM that are already present "in the wild".  We expect these to be few; the ones we've identified so far are three:

1. It appears that the common practice for same-sex marriages is to have a 0 FAM with a 1 HUSB and 1 WIFE but have both HUSB and WIFE point to 0 INDI with the same 1 SEX.

2. It appears that the "no more than three" constraint on EMAI/EMAIL, FAX, PHONE, and WWW sub-tags of ADDR is not generally followed, nor are the "1–60 character"-type limits on many tag payloads.

3. Some files appear to follow the (incorrect) example in the GEDCOM spec use

    0 SOUR
    1 REPO
    2 CALN
    2 MEDI

instead of the specification-required

    0 SOUR
    1 REPO
    2 CALN
    3 MEDI

(4?) I suppose technically a few other changes we are working on (such as allowing short payloads of PUBL tags) are also deviations from GEDCOM, but these seem to be pretty clearly corrections of mistakes, not adjustments of design.

We are also adding a few new tags to support future disciplined namespace-collision-free expansions to the data model; we are designing these tags such that ignoring them does not cause misinterpretation of the GEDCOM data and an import+export by an ELF system does not change what a GEDCOM-only application sees.

On Thu, Oct 26, 2017 at 5:58 PM, Nick Hall <nick-h at gramps-project.org> wrote:
> On 24/10/17 22:13, Richard Smith wrote:
>>
>> It is vital that ELF files produced by applications following the 
>> recommendations in ELF 1.0 will be readable by applications expecting 
>> GEDCOM, and that ELF applications can read current GEDCOM file, 
>> including files that deviate from the GEDCOM standard in various well-known ways.
>
>
> What deviations from the GEDCOM standard will ELF compliant 
> applications be required to read?
>
> Nick.
>
>
>
>
> _______________________________________________
> TSC-public mailing list
> TSC-public at fhiso.org
> http://fhiso.org/mailman/listinfo/tsc-public_fhiso.org

_______________________________________________
TSC-public mailing list
TSC-public at fhiso.org
http://fhiso.org/mailman/listinfo/tsc-public_fhiso.org




More information about the TSC-public mailing list