* FH criticised in blog post - email to support?

[Valkrider]

In the ongoing saga of Gedcom 5.5 vs 5.5.1 there is a new blog post at http://genealogytools.com/why-all-genea ... com-5-5-1/ that criticises Family Historian, along with several other programmes, for mislabelling its Gedcom files.

The article suggests emailing Calico Pie to get the export changed. I know that there are many other important things we would like to see fixed in Family Historian. It seems like such a minor fix it may be worth raising it with Calico Pie so that at least it is no longer criticised for this.

[NickWalker]

Anyone can write a blog post, but it doesn't mean they're right.

[Valkrider]

@Nick that may be correct BUT every one of my exported Gedcoms is labelled 5.5 NOT 5.5.1. So in this case it is correct.

[NickWalker]

Yes but 5.5.1 was never released as an official standard and FH doesn't produce GEDCOM in 5.5.1 format so it would be wrong to label it like that.

[mjashby]

I believe the main basis of the underlying argument in the Blog Post is that Family Historian allows the use a number of Gedcom Tags that were not included in the Gedcom 5.5 specification and which were only defined in the 5.5.1 specification so, in that case, Calico Pie is be falsely claiming that the program creates/outputs a totally valid 5.5 Gedcom file unless those offending Tags are removed. Alternatively, those additional non-5.5 Tags should appear in the software as "User Defined" additions and it should be possible/obligatory to omit those Tags from from a Gedcom 5.5 export. From personal experience, I'm sure Trading Standards (in the UK) would see it the same way, if they understood and were interested!.

Personally, I cannot see why Calico Pie sticks with insisting on 5.5 compliance when the vast majority of genealogy applications which users have communicate with have openly adopted the later 5.5.1 specification either in full, or in part, to allow the inclusion of additional features that most users want/need/insist on having and are catered for in 5.5.1, despite the dire warnings that 'It is Only a Draft'. After all, it works and will never be anything else but a Draft as the 'author' is no longer interested; and the likelihood of any 'new' genealogical data transfer standard that all developers will wholeheartedly subscribe to is, at best, a remote possibility which is not likely to occur in any of our lifetimes.

Mervyn

[NickWalker]

I believe the main basis of the underlying argument in the Blog Post is that Family Historian allows the use a number of Gedcom Tags that were not included in the Gedcom 5.5 specification and which were only defined in the 5.5.1 specification so, in that case, Calico Pie is be falsely claiming that the program creates/outputs a totally valid 5.5 Gedcom file unless those offending Tags are removed. Alternatively, those additional non-5.5 Tags should appear in the software as "User Defined" additions and it should be possible/obligatory to omit those Tags from from a Gedcom 5.5 export. From personal experience, I'm sure Trading Standards (in the UK) would see it the same way, if they understood and were interested!.

As far as I'm aware that's what FH does - it uses User Defined additions and doesn't create 5.5.1 specific tags. Family Historian follows the specification for the final version of GEDCOM (5.5). The spec does discuss the use of Unicode and states that the CHAR tag should be used to specify the character set, which is what Family Historian does. I think that what Family Historian does is very much in the spirit of what the specification discusses, e.g. it says "UNICODE character set should be used for multi-language support as soon as operating systems begin providing adequate storage and display support.".

[tatewise]

I have Emailed Support on this subject, who say they are considering it:

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?

I am growing more and more concerned that FH will lose its market position if it does not at least support import and export of GEDCOM 5.5.1 Draft format that is so widely supported in the rest of the industry.

Although that draft says it must not be used, it was used by the draft authors LDS themselves in their own PAF product. See the references in the quotes above.

FH does almost completely stick to GEDCOM 5.5, but it does use CHAR UTF-8 encoding and the Media record FILE tag in certain cases, although they are both only defined in GEDCOM 5.5.1 Draft. FH also has recently been modified to import some GEDCOM 5.5.1 Draft structures from such as TMG and FTM.

[NickWalker]

It seems reasonable for FH to allow an option to export in 5.5.1 but I think 5.5 standard together with the various extensions that Calico have added over the years work well as the default.

[tatewise]

Yes, if I understand it correctly, only a few tag adjustments are needed to be 5.5.1 export compliant:

• Adjust _ATTR to use FACT
• Adjust _EMAIL and _WEB to use EMAIL and WWW
• Adjust _FILE and FORM & TITL to use FILE with subsidiary FORM & TITL
• Move _PLAC record MAP, LATI & LONG to use PLAC field MAP structure.

Similar adjustments for importing 5.5.1 would be straightforward, and already mostly exist.

That would go a long way to improving reviews and offering compatibility with other products.

There are some useful additions that FH could use, such as status of a child link FAMC.STAT and FAX numbers.

[NickWalker]

What's a Fax Grandad?

[tatewise]

I have no idea but their numbers are printed on loads of documents I receive

P.S.
Joking apart, I believe they have a legal status that Email does not:
http://smallbusiness.chron.com/fax-vs-e ... 47850.html
http://www.faxination.com/wiki/10-reaso ... -important
and lots more with a search for legal status of fax vs email

[NickWalker]

Yes, if I understand it correctly, only a few tag adjustments are needed to be 5.5.1 export compliant:

