Modern Software Experience

2023-02-15

Compatibility details

Intersex in GEDCOM

The need for GEDCOM to support X for Intersex was noted through an annotation in the GEDCOM 5.5.1 Annotated Edition (2018):

An additional sex value has come to be used since this specification [GEDCOM 5.5.1] was created. Genealogy applications must allow users to enter, and their GEDCOM readers must accept one additional sex value; X for intersex.

GEDCOM 5.5.5 (2019) added support for Intersex

INDIVIDUAL_RECORD:=
n @@XREF:INDI@@ INDI {1:1}
...
+1 SEX <SEX_VALUE> {0:1}
...

SEX_VALUE:= {Size=1:7}
A code that indicates the sex of the individual:
M =    Male
F =    Female
X =    Intersex
U =    Unknown / Unfound
N =    None / Not recorded

compatibility

GEDCOM 5.5.5 is the most backward-compatible GEDCOM version ever. GEDCOM 5.5.5 is even more compatible with GEDCOM 5.5.1 applications than GEDCOM 5.5.1 itself; a GEDCOM 5.5.5 data transfers will always transfers LDS baptisms, whereas a GEDCOM 5.5.1 data transfer is likely to lose them..
Such compatibility is wonderful, but there is a shadow side. The most obvious of the extreme compatibility is that it does not allow introduction of new records, and thus seriously limits the possibility to introduce new features. Hence the description of GEDCOM 5.5.5 as a simplified, cleaned up and streamlined GEDCOM 5.5.1.
A less obvious issue of the high compatibility is that there is no pressing need for vendors to add explicit GEDCOM 5.5.5 support. All leading genealogy applications support (or try to support) GEDCOM 5.5.1 Annotated Edition (AE), and those application import GEDCOM 5.5.5 files just fine

GEDCOM 5.5.5 is mostly a better GEDCOM 5.5.1, but did introduce some minor new features. Do not misunderstand that observation. The introduction of X for Intersex is significant, but technically speaking a very small change; merely one new legal value for an already existing record.

0 @1@ INDI
1 NAME John /Doe/
2 GIVN John
2 SURN Doe
1 SEX M
0 @2@ INDI
1 NAME Jane /Doe/
2 GIVN Jane
2 SURN Doe
1 SEX F
0 @3@ INDI
1 NAME Jan /Doe/
2 GIVN Jan
2 SURN Doe
1 SEX X

Intersex in GEDCOM 5.5.1

0 @1@ INDI
1 NAME John /Doe/
2 GIVN John
2 SURN Doe
1 SEX M
0 @2@ INDI
1 NAME Jane /Doe/
2 GIVN Jane
2 SURN Doe
1 SEX F
0 @3@ INDI
1 NAME Jan /Doe/
2 GIVN Jab
2 SURN Doe
1 _SEX X

Intersex in GEDCOM 5.5.5

5.5.1 import of X

You have to expect some information loss when importing a new data format into an older application, even if that new data format was designed with those older applications in mind - and that's the case 3ere.
The INDI.SEX record X value, introduced in GEDCOM 5.5.5, is likely to be lost when imported into into a GEDCOM 5.5.1 application. More precisely, when it is not recognised, it will be either explicitly rejected or silently ignored (the GEDCOM 5.5.1 specification allow both), and the application will use the default INDI.SEX value, U for Unknown. Thus, information is lost as X is downgraded to U, and that is the best we can expect from an application that does not support Intersex yet.

Perhaps a few applications will import X into an INDI.SEX record because they simply fail to check the record value they import at all. While such accidental acceptance of the unsupported value may seem fortuitous in this case, applications not checking their input is highly problematic in general.

The Intersex support added in GEDCOM 5.5.5 is necessary but not sufficient for the transfer of that data. The GEDCOM support merely enables transfer of the data, by providing a simple application-independent format. For the data transfer to be truly successful, the receiving application has to support it.

Intersex support

Adding support for intersex is fairly trivial; just allow the additional value, and add some sentences for reports and such. The GEDCOM export code should not need any work at all, and the GEDCOM import code merely needs to allow the value. Adding support for a new feature could hardly be simpler.

It really is that simple, thanks to GEDCOM's support for Intersex, but it's not the entire story. applications supporting GEDCOM 5.5.5 do not need to keep supporting GEDCOM 5.5.1 Annotated Edition but developers will choose to provide their users with a choice: GEDCOM 5.5.5 (default) or GEDCOM 5.5.1. The choice to keep providing GEDCOM 5.5.1 AE creates a new issue; what do with intersex when exporting to GEDCOM version 5.5.1?

GEDCOM 5.5.1 export

There are three basic approaches to dealing with features not supported by an older GEDCOM version:

Obviously, the best option is not using the older version, but let's consider these three approaches. Omitting or downgrading the data (in this case from X to U) results in loss of information.

Including the X value anyway requires no coding effort at all. Whether it works depends on how the importing application deals with it. It is technically a violation of the GEDCOM 5.5.1 specification, but surely that annotation quoted at the beginning of this article implies that you should do so anyway?

Using extensions enables exporting the data without violating the GEDCOM 5.5.1 specification, but again, whether it works depends on how the importing application deals with it.

The GEDCOM 5.5.1 tag for supporting X is _SEX. The GEDCOM 5.5.1 already demands that extensions start with an underscore. The GEDCOM 5.5.5 standard has a few more rules for extensions, that improve compatibility of different GEDCOM versions and dialects (GEDCOM files created by different applications).G GEDCOM version 5.5.5 demands the use of standard tags whenever possible; it is illegal to use extensions for anything that can be coded with standard tags. The GEDCOM 5.5.5 standard also reserves standard tags prefixed with an underscore for support of new features in older standards. So applications can use GEDCOM 5.5.5 features in GEDCOM 5.5.1 files, by prefixing the tag with an underscore. That isn't a new idea, various applications use _EMAIL in GEDCOM 5.5 for the the EMAIL record first defined in GEDCOM 5.5.1. What's new is that this approach is explicitly supported and encouraged by the specification. This makes it easy for developers to support new features, even through old GEDCOM versions.

Best practice

Best practice for GEDCOM 5.5.1 applications to stop relying on GEDCOM 5.5.5's compatibility with with GEDCOM 5.5.1 applications, and upgrade their GEDCOM support to GEDCOM 5.5.5.
GEDCOM 5.5.5's explicit support for new features in older GEDCOM versions makes it possible to do this on a feature by feature basis.

GEDCOM reader

GEDCOM writer

GEDCOM validator

links

 

Copyright © Tamura Jones. All Rights reserved.