An Example GedML Dataset

In the box below is a very simple dataset representing a fictitious family with two parents and one child. There are six GEDCOM records (Level number 0): a header (HEAD), three individuals (INDI), one family (FAM), and a trailer (TRLR).

The left-hand column gives the GEDCOM 5.5 encoding; the right-hand column gives the equivalent in GedML.

GEDCOM 5.5 GedML

0 HEAD
1 SOUR FTW
1 DEST PAF
1 DATE 21 Oct 1997
1 CHAR ANSEL
1 FILE C:\MHK\FAMILY\TEST.GED

0 @I01@ INDI
1 NAME Michael Howard /KING/
1 SEX M
1 BIRT
2 DATE 11 May 1953
2 PLAC Hannover, Germany
1 FAMS @F1@

0 @I02@ INDI
1 NAME Penelope Mary /PHELAN/
1 SEX F
1 BIRT
2 DATE 24 Sep 1956
2 PLAC Cheltenham, Glos, England
1 FAMS @F1@

0 @I03@ INDI
1 NAME Philippa Heloise /KING/
1 SEX F
1 BIRT
2 DATE 13 Jul 1989
2 PLAC Reading, Berks, England
1 FAMC @F1@

0 @F1@ FAM
1 HUSB @I01@
1 WIFE @I02@
1 CHIL @I03@
1 MARR
2 DATE 10 Apr 1982
2 PLAC Cheltenham, Glos, England
0 TRLR 		<GED>
<HEAD>
<SOUR>FTW</SOUR>
<DEST>PAF</DEST>
<DATE>21 Oct 1997</DATE>
</HEAD>


<INDI ID="I01">
<NAME>Michael Howard <S>KING</S></NAME>
<SEX>M</SEX>
<EVEN EV='BIRT'>
<DATE>11 May 1953</DATE>
<PLAC>Hannover, Germany</PLAC> </EVEN>
<FAMS REF="F1"/>
</INDI>
<INDI ID="I02">
<NAME>Penelope Mary <S>PHELAN</S></NAME>
<SEX>F</SEX>
<EVEN EV='BIRT'>
<DATE>24 Sep 1956</DATE>
<PLAC>Cheltenham, Glos, England</PLAC> </EVEN>
<FAMS REF="F1"/>
</INDI>
<INDI ID="I03">
<NAME>Philippa Heloise <S>KING</S></NAME>
<SEX>F</SEX>
<EVEN EV='BIRT'>
<DATE>13 Jul 1989</DATE>
<PLAC>Reading, Berks, England</PLAC> </EVEN>
<FAMC REF="F1"/>
</INDI>
<FAM ID="F1">
<HUSB REF="I01"/>
<WIFE REF="I02"/>
<CHIL REF="I03"/>
<EVEN EV='MARR'>
<DATE>10 Apr 1982</DATE>
<PLAC>Cheltenham, Glos, England</PLAC>
</EVEN>
</FAM>
</GED>

Notes:

  1. The header record gives administrative information about the file. This example is produced using the commercial product Family Tree Maker for Windows version 3. It omits some fields which according to the GEDCOM specification are mandatory: this illustrates a general point that we cannot be to rigid in defining our DTD, or many existing products will be found to be invalid even though they interchange data quite happily. Note that the GEDCOM standard defines many more header fields than are used here, including level 2 and even level 3 fields. Some of the fields in the header are unnecessary in GedML: I have removed those (CHAR and FILE) which make no sense at all once the file is converted.
  2. The other records have an identifier (e.g. @I01@ for the first INDI (individual) record. This is translated into an ID="I01" attribute in the GedML. The DTD defines this as an attribute of type ID, ensuring uniqueness.
  3. Cross-references, e.g. the FAMS field, have a value which is a record identifier (e.g. @F01@). This translates in GedML into a REF attribute. The DTD defines this as an attribute of type IDREF, ensuring referential integrity.
Michael H. Kay
16 February 1999