The illegal VERS value invalidates the GEDCOM header and as a rule, GEDCOM readers should reject files that do not even contain a valid GEDCOM header. A forgiving GEDCOM reader that recognises the illegal value could issue a non-fatal error and continue.
I would not classify Behold as a forgiving GEDCOM reader, rather one that 'can read and error report' on most (all?) GEDCOM files.
I included support for GEDCOM 5.5EL in Version 1.0.1. The info in the _LOC records is merged into Behold's Place details. Behold already had support for the _WITN tag and Behold's method of handling the ASSO and TYPE tags will handle them. The Find Files window will also identify GEDCOM 5.5EL files.
Tamura is more careful in his selection of terminology than most people. I most often agree with his judgements.
I will be implementing "perfect" GEDCOM input parsing in Version 1.5, which will report on all problems, but will still allow almost anything. That exercise will be necessary to ensure that the GEDCOM output Behold will produce is 100% compliant.
currently, a group of German programmers are working to make their GEDCOM export and import more standard compliant and compatible to each other.
They have not yet finished, but there is a GEDCOM test file that aims to use every tag that is defined in GEDCOM and every convention they have agreed on. Part of what they have agreed to is to allow a 5.5EL-like Place structure.
Putting the test file into Behold, I saw only one error message ("LANG" is not a valid GEDCOM tag) so it seems they followed the standard quite well.
There are some _LOC tags that build a hierarchy, with some extra complications. Some of those things show up under "Undefined Records" in Behold.
Maybe you can find something useful for yourself in that file.
Thank you for the link to those files. I've now added them to my test suite for Behold.
The _LOC records that are at level 0 should not be giving Undefined Records. I have tested only a few GEDCOM 5.5EL files since I haven't been able to find very many of them. And those were extremely simple ones. For those, Behold understands the _LOC tag and _LOC record and displays them properly.
But your examples are a little more complex. I'll take a look and see if I can get them to display properly in Behold.
Joined: Mon, 12 Jan 2009
36 blog comments, 59 forum posts
Posted: Fri, 2 Mar 2012
Louis
Wondering what Behold does with GEDCOM 5.5EL.
See http://www.tamurajones.net/DetectingGEDCOM5.5EL.xhtml
Also, Tamura states:
The illegal VERS value invalidates the GEDCOM header and as a rule, GEDCOM readers should reject files that do not even contain a valid GEDCOM header. A forgiving GEDCOM reader that recognises the illegal value could issue a non-fatal error and continue.
I would not classify Behold as a forgiving GEDCOM reader, rather one that 'can read and error report' on most (all?) GEDCOM files.
Joined: Sun, 9 Mar 2003
288 blog comments, 245 forum posts
Posted: Sat, 3 Mar 2012
Brett:
I included support for GEDCOM 5.5EL in Version 1.0.1. The info in the _LOC records is merged into Behold's Place details. Behold already had support for the _WITN tag and Behold's method of handling the ASSO and TYPE tags will handle them. The Find Files window will also identify GEDCOM 5.5EL files.
I talked about GEDCOM 5.5EL in my "The Place Record in GEDCOM" post.
Tamura is more careful in his selection of terminology than most people. I most often agree with his judgements.
I will be implementing "perfect" GEDCOM input parsing in Version 1.5, which will report on all problems, but will still allow almost anything. That exercise will be necessary to ensure that the GEDCOM output Behold will produce is 100% compliant.
Louis
Joined: Thu, 5 Sep 2013
9 blog comments, 9 forum posts
Posted: Thu, 5 Sep 2013
Hi Louis,
currently, a group of German programmers are working to make their GEDCOM export and import more standard compliant and compatible to each other.
They have not yet finished, but there is a GEDCOM test file that aims to use every tag that is defined in GEDCOM and every convention they have agreed on. Part of what they have agreed to is to allow a 5.5EL-like Place structure.
The current files are available at
http://wiki-de.genealogy.net/GEDCOM_Musterdatei/Musterdatei
They are updated from time to time, as the agreements are not yet fixed.
Putting the test file into Behold, I saw only one error message ("LANG" is not a valid GEDCOM tag) so it seems they followed the standard quite well.
There are some _LOC tags that build a hierarchy, with some extra complications. Some of those things show up under "Undefined Records" in Behold.
Maybe you can find something useful for yourself in that file.
Cheers
Klemens
Joined: Sun, 9 Mar 2003
288 blog comments, 245 forum posts
Posted: Thu, 5 Sep 2013
Klemens,
Thank you for the link to those files. I've now added them to my test suite for Behold.
The _LOC records that are at level 0 should not be giving Undefined Records. I have tested only a few GEDCOM 5.5EL files since I haven't been able to find very many of them. And those were extremely simple ones. For those, Behold understands the _LOC tag and _LOC record and displays them properly.
But your examples are a little more complex. I'll take a look and see if I can get them to display properly in Behold.
Louis