Just getting back to checking my own GEDCOM with Behold.
In my early days, I added some lines such as: 2 DATE yes
Currently Behold tells me: Behold will change this to a date phrase by adding parenthesis ....
Perhaps it would be better to check for this and convert it to the acceptable 'Y', rather than a date phrase.
GEDCOM's error checking is only "good" right now. It will get much better when I implement export to GEDCOM 5.5.1 because I'll have to ensure the export is completely valid.
I also will be trying to do simple corrections to input when the GEDCOM is wrong, if it is obvious and non-ambiguous what the data was intended to be.
In your example, 2 DATE does not allow a Y or a yes. The Y must be at the event at the level above, e.g. 1 DEAT Y, and it is only allowed on a BIRT, CHR, MARR or DEAT. (Frankly, having Y on a BIRT event makes no sense to me.)
In cases where it is not obvious what is meant by the GEDCOM, I figure it is better to just indicate a problem, and let the user fix it themself rather than risk Behold making an incorrect assumption. For example, 2 DATE 1845/6 could be a double date and changed to the valid 2 DATE 1845/46 or it could have been 2 DATE FROM 1845 TO 1846. It is not clear and I shouldn't assume.
There are some date problems that Behold does fix. The rest it converts to date phrases just so they will be valid GEDCOM.
Your example is a bit more complex as I say because it will involve inspecting the tag above. I'll consider it when I expand the data correction when I write the GEDCOM export routines.
Joined: Mon, 24 Nov 2014
10 blog comments, 13 forum posts
Posted: Tue, 17 Mar 2015
Just getting back to checking my own GEDCOM with Behold.
In my early days, I added some lines such as: 2 DATE yes
Currently Behold tells me: Behold will change this to a date phrase by adding parenthesis ....
Perhaps it would be better to check for this and convert it to the acceptable 'Y', rather than a date phrase.
Joined: Sun, 9 Mar 2003
288 blog comments, 245 forum posts
Posted: Tue, 17 Mar 2015
GEDCOM's error checking is only "good" right now. It will get much better when I implement export to GEDCOM 5.5.1 because I'll have to ensure the export is completely valid.
I also will be trying to do simple corrections to input when the GEDCOM is wrong, if it is obvious and non-ambiguous what the data was intended to be.
In your example, 2 DATE does not allow a Y or a yes. The Y must be at the event at the level above, e.g. 1 DEAT Y, and it is only allowed on a BIRT, CHR, MARR or DEAT. (Frankly, having Y on a BIRT event makes no sense to me.)
In cases where it is not obvious what is meant by the GEDCOM, I figure it is better to just indicate a problem, and let the user fix it themself rather than risk Behold making an incorrect assumption. For example, 2 DATE 1845/6 could be a double date and changed to the valid 2 DATE 1845/46 or it could have been 2 DATE FROM 1845 TO 1846. It is not clear and I shouldn't assume.
There are some date problems that Behold does fix. The rest it converts to date phrases just so they will be valid GEDCOM.
Your example is a bit more complex as I say because it will involve inspecting the tag above. I'll consider it when I expand the data correction when I write the GEDCOM export routines.
Louis