[TSC-public] Progress on ELF
tychonievich at gmail.com
Fri Oct 27 08:31:06 CDT 2017
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
instead of the specification-required
(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?
> TSC-public mailing list
> TSC-public at fhiso.org
More information about the TSC-public