Family Historian User Group

This thread is intended to track implementation issues with GEDCOM 7 files imported/exported by FH.
The https://github.com/FamilySearch/GEDCOM/releases webpage Assets list the latest gedcom.html and gedcom.pdf files.
On 10th Mar 2023, they were at version 7.0.12.
Specification names and PDF page references are provided in support of the tags described below.

1. FAMily record custom attributes using the _ATTR tag are NOT exported as FACT tags as specified in GEDCOM 7.
   ( INDIvidual record custom attributes do correctly use FACT tags. )
   Interestingly, FAMily FACT tags are correctly imported as custom attributes.
   See GEDCOM 7, FAMILY_ATTRIBUTE_STRUCTURE specification on PDF Page 48.
   *
2. Fact Witness _SHAR tags are NOT exported as ASSO tags.
   Also, ASSO tags are NOT imported as Fact Witness Associations, but become UDF.
   The ROLE and PHRASE subtags need translating from/to the FH ROLE subtag values.
   e.g. 7.0 ROLE = OTHER and PHRASE = FH ROLE text.
   See GEDCOM 7, ASSOCIATION_STRUCTURE and enumset-ROLE specifications on PDF Pages 46 & 98.
   *
3. Media frame _AREA tags are NOT converted to CROP tags with TOP, LEFT, HEIGHT, WIDTH subtags.
   Valid CROP tags are NOT imported as _AREA tags, but become UDF.
   See GEDCOM 7, MULTIMEDIA_LINK and CROP (Crop) specifications on PDF Pages 56 & 71.
   *
4. UniqueID _UID tags are NOT exported as UID tags.
   Also, UID tags are NOT imported as _UID tags, but become UDF.
   See GEDCOM 7, UID (Unique Identifier) specification on PDF Page 95.

GEDCOM is currently at 7.0.12, just an FYI!

Thanks, I've found 7.0.10 at https://gedcom.io/specifications/Family ... DCOMv7.pdf
Where can I find 7.0.12 please?

I've updated the Page references in the OP.

The HTML page is at .12 while the PDF is at .10

What exactly are the implications of that? Are they still essentially the same specification, or not?
Could this lead to confusion about which specification a product supports?

The .12 version has been verified and registered in GitHub.

I’ve ask for clarification, but I think .12 should used!

It all becomes a bit circular.
Start at the GitHub Repository and follow the README link to https://github.com/FamilySearch/GEDCOM/ ... /README.md which says "If you are looking for the specification itself, see https://gedcom.io." There if you click Read the specs you are taken to the list of FamilySearch GEDCOM Version 7 specifications where PDF v7.0.10 and HTML v7.0.12 are listed along with a link back to the GitHub Repository where we started!

This is one of the problems of constant patch releases using semantic versioning (major.minor.patch). At best I think it is only feasible to expect large genealogical sites and software providers to keep up with minor releases (7.1, 7.2 for example). Given that these companies haven't had to keep up with any GEDCOM releases for many years, they are probably not geared up to start doing so now.

I don't know what version FH7 has implemented - would it be worth asking? And maybe ask if they have any plans on how often they intend to update it (I know they probably won't answer the latter part).

Minor and Patch releases should all be backwards compatible according to Semantic Versioning 2.0.0 (which is what the GEDCOM specification states it will use), so my suggestion is we should just pick a baseline and stick with that. Might as well go with 7.0.12, but it rather depends on what version CP have gone with.

Pick up the latest release here...
https://github.com/FamilySearch/GEDCOM/releases

Both the .HTML and .PDF files are in the Assets list for the latest version.

Thank you Jim. That is consistent and shows the https://gedcom.io/specs/ page is out of date.
I'll update the OP with that new link.

Are you guys all happy that I then delete these other postings that will be redundant?

It's largely academic unless the source and target apps use precisely the same version, but note that the link Jim posted notes Simon Orde (the creator and godfather of FH) as a contributor and recipient.

I think that directs us to review against the latest release, as CP will be fully aware of it, and they will make up their own minds about prioritising the various issues.

7.0.12 was only issued 2 weeks ago, so CP may have worked from 7.0.11 issued on Nov 1, 2022 but the differences are minor and don't affect the tag issues listed in the OP.

I agree that the changes are minor between .10 and .12, but my goal was to note that v7 has evolved from the initial release to include multiple enum changes, some definitions of what goes in a tag and other documentary changes.

Also note that we are working on v7.1 changes as well and looking to future releases for v8.0 both with no release dates as of today!

Can the evolution of GEDCOM specifications and related discussions be moved to the GEDCOM 7.0 (18957) thread so that this posting focuses on just FH import/export GEDCOM 7 issues?

My point was a general one, rather than directed at today's latest flavour. This thread will be kept up to date with the latest version of GEDCOM 7, and we only raise issues against that. CP will be aware of the updates, and they will make up their own minds about if/when to make corrections.

Is it worth a separate ticket to highlight that FH only reports "GEDCOM 7" as the destination? It would be more meaningful to keep that updated to reflect the latest version they have reviewed against.

Just out of interest I did a GEDCOM 7 export, and in the resultant file it states
So I guess we only have to worry about problems against that specification, rather than the latest flavour, as Mark puts it. It might be a little clearer if the export drop-down stated 7.0 or 7.0.0 instead of 7, but I'm not sure it's worth raising a ticket for unless you feel strongly about it.

But which specification is GEDCOM VERS 7.0?
It could be anything from 7.0.0 to 7.0.12.

To clarify the release info in a GEDCOM.

Only 2 VERS 7.0 is required but VERS 7.0.1 is permitted.

The structure of GEDCOM v7 will not change for patches 7.0.1 thru 7.0.xx, any changes produced in a patch will be more resigned to clarifications of definitions for a tag, adding enumerated values to a tag, clarify recommended uses for tags.

Excellent - if there is only one GEDCOM 7.0, that simplifies things enormously. All we are doing is making sure we are using the latest description of it.

KFN wrote: ↑

10 Mar 2023 21:23

The structure of GEDCOM v7 will not change for patches 7.0.1 thru 7.0.xx, any changes produced in a patch will be more resigned to clarifications of definitions for a tag, adding enumerated values to a tag, clarify recommended uses for tags.

Does a change in the cardinality of a tag from {0:1} to {0:M} or from {0:1} to {1:1} constitute a change in structure?

tatewise wrote: ↑

11 Mar 2023 11:46

Does a change in the cardinality of a tag from {0:1} to {0:M} or from {0:1} to {1:1} constitute a change in structure?

If this was a “Normalized” database structure I would say that cardinality should not change in a patch.

I don’t recall all of the cases that cardinality change, but the one I do recall was early on and they believed that the specification had not yet been implemented and they ultimately reverted back to the v5.5.1 specification of cardinality for the tags.

https://github.com/FamilySearch/GEDCOM/ ... ag/v7.0.11 says:
Since 7.0.0, g7:NOTE-TRAN was listed with {0:1} in g7:NOTE but {0:M} in g7:record-SNOTE and defined in a way that assumed {0:M}. It has now been updated to {0:M} in g7:NOTE-TRAN too.

https://github.com/FamilySearch/GEDCOM/ ... tag/v7.0.6 says:
Deprecate EXID without a TYPE. EXID is defined in terms of its TYPE, and an EXID without a TYPE is not meaningful. EXID.TYPE will have cardinality {1:1}, not {0:1}, in the next major release.

I’m not on the Steering Committee, only a commenter at large.

The NOTE change prevented inconsistency issue in the document and definitely a bug to be fixed.

The EXID without a TYPE was illogical and also a bug to be fixed.

What you you want me to say? Bugs need to be fixed where they can with minimal impact. Commenters have found others that were not implemented because they would impact to a greater degree.