The FTW TEXT article explains what FTW TEXT is. The FTW TEXT Problem documents the problem that FTW TEXT causes with regular GEDCOM readers.
One possible solution to those problems is to support FTW TEXT.
To do so, you need to distinguish between GEDCOM and FTW TEXT. The GEDCOM
Magic article explains how to correctly detect GEDCOM and FTW TEXT and
distinguish between them.
This article explains about how to support FTW TEXT in addition to GEDCOM, how to avoid the mistake many vendors make, and why you should avoid it.
It does not discuss whether you should FTW TEXT. That is discussed in Dealing with FTW TEXT.
There is no reason to write FTW TEXT. FTW TEXT is structurally identical to FTW GEDCOM, a GEDCOM dialect that many GEDCOM readers handle successfully.
Family Tree Maker for Windows (FTW) is the only application that writes FTW TEXT. It is a misfeature that no other vendor has duplicated. Several vendors doread FTW for compatibility’s sake.
A GEDCOM reader recognises GEDCOM tags and then acts upon the tags. One fairly natural approach to building a GEDCOM reader is to use a table that associates each tags with the things the GEDCOM reader must do when it encounters these tags.
Conceptually, some part of that table could look like this:
| GEDCOM tag | action |
|---|---|
ADDR | do ADDR thingies |
FAM | do FAM thingies |
HEAD | do HEAD thingies |
HUSB | do HUSB thingies |
TRLR | do TRLR thingies |
One reason that several vendors decided to support FTW in their GEDCOM readers is that it is not hard to do so. The only difference between FTW GEDCOM and FTW TEXT is the tags they use. Supporting FTW TEXT is just a matter of supporting the FTW TEXT tags. Just add the FTW TEXT tags into the table, so that the reader responds identically to the GEDCOM and FTW TEXT tags. Conceptually, that idea looks like this:
| GEDCOM or FTW TEXT tag | action |
|---|---|
ADDR or ADDRESS | do ADDR thingies |
FAM or FAMILY | do FAM thingies |
HEAD or HEADER | do HEAD thingies |
HUSB or HUSBAND | do HUSB thingies |
TRLR or TRAILER | do TRLR thingies |
Implemented as a simple alphabetical table, it looks like this:
| tag | action |
|---|---|
ADDR | do ADDR thingies |
ADDRESS | do ADDR thingies |
FAM | do FAM thingies |
FAMILY | do FAM thingies |
HEAD | do HEAD thingies |
HEADER | do HEAD thingies |
HUSB | do HUSB thingies |
HUSBAND | do HUSB thingies |
TRAILER | do TRLR thingies |
TRLR | do TRLR thingies |
The problem with this approach is that it is wrong. This approach this does not merely add FTW TEXT support to the GEDCOM support, but has another, probably unintended consequence too; it lowers the quality of the existing GEDCOM support.
In the modified table, the proprietary FTW TEXT tags have effectively been elevated to the status of synonyms for the GEDCOM tags they correspond with. That does not change the GEDCOM reader into a reader that supports both GEDCOM and FTW TEXT, but into a reader that supports FGTEWDTCEOXMT (pronounced: FTW-GED-TEXT-COM); it does not just accept FTW TEXT in addition to GEDCOM, but accepts any weird mix of GEDCOM and FTW TEXT.
An distinguishing property of a FGTEWDTCEOXMT reader is that because it does not tell GEDCOM and FTW TEXT apart, it fails to issue error messages about illegal tags.
A GEDCOM reader will accept FAM and HUSB, but complain about
illegal tags when it encounters FAMILY and HUSBAND. An FTW TEXT reader will accept FAMILY and HUSBAND, but complain about illegal tags when it encounters FAM and HUSB.
A FGTEWDTCEOXMT reader treats GEDCOM tags and FTW TEXT tags as synonyms in FGTEWDTCEOXMT; it allows any mix of GEDCOM and FTW TEXT tags.
The failure of a FGTEWDTCEOXMT to report illegal GEDCOM or illegal FTW TEXT tags is a failure to support either GEDCOM or FTW TEXT properly.
To support both GEDCOM and FTW TEXT, a single table of GEDCOM tags should not be replaced with one larger table for both GEDCOM and FTW TEXT tags, but with two tables; one table for GEDCOM and one table for FTW TEXT.
One table for GEDCOM:
| GEDCOM tag | action |
|---|---|
ADDR | do ADDR thingies |
FAM | do FAM thingies |
HEAD | do HEAD thingies |
HUSB | do HUSB thingies |
TRLR | do TRLR thingies |
And another table for FTW TEXT:
| FTW TEXT tag | action |
|---|---|
ADDRESS | do ADDR thingies |
FAMILY | do FAM thingies |
HEADER | do HEAD thingies |
HUSBAND | do HUSB thingies |
TRAILER | do TRLR thingies |
The GEDCOM / FTW TEXT reader must detect the file type and then use the appropriate table for processing the file. That way it can make sure the file is either a GEDCOM or a FTW TEXT file and continue to report illegal tags correctly.
Most vendors do not clearly document whether they support FTW TEXT, but
several do support it nonetheless.
Some genealogy applications that seem to read FTW TEXT files besides Family Tree Maker Classic itself are Personal Ancestral File (PAF), Ahnenblatt, MyHeritage Family Tree Builder, Legacy Charting, MudCreek GENViewer and GenSmarts. GenoPro 2007 generates a few message about custom tags, but does read the files.
I did not perform elaborate tests to determine whether applications fully support FTW TEXT or not. That these applications support FTW TEXT is just my initial impression based on quick testing with one small FTW TEXT file.
In The FTW TEXT Problem I showed how applications that do not support FTW TEXT respond when confronted with it it. The applications that aim to support FTW TEXT will not be confused by FTW TEXT, but that does not mean that those applications are not confused. As just explained, there is a right way and a wrong way to supporting FTW TEXT, and the wrong way is confused indeed.
I did perform another quick test to find whether these applications that aim to support FTW TEXT in addition to GEDCOM really support both GEDCOM and FTW TEXT or merely support FGTEWDTCEOXMT.
The test is very simple; I created an FGTEWDTCEOXMT file and then tried to import it. Only applications that mistakenly support FGTEWDTCEOXMT accept that mess. Application that support both GEDCOM and FTW TEXT will correctly report illegal tags.
Applications that do not create an import log file, such as Legacy
Charting and MudCreek GENViewer are not suddenly going to create one, but even for those applications this simple test is good enough.
After all, if they support GEDCOM and FTW TEXT correctly, they simply cannot make sense of the illegal tags, and should report some kind of fatal error. Thus, if they fail to report that fatal error, they fully deserve the conclusion I draw from that failure.
| application | version | supports |
|---|---|---|
| Family Tree Maker Classic | 16.0.350 | FGTEWDTCEOXMT |
| New Family Tree Maker | 200918.0.0.307 | FGTEWDTCEOXMT |
| Personal Ancestral File | 5.2.18.0 | FGTEWDTCEOXMT |
| Ahnenblatt | 2.60 | FGTEWDTCEOXMT |
| MyHeritage Family Tree Builder | 3.0.0.820 | FGTEWDTCEOXMT |
| GenSmarts | 2.1.1.43 | FGTEWDTCEOXMT |
| MudCreek GENViewer Lite | 1.15 | FGTEWDTCEOXMT |
| Legacy Charting | 7.0.120.951 | FGTEWDTCEOXMT |
I was surprised to note that not one of these applications got it right. All these applications made the mistake of adding FTW TEXT support in such way that they do not really support either GEDCOM or FTW, but FGTEWDTCEOXMT instead. Tags that are illegal in one but legal in the other are no longer reported as the errors they are.
That last test does not prove that these vendors do not care about adding FTW TEXT support the right way. It only shows that these vendors opted for a simple approach that seemed a solution without thinking the implications of that simple approach through, and ended up degrading their pre-existing GEDCOM support.
To bring their GEDCOM support back to the pre-mistake level, they need to either fix the way they support FTW TEXT or simply drop their FTW altogether. How fast they do either now that the quality-degrading mistake has been pointed out tells you how much they care about doing it right.
There are several good reasons do it right. First of all, the desire to do the right thing and provide a quality product. That earns a thumbs up. Secondly, the desire to make sure that your product is just as good or better than the competition. That looks good in comparisons.
But perhaps the most unexpected reason, one these vendors apparently never stopped to think about, is that the right way is noticeably faster. The right method detects the file type and then uses the appropriate, small table; it is practically as fast as a GEDCOM-only reader.
The confused approach uses one big table instead and that slows the program down. A table that is almost twice as big takes longer to search through. Its impact on total import time is not a factor two, but it is likely to be noticeable, and applications as slow as Family Tree Maker need every little bit.
Either removing the FTW TEXT support or using two separate tables restores the file reader to not just its former quality level, but its former performance level as well.
Added the implementation strategy sidebar suggesting implementing FTW GEDCOM reader after the GEDCOM reader, and FTW TEXT reader after the FTW GEDCOM reader.
Copyright © Tamura Jones. All Rights reserved.