Some familiarity with GEDCOM, the fan value and the GedFan utility is assumed. You may want to read The Fan Value and GedFan first.
The Fan Value article seems crystal clear on what's expected from applications when using the GEDCOM files created by GedFan to determine an application's fan value:
There are only two GEDCOM-related demands: the GEDCOM importer has to read the data correctly, and if the application is a genealogy editor, its GEDCOM exporter has to export the data again into a valid GEDCOM file, adding nothing, omitting nothing.
The exported GEDCOM file should be GEDCOM version 5.5.1 (or later), but GEDCOM 5.5 is accepted. The exported GEDCOM may use any valid character encoding, and may contain all kinds of vendor-specific GEDCOM extensions, but it has to be a valid GEDCOM file. That specifically means that the file should have a valid GEDCOM header. An application that produces invalid GEDCOM files has GEDCOM fan value 0.
Valid GEDCOM in, valid GEDCOM out, please.
However clear that may seem, a question I received from a vendor today prompted this article as clarification.
The fan files generated by GedFan are GEDCOM 5.5.1 files.
As the GedFan article notes, any current genealogy application should be able to read these files
as GEDCOM 5.5.1 has been the de facto standard for more than a decade already.
However, the fan files produced by GedFan aren't meant to test GEDCOM 5.5.1 support or make legacy applications fail,
and The Fan Value explicitly states that, although the exported GEDCOM file should be GEDCOM version 5.5.1 or later,
GEDCOM 5.5 is accepted.
The WWW tag is one of the useful tags introduced in GEDCOM 5.5.1.
The fan files uses the WWW tag to provide a link back to this site.
The Family Tree Maker 2012 Fan Value article remarks on FTM 2012's lack of support for GEDCOM 5.5.1,
as evidenced by its Line 22 : error 4 : Invalid tag: WWW. Line ignored.
error message.
The WWW tag is not invalid, so that is an erroneous error message.
It would have been a valid error message if it had said Invalid GEDCOM 5.5 tag
instead of Invalid tag
.
It would have been an accurate message if it had said something like Unrecognised tag for unsupported GEDCOM version
.
The Family Tree Maker 2012 Fan Value article concludes that Family Tree Maker 2012's fan value is zero,
but neither the erroneous error message nor its lack of support for GEDCOM 5.5.1 is the reason for that conclusion.
The reason is that the ostensible GEDCOM files that FTM 2012 produces do not validate,
and that is because of another issue with the FTM 2012 GEDCOM header.
Any application that supports GEDCOM 5.5.1 should read and write the WWW tag.
An application that still doesn't support GEDCOM 5.5.1 will not recognise the WWW tag.
Determination of the fan value does not place any demands on error handling, so any error message may be ignored.
However, failure to read the WWW record will lead to failure to write it,
i.e. omitting something that was in the input, and omitting data is not allowed.
However, The Fan Value explicitly states that valid GEDCOM 5.5 output is acceptable;
it is okay to use GEDCOM 5.5, but it still has to be valid GEDCOM 5.5.
There is no WWW tag in GEDCOM 5.5, so use of the WWW tag within a GEDCOM 5.5 file would invalidate that file.
Moreover, legacy applications that do not support GEDCOM 5.5.1,
even the ones that extend GEDCOM 5.5 with a private tag to support URLs,
cannot be expected to recognise the WWW tag and map it to their private tag.
The question I received is whether failure to recognise the WWW tag on input automatically results in a fan value of zero.
So the answer is no, it does not.
Failure to support GEDCOM 5.5.1 is a major shortcoming that should be mentioned,
but fan value determination isn't a GEDCOM 5.5.1 coverage test.
Well, the exact question I received is whether an erroneous error message,
such as produced by Family Tree Makere 2012, automatically results in a fan value of zero.
The answer still is no, it does it.
The fan files are supposed to be valid GEDCOM files, to test capacity, not support for GEDCOM dialects.
Any GEDCOM error messages that occur for supposedly valid GEDCOM files are noteworthy, particularly erroneous ones.
Mentioning an erroneous error message that reveals lack of support of GEDCOM 5.5.1 gets two things done in one stroke.
The fan value is a measure of capacity.
It isn't about error handling at all.
The quality of the error handling does not affect the fan value.
The fan files created by GedFan contain the WWW tag.
All applications have to read and write the GEDCOM data, and are not allowed to add or omit anything,
but an application that still doesn't support GEDCOM 5.5.1 cannot handle the WWW tag.
If it comes across a WWW tag, it won't read it, so it won't write it either;
the link provided in that tag will be omitted from the output…
The fan files created by GedFan contain the WWW tag,
but it does not occur in the GEDCOM data, it only occurs in the GEDCOM header and the submitter record.
Applications should not add anything to or omit anything from the GEDCOM data, and provide their own GEDCOM header.
A valid GEDCOM header not only specifies the GEDCOM version, character set and encoding,
it also contains such things as the application name and version, and the vendor's address.
The WWW tag is part of the address structure.
A GEDCOM reader should examine such fields as the GEDCOM version to determine whether it can read the file,
but will generally ignore such fields as the vendor's address.
That information is in there for human readers.
A GEDCOM writer provides its own application name, version and vendor address.
Replicating the another vendor's name, version or address would be a mistake.
The submitter record contains a WWW tag in the submitter's address record.
An application that supports GEDCOM 5.5.1 should preserve it,
and failure to do so deserves to be mentioned, but does not affect the fan value.
The GEDCOM specification expects older applications to ignore newer tags:
the receiving system will ignore data which it does not
understand and process only the data that it does understand.
.
Thus, an application that doesn't supports GEDCOM 5.5.1 should omit the WWW tag.
Adding a note field because of the unrecognised tag would be an serious error
that deserves to be mentioned, but still does not affect the fan value.
If either the GEDCOM header or the submitter record is invalid, the file isn't a valid GEDCOM file.
The demand is exporting the data again into a valid GEDCOM file,
adding nothing to and omitting nothing from the the data.
To be a valid GEDCOM file, the output file must contain a valid GEDCOM header and submitter record.
If either the GEDCOM header or the submitter record is invalid, the file isn't a valid GEDCOM file.
The header should provide the vendor's own address, with or without a link to their own web site.
The submitter record should import and export correctly, and any errors should be noted.
The values of the GEDCOM header and submitter record aren't important to a capacity test,
what matters in the ability to import the data, handle it, and export it again.
The few tags the fan files use for the data are all core GEDCOM tags, common to GEDCOM 5.5 and GEDCOM 5.5.1.
The few tags the fan files use for the data are all core GEDCOM tags, common to GEDCOM 5.5 and GEDCOM 5.5.1.
The inclusion of the WWW tags is not useless.
The web links obviously inform human readers where to find out more about the fan files,
but that is not all the WWW record good for.
It is handy to know whether an application supports GEDCOM 5.5.1,
and the two WWW tags provide a quick GEDCOM version check.
Some genealogy applications ignore the GEDCOM version provided in the GEDCOM header, or simply assume that 5.5.1 is compatible with 5.5.
The presence of the WWW tag in the GEDCOM header may still provoke such application into admitting that it does not support GEDCOM 5.5.1.
However, the WWW tag in the GEDCOM header might simply be ignored without an error message.
The whole vendor address might be ignored, as it need not be replicated in GEDCOM output anyway.
The second WWW tag, in the submitter record, provides another check;
an application that supports GEDCOM 5.5.1 application should replicate it,
an application that only supports GEDCOM 5.5 should omit it.
Copyright © Tamura Jones. All Rights reserved.