• Adjust _ATTR to use FACT
• Adjust _EMAIL and _WEB to use EMAIL and WWW
• Adjust _FILE and FORM & TITL to use FILE with subsidiary FORM & TITL
• Move _PLAC record MAP, LATI & LONG to use PLAC field MAP structure.

Similar adjustments for importing 5.5.1 would be straightforward, and already mostly exist.

That would go a long way to improving reviews and offering compatibility with other products.

There are some useful additions that FH could use, such as status of a child link FAMC.STAT and FAX numbers.

Presumably the FILE would need to change the relative paths used in projects into full paths?

[AdrianBruce]

Yes, if I understand it correctly, only a few tag adjustments are needed to be 5.5.1 export compliant:
...

Um. How does this fit with http://www.fhug.org.uk/forum/viewtopic. ... lit=+draft where it was stated that the EVEN tag (for instance) in the 5.5.1 spec'n does not allow a "value" on the EVEN line in the definition but does have an example with exactly that? And the 5.5.1 individual event structure doesn't have the EVENT_DESCRIPTOR, but the family event structure does. Which is potentially worse because this is the specified format, not an example. I am concerned that these inconsistencies might result in more than just a few tag adjustments. Maybe not but which 5.5.1 format do software companies actually follow for the EVEN and its value? The specification or the description? Certainly, when this came up earlier in the year, some of the bloggers were adamant that the example was correct and the specification wrong.

Just for clarity, is it being suggested that FH allows import and export of 5.5.1 GEDCOM but stores it in its current 5.5 format? That would seem sensible and minimises the change required. There is an assumption that it is possible to map in both directions between the current 5.5 format and 5.5.1, of course, that would need to be worked through.

Presumably importing 5.5.1 individual event structure with an EVENT_DESCRIPTOR could be done by changing them to attributes. But exporting them again surely has to result in export as an Attribute, i.e. there'd be a round trip difference???

[AdrianBruce]

... Presumably the FILE would need to change the relative paths used in projects into full paths?

Which is a bit weird because the relative paths are usually(?) meaningful after moving to the new machine, but full paths are not unless the target and recipient machines are set up the same way, right up to the disk drives.

Crikey... If my FILE paths in the FH data (rather than any import or export) were absolute, I'd have difficulty storing my FH file in OneDrive as OneDrive is on C: on my laptop and D: on my desktop. So full 5.5.1 compatibility could never be on the file I use, only on imports and exports. Or am I missing something?

[NickWalker]

The Export dialog already has options to expand file paths to full so I think adding some further options to allow export in 5.5.1 format would work. But the FH solution of being able to use relative paths is so much better.

[jimlad68]

1. One of the things I learnt early on in IT was 'go with the most popular standard even if it is not the best' failing that, a standard that you could easily migrate to/from. If that is Gedcom 5.5.1 and there are no major downsides, lets go with it.

However:

2. I suspect many of the Plugins and even queries would need amending, but that can be said of even a FH update.

3. Would it mean less development on other more useful features.

4. Does the current 'Export Gedcom File' not effectively import/ export 5.5.1. In which case all those reviewers need vehemently correcting. (This is yet another example where the inclusion of Plugins in the trial version of FH would be of great benefit. Why does Calico Pie resist putting its product forward without one of its main selling points. In this case, from my correspondence, I don't think the above reviewer had the full version; begs the question how can you do a proper review!).

5. There was a period when Gedcom was out of the limelight and developers (e.g. TMG) were pushing direct imports like GENBRIDGE, but when you consider all the permutations of products and versions, Gedcom is still often easier. I think the recent near demise of TMG and FTM, together with the excellent developments of FH and Rootsmagic have got developers looking at direct imports but users and reviewers back to looking at Gedcom.

[tatewise]

Let's clarify a few issues.

So far, only importing / exporting 5.5.1 is proposed, with 5.5 used internally. This is similar to most other products that import / export 5.5.1 and use a significantly different database structure internally. Importing / exporting 5.5 would also be retained to maintain full round trip compatibility with FH.

Importing Events (EVEN) and Facts (FACT) would produce Events and Attributes. Events with a value would be handled as now and put the value in a Note or _UNCAT field. So Export would still produce Events and Facts. Nobody said round-trip would be perfect, and currently it is certainly NOT perfect except for FH itself.

Media FILE would support the same options as _FILE does now with either relative or absolute paths. That is already the case for the current FH versions including FILE tag. See how_to:exporting_gedcom_with_multimedia|> Exporting a Family Tree with Multimedia.

Jim:-
1. My thinking exactly.
2. No changes needed as FH still 5.5 internally.
3. Possibly but I believe the changes are quite small and it might win over reviewers and gain users.
4. Export Gedcom File Plugin does NOT import anything, but could make better use of 5.5.1 in exports.

[AdrianBruce]

OK Mike - I'll buy that now you've clarified what I hoped you meant.

"Events with a value would be handled as now and put the value in a Note or _UNCAT field" - right - sounds better like that. Works on Individuals because the 5.5.1 draft doesn't actually allow values with Individual's Events. Despite what the bloggers think is obvious!

Not certain about Families because the generic / user-defined EVEN for families introduced in 5.5.1 does have a EVENT_DESCRIPTOR - presumably because there isn't an Attribute Structure for Families at the moment in 5.5.