I’ve tweeted over the last few days of GEDCOM X’s announcements on its blog posts. I’ve followed its progress since Tamura Jones broke the news about it last December. I met Ryan Heaton, the employee of FamilySearch doing the most work on it, at RootsTech in February, and listened to his talks on the project. I’ve participated on the GEDCOM X community issue tracker, putting my two cents worth in when the need was there. I provided feedback to them in a March blog post.
They’ve now made their data format public. I’ve really only had a cursory look at it. I don’t have time currently to go into detail into exactly what their structures are. My main concern is that GEDCOM X will represent some of its data structures in very different ways than most genealogy programs, e.g. no family record and just relationships. Almost every program uses the GEDCOM lineage-linked structure with families and individuals and FAMC, FAMS, HUSB, WIFE and CHIL connectors. It would seem logical that programmers should change their internal structures to something else if that something else became the new standard. But that’s asking a lot.We’re talking about ripping out the guts of a program. If the structures are easily mappable, then they could be handled. But if they’re easily mappable, then why is a new standard needed at all?
I did try their GEDCOM 5.5 to GEDCOM X translator on one file, and then unzipped the file to see that it made a thousand
JSON XML files. There is no inherent difference between XML and the GEDCOM grammer. They are probably mappable back and forth.
There are quite a number of
JSON XML components for Delphi to choose from, e.g: https://www.google.com/search?q=delphi+xml but I personally don’t look forward to having to implement such a thing. With GEDCOM, I’m in control of the way Behold parses and I can optimize it appropriately.With 3rd party packages, it’s someone else’s code.
Converting the input between GEDCOM, XML, JSON or whatever is the easy (almost trivial and mechanical) part. The hard part will be incorporating the concepts that GEDCOM X has that GEDCOM and Behold don’t have into Behold. That is the part that scares me. If the differences are considerable, then it will severely hamper GEDCOM X’s full adoption into existing programs. That will give the horrible result of partial incorporation, meaning that GEDCOM X will not transfer all data between all programs, and thus be no better than GEDCOM is today.
For example, you can’t expect programs that don’t have an extensive citation capability to add one just because they find it in GEDCOM X. Or what if they had one, but it was structured very differently. And if GEDCOM X decides to throw in every possibility under the sun, or complicate things with complex multi-level multi-linked structures, you’ll be sure some programs just won’t get them right, or will refuse to do them to the level specified. The more complex the spec, the harder it will be to interpret correctly, and the more resistant the developer will be to implementing it.
GEDCOM X will have to be comprehensive, yet be as simple as possible. Those are two goals that work against each other, so it will be difficult to get the balance just right. It will have to use a 99% rule, and not try to include the other .999% which will increase the complexity level 1000-fold.
GEDCOM X will need allies. They’ll need to work with the FHISO folk. They’ll have to be wary of Ancestry.com and MyHeritage who have their own data transfer ideas. They’d likely also want to get AncestorSync involved early on.
I’m hoping for it. I really am. But they’ll have a hard sell.
June 9: Ryan Heaton corrected me. GEDCOM X uses XML, not JSON. I’ve updated my post to reflect this.