There is in fact very little difference between the two. In 5.5.1, the BLOB tag was removed and 8 tags were added, including some important ones like EMAIL, WWW, LATI and LONG, and a few extra syntactical changes were added that improved 5.5. Many programs now export these extras.

A program that can read valid 5.5.1 can also read valid 5.5, except for the BLOB tag which I don’t believe is used any more by any current program, and I’m not sure if it can be displayed by any program (maybe GEDitCOM). I have never found a GEDCOM that actually uses BLOBs other than a GEDitCOM-generated file used for testing GEDCOM readers. So I’ve not bothered to implement interpretation of what the blob is supposed to be.

A program exporting to 5.5 would have to do something with those extra 5.5.1 tags and enhanced syntax, and that would compromise the user’s data. A program exporting to 5.5.1 would only lose the BLOG tag.

So overall, there are minor trade-offs between using GEDCOM 5.5 and GEDCOM 5.5.1.

Prior to implementing GEDCOM export, I’ll take a more detailed look at what some other programs do and then decide on what might be best for Behold to export to. I do want only one export version, though.

I am looking forward to the ’soon will have Behold to to convert their file back to standard GEDCOM’.

By the way, what is your idea of standard GEDCOM, 5.5 or 5.5.1.

Thanks

Developers will need a good reason to change before they would. A new standard will have to be not too difficult to implement. It will have to be able to still work without requiring modifications to their current database. And it will have to offer them something that is so important they can’t refuse, and that will be important to them if their competition is using it and/or their users demand it. Maybe some slick implementation of sources/citations, evidence/conclusions or internationalization might entice them.

As far as the incorrect GEDCOMs go, those users today are very lucky. If and when a new standard comes out, there will be at least a few programs made to convert GEDCOM to the new standard. Some of the programs will do extended GEDCOM better than others. And I know I’ll add that conversion ability into Behold as well. So they really don’t have to worry about it for quite a while yet. The fact that GEDCOM today is so pervasive is what provides this safety and the fact that it was able to get that way is what makes me say we are very lucky as genealogists to have had it.

Developers could and probably should, but don’t and won’t have to write their own conversion routine unless they have a good reason to. Ancestry.com didn’t write a conversion routine for their FTW Text leaving many of their users in the exact situation you describe - but Ancestry didn’t care. And those FTW Text files now have Behold to view their data and soon will have Behold to to convert their file back to standard GEDCOM. So the users are all safe for now.

Louis

What do you consider the likelihood of developers being willing to compromise and adapt their programs to work with any standards decided?

How does one address the many users who are happy with their program as is (not knowing GEDCOM export/import difficulties) and do not upgrade their software, so that there will still be incorrect GEDCOM files being created/distributed? Would each developer need to also adapt their programs to correctly import GEDCOM, as is your goal for Behold?

Brett

After reading your blogposting I decided to examine the 4638 GEDCOM’s which genealogists uploaded. I searched for files containing 29 FEB ***1, 29 FEB ***3, 29 FEB ***5, 29 FEB ***7 or 29 FEB ***9.

PRO-GEN > 26
GensDataPro > 22
MyHeritage Family Tree Builder > 21
BROSKEEP > 7
Aldfaer > 1
gwb2ged > 1
OEDIPUS_II > 1
PhpGedView > 1
Reunion > 2
Stamboom > 1

So Dutch programmers have some work to do too…

I don’t think the reason for fail will be lack of developer involvement. Tom Wetmore who developed Lifelines, was involved in GenTech and is now developing DeadEnds has been a major contributor. Michael Martineau of Family Pursuit has also been a contributor.

Then we’ve had involvement from AncestorSync who is in turn involved and has connections to many of the major vendors. Bruce Buzbee of RootsMagic has attended a few developer meetings. Gordon Clarke of FamilySearch has been helping with the organization of the BetterGEDCOM group. And Legacy has offered its citation templates for BetterGEDCOM’s SourceTemplates.org endeavor.

I don’t think it would be hard to get other developers involved if BetterGEDCOM started producing something tangible that others could evaluate. My current push is to get them to produce the Source/Citation definitions that have been talked about. BG’s got to produce something soon in order to stay relevant, and there would be no better time to do that than just prior to RootsTech.

I said BetterGEDCOM might be doomed to fail, not because developers aren’t involved, but because the developers would not willing to compromise and adapt their programs to work with whatever standards are decided upon.

Louis