* Tamura Jones criticising Family Historian again

[Valkrider]

It seems as though Tamura Jones doesn't like Family Historian.

He has written yet another article about Gedcom v5.5 and v5.5.1 and the way that other programmes handle 'unknown' sex and Family Historian comes in for more criticism.

See https://www.tamurajones.net/GEDCOMSEX.xhtml

[tatewise]

I used to think differently, but having been exposed to many other products with the Export Gedcom File Plugin, I now sympathise with his argument.

FH does now support many of the Gedcom Draft V5.5.1 features both on import and export.
That includes the UTF-8 encoding, which is invalid for Gedcom V5.5, and V5.5.1 structures used by other products such as the FILE tag in Media records that is invalid in Gedcom V5.5.

See Wish List Ref 390 Gedcom Standard 5.5.1.

The Gedcom Version used is specified in the Gedcom Header.
FH should be able to import either V5.5 or V5.5.1 automatically and almost does so now.
FH should be able to export either V5.5 or V5.5.1 and partially does so now.
FH should switch to using V5.5.1 internally by default or have a Tools > Preferences setting to choose the version.
The benefits are that it would interoperate better with other products that mostly use V5.5.1 and would avoid the criticisms from reviewers who often deprecate FH because it does not support V5.5.1.

I raised this issue with Calico Pie Support a year ago :-
Subject: GEDCOM 5.5 and 5.5.1 Support Ticket: #867999
"I know you prefer GEDCOM 5.5 but there are strong arguments for at least supporting GEDCOM 5.5.1.
See The Perils of Following the GEDCOM Standard and Why All Genealogy Apps Should Support GEDCOM 5.5.1 by Keith Riggle, plus GEDCOM 5.5.1 isn't a Draft and others in Tamura Jones ~ Genealogy series.
Family Historian does already support UTF-8 and the FILE tag in Media records that are both only defined in GEDCOM 5.5.1 and supports other structures that are not strictly GEDCOM 5.5 compatible, so why not at least support import and export of GEDCOM 5.5.1 format that is employed by so many other products?"

The reply was as follows with nothing since :-
"Thanks for the feedback I have passed it on for consideration."

[ColeValleyGirl]

Mike is right in some respects -- if FH is going to sell itself on Gedcom compatibility, it ought to move to 5.5.1.

However, I suspect that's an awful lot of work to ensure it's done correctly root and branch, And frankly, I'd rather see that effort go into new functionality (formatted text anyone?) or fixing bugs that impact many people.

[AdrianBruce]

... I suspect that's an awful lot of work to ensure it's done correctly root and branch, ...

And we know the GEDCOM 5.5.1 proposal is riddled with inconsistencies - examples don't match the defined format, e.g., and the principles for Family attributes and events are different from those for Individual attributes and events. I very much doubt that all those issues were ever intended. And they have I suspect, been interpreted differently. One inconsistency came up a couple of years ago, and the writers said, "Clearly what FS meant was ...." Err no - not clear at all why one option should be regarded as the one and only true proposal.

Tamura is mercilessly exact on some things (not without reason) but promotes the concept of 5.5.1 as a de facto standard - which is a contradiction in terms, especially when the document is clearly just an incomplete proposal.

... frankly, I'd rather see that effort go into new functionality (formatted text anyone?) or fixing bugs that impact many people.

Me too. Frankly, I really don't transfer my data to a GEDCOM 5.5.1 program that often - if I did, it would be for using their superior citation templates and formats, which, err... don't transfer in any sort of GEDCOM! Though I'd quite like to see 5.5.1 features on a case by case basis, where they benefit us.

Perhaps we should do something easier first - like decide whether League or Union is the better form of Rugby!

[ColeValleyGirl]

Netball beats everything hands down but not as much as chilling in the garden with a glass of wine.

(Unfortunately, chilling in the garden for the next week is going to be too literal here in England.)

[tatewise]

Both 5.5 and 5.5.1 have several inconsistencies, but product usage appears to have come to a de facto agreement about most of them, largely driven by the market leaders.

Many users do appear to regularly transfer their data by Gedcom and if FH had better interoperability it might become even more popular. Better compatibility, better reviews, would lead to more users, more Calico Pie income, and hopefully more features and fixes.

[AdrianBruce]

Yes, I sort of agree, Mike, but I fear issues coming from the partial state of 5.5.1 - it's not as if it was just a signature away from formal acceptance, there are gaping holes that we've seen. (E.g. do you follow the standard or the examples? Which way do "other apps" go?)

Probably a way forward for 5.5.1 compatibility (which I think I voted for!) is to maintain the advertised full compatibility with 5.5 and then advertise just partial compatibility with certain major features of 5.5.1 - take it bit at a time, can't be worse than some other stuff!

[tatewise]

There are enough products employing 5.5.1 to follow their de facto lead and I think all the changes are only syntactic.
Many of the changes are simply Tag names _ATTR > FACT, _EMAIL > EMAIL, _WEB > WWW, _FILE > FILE.
There is a minor restructuring of Media record tags to move FORM below FILE and allow multiple FILE instances.
Some subsidiary tags are added to NAME and PLAC plus a few other structures.
Both Events and Attributes are allowed to have a value whether standard, custom, Individual, or Family.
I know there are some inconsistencies in 5.5.1 but that is how most products seem to interpret it.

It has to be recognised that despite its claim, some intricate aspects of 5.5 in my opinion are not fully implemented by FH.
But those, and some intricacies of 5.5.1 are not fully implemented by most products.
The changes outlined above do have a major impact on portability and are either quite trivial changes or largely implemented in FH already.