XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (723 page)

Creating Family Records

The

elements in the result document correspond one-to-one with the

elements in the input, except that the event information is not included (it is output separately in

elements, later). For example, the input element:

is translated to the output element

Here is the code to do this:

One point worth noting here is the use of
select=“HUSB,
WIFE,
CHIL”
to ensure that the elements of the family appear in the right order in the output. The GEDCOM 6.0 schema is very strict about the order of elements, whereas GEDCOM 5.5 was more liberal. This expression selects a sequence containing zero-or-one
HUSB
elements, zero-or-one
WIFE
elements, and zero-or-more
CHIL
elements, and processes them in that order.

If the input GEDCOM file is invalid, for example if a
FAM
contains more than one
WIFE
element, then the output file will also be invalid, and this will cause a validation error to be reported by the XSLT processor.

Creating Individual Records

The code for mapping

records in the source to

records in the result tree is similar in principle to the code for family records, though a little bit more complicated.

Note the code here for extracting the surname from the name using the

instruction. In GEDCOM 5.5 the surname is tagged by enclosing it between
/
characters; in 6.0, it is enclosed in a nested

element. The 6.0 specification also allows tagging of other parts of the name, for example as a given name, a title, a generation suffix (such as
Jr
) and so on, but as such fields aren't marked up in our source data, we can't generate them.

The rules for
NOTE
elements apply to such elements wherever they appear in a GEDCOM file, which is why the patterns specify
match=“NOTE”
rather than
match=“INDI/NOTE”
; for other elements, the rules may be specific to their use within an

record.