Software should be able to read both its own databases and any files it writes it in some product-independent transfer format. For genealogy software, that means it should be able to read the GEDCOM files it writes.
Moreover, the current version of the software should be able to read any such files created by earlier versions, even if those earlier versions made mistakes. For genealogy software, that means that the current version should read any ostensible GEDCOM files created by earlier versions.
The user expect as much.
Genealogy software that has been around for decades must be able to import decades old database and GEDCOM files. After multiple changes of operating system, and development platform, that can become tricky to do, and vendors may opt for a workaround.
The current Family Tree Maker does not support databases created by Family Tree Maker 4 or earlier, nor GEDCOM files prior to GEDCOM version 5.5. To make up for that, Software MacKiev offers a free copy of Family Tree Maker 2005 Starter Edition, which cannot import those older files, and the current version will import FTM 2005 files.
Developers of new genealogy software face another challenge; figuring out how much legacy GEDCOM to support.
Today (2024), developers of new genealogy software may choose GEDCOM 5.5.5 as their export format, but while there is no compelling reason to support every legacy GEDCOM version, they cannot ignore GEDCOM 5.5.1 yet, and GEDCOM 5.5.1 support is problematic is more than one way.
The issue most obvious from even a cursory browse through the specification is that GEDCOM 5.5.1 allows multiple character sets and encodings, including one (ANSEL) that most developers have never even heard about before, and for which there is no ready-made support in the operating system.
Once developers have an early version of their at GEDCOM import working, they will quickly discover that the ostensible GEDCOM 5.5.1 files created by many products already in the market suffer from more errors and idiosyncrasies than they can ever hope to support if they want to release version one-dot-zero within their lifetime. Luckily, it is not really necessary to support all (ostensible) GEDCOM 5.5.1 files.
For some two decades now, the de facto GEDCOM standard has been GEDCOM 5.5.1 Annotated Edition (AE). Practically all of today’s software produces UTF-8 encoded GEDCOM 5.5.1 AE files. This makes it reasonable for new genealogy software to limit legacy GEDCOM support to just those files; UTF-8 encoded GEDCOM 5.5.1 files that start with a Byte Order Mark (BOM).
This practical choice is made even more practical by the fact that detection of UTF-8 encoded GEDCOM 5.5.1 AE files is extremely simple (see Detecting GEDCOM 5.5.1 Annotated Edition ).
wLimiting legacy GEDCOM support thusly will not avoid all GEDCOM 5.5.1 problems, but it does avoid many of them. Avoiding GEDCOM problems is preferable over having to solve them,, because time spent dealing with GEDCOM issues is spent at the expense of time for developing and improving product features.
Limiting legacy GEDCOM support thusly avoids dealing with other character sets than Unicode, It avoids pre-GEDCOM 5.5.1 issues. It also avoids older GEDCOM 5.5.1 issues, as support for and use of the UTF-8 encoding is associated with more recent products versions, and the Byte Order Mark, specific to Annotated Edition filers, is associated with yet more recent product versions.. Thus, limiting legacy GEDCOM support to UTF-8 encoded GEDCOM 5.5.1 AE files ensures that the GEDCOM import will generally deal with relatively high quality GEDCOM 5.5.1 files.
Developers will still have to deal with some third-party errors, and will also have to figure out which third-party GEDCOM extensions to support on GEDCOM import, but this limited legacy GEDCOM support is enough to import data from practically any third-party products.
Copyright © Tamura Jones. All Rights reserved.