Genealogical Record Exchange and Description Language
(GREnDL 1.1)

Proposal 10 January 2004

This version:
http://www.rumblefische.com/util/grendl/grendl.html
with a DTD
with a XML Schema
Latest version:
http://www.rumblefische.com/util/grendl/grendl.html
Changes:
6 October 2004
  • Changed encodings to ISO-8859-1 from UTF-8.
    1 October 2004
  • Updated the section "Appendix B: Converting the Data" (removed version from version of Adam.exe)
    19 September 2004
  • Updated links
    10 February 2004
  • Added a new section "Appendix B: Converting the Data"
  • Added [/CCYY] to date.
  • Removed 'spouse' from claim types. The 'marriage' claim type is now used to claim spouses.
  • Modified the validation header.
  • Added links to Adam.zip, Validator.zip and Saxon.zip.
  • Fixed test1.html.
  • Modified calendar to be of type string.
    • Downloads:
    http://www.rumblefische.com/util/grendl/grendl.zip (519kB)
    includes all downloads mentioned in this document
    Author:
    Tim Forsythe (tjforsythe at gmail dot com)

    • Copyright © 2003-2004 Tim Forsythe. All rights reserved.
    This document may be freely copied and distributed without modification.

    Abstract

    The Genealogical Record Exchange and Description Language (GREnDL 1.1) describes a data model used to represent genealogical information, and specifies the element structures, attributes and data types of the description language used to exchange that information between various representing applications. GREnDL is itself represented in XML as defined by [XML 1.0 (Second Edition)].

    Status of this document

    GREnDL 1.1 is not a recognized standard, and hence should only be used by those who are aware of this instability and flexible enough to manage that.

    Please report errors in this document to the author.

    The English version of this specification is the only available version.

    GREnDL is based on previous work by the author, and supercedes the Genealogy Data Format 1.1.2 (Tim Forsythe, 2002-2003) and the Universal Data Model 1.0 (Tim Forsythe, 2000-2001).

    Table of contents

    1 Introduction
    1.1 Purpose
    1.2 What GREnDL is Not!
    2 Genealogical Data Model
    2.1 Overview
    3 Document Details
    3.1 Introduction
    3.1.1 XML Conventions
    3.1.2 Data Types
    3.1.2.1 unsignedInt
    3.1.2.2 positiveInteger
    3.1.2.3 ID
    3.1.2.4 IDREF
    3.1.2.5 string
    3.1.2.6 language
    3.1.2.7 anyURI
    3.1.2.8 dateTime
    3.1.2.9 date
    3.1.2.10 crc
    3.1.2.11 html
    3.1.3 Syntax Example
    3.1.4 Data Security
    3.1.5 Data Integrity
    3.1.6 Documenting Relationships
    3.1.7 Documenting Attributes
    3.1.8 Documenting Events
    3.1.9 Validation
    3.2 File Structure
    3.2.1 head
    3.2.1.1 file
    3.2.1.1.1 version
    3.2.1.1.2 copyright
    3.2.1.2 exporter
    3.2.1.3 submitter
    3.2.2 body
    3.2.2.1 person
    3.2.2.1.1 mergeref
    3.2.2.1.2 name
    3.2.2.1.2.1 honorific
    3.2.2.1.2.2 nickname
    3.2.2.1.2.3 given
    3.2.2.1.2.4 taken
    3.2.2.1.2.5 called
    3.2.2.1.2.6 middle
    3.2.2.1.2.7 religious
    3.2.2.1.2.8 prefix
    3.2.2.1.2.9 surname
    3.2.2.1.2.10 ordinal
    3.2.2.1.2.11 suffix
    3.2.2.1.2.12 agnomen
    3.2.2.1.2.13 designation
    3.2.2.1.3 claim
    3.2.2.1.3.1 claimtype
    3.2.2.1.3.2 data
    3.2.2.1.3.4 personref
    3.2.2.1.3.4 when
    3.2.2.1.3.4.1 about
    3.2.2.1.3.4.2 before
    3.2.2.1.3.4.3 after
    3.2.2.1.3.4.4 from
    3.2.2.1.3.4.4.1 to
    3.2.2.1.3.4.5 between
    3.2.2.1.3.4.5.1 and
    3.2.2.1.3.4.6 date
    3.2.2.1.3.4.7 time
    3.2.2.1.3.4.8 era
    3.2.2.1.3.4.9 calendar
    3.2.2.1.3.4.10 jdn
    3.2.2.1.3.4.11 age
    3.2.2.1.3.4 location
    3.2.2.1.3.4.1 address
    3.2.2.1.3.4.1.1 street
    3.2.2.1.3.4.1.2 city
    3.2.2.1.3.4.1.3 county
    3.2.2.1.3.4.1.4 state
    3.2.2.1.3.4.1.5 country
    3.2.2.1.3.4.1.6 continent
    3.2.2.1.3.4.1.7 postalcode
    3.2.2.1.3.4.2 latitude
    3.2.2.1.3.4.3 longitude
    3.2.2.1.3.4.4 elevation
    3.2.2.1.3.5 citationref
    3.2.2.1.4 link
    3.2.2.1.4.1 uri
    3.2.2.1.4.2 caption
    3.2.2.1.5 research
    3.2.2.1.5.1 objective
    3.2.2.1.5.2 resolution
    3.2.2.1.6 note
    3.2.2.1.6.1 htmlblock
    3.2.2.1.7 modified
    3.2.2.2 source
    3.2.2.2.1 title
    3.2.2.2.2 abbr
    3.2.2.2.3 author
    3.2.2.2.4 publisher
    3.2.2.2.4.1 isbn
    3.2.2.2.4.2 issn
    3.2.2.2.5 volume
    3.2.2.2.6 issue
    3.2.2.2.7 number
    3.2.2.2.8 citation
    3.2.2.2.8.1 part
    3.2.2.2.8.2 section
    3.2.2.2.8.3 chapter
    3.2.2.2.8.4 page
    3.2.2.2.8.5 paragraph
    3.2.2.2.8.6 text
    3.2.2.2.9 contactref
    3.2.2.2.9.1 code
    3.2.2.3 contact
    3.2.2.3.1 description
    3.2.2.3.2 phone
    3.2.2.3.3 email
    3.2.3 crc
    4 Appendix A: Representing the Data
    5 Appendix B: Converting the Data
    6 References
    7 Index

    1 Introduction

    1.1 Purpose

    The Genealogical Record Exchange and Description Language (GREnDL) was developed to address deficiencies in the GEDCOM 5.5 standard for representing genealogical information and exchanging that information between databases or representing applications. The GEDCOM standard was developed by the Church of Latter Day Saints (LDS). Version 5.5 was released in 1996. GEDCOM 5.5. is currently the most widely used format by genealogical programs for use in the exchange of genealogical data. GREnDL is provided here as an alternative. It was designed to be more flexible in storing event and attribute driven data, and provides better traceability of evidence.

    1.2 What GREnDL is Not!

    GREnDL does not provide a model or format for the representation of data. It is similar to GEDCOM 5.5. in this respect. See Representing the Data for a discussion on how this might be accomplished. Examples are included.

    GEDCOM 5.5, being developed by LDS, includes specific tags for documenting LDS events. GREnDL does not provide embedded LDS specific information; however it does provide the ability for any application to define an unbounded number of claimtypes, of which LDS specific tags, may be mapped.

    2 Genealogical Data Model

    2.1 Overview

    Genealogical record keeping requires that we make claims about persons (name, birth date, etc.) that we discover through the use of sources and their citations. In order to provide tracibility of these sources, we must be able to document where they reside. We must also be able to measure or gauge the likelihood that the information documented is accurate. GREnDL provides the researcher with all of these capabilities through the use of linked data records. A data record is a group of related information thay may be uniquely identified and may be linked to multiple related records. The nature of genealogical research, which is often times incomplete, must allow for the creation of unlinked records. This model provides 4 record types: Person, Source, Citation, and Contact.

    The person record includes the persons name, gender, and a list of claims. The claims are used to document events and attributes associated with a person. Each claim can record the type and quality of the claim, any data or individuals associated with the claim, the date and location of the claim. This model includes several pre-defined claim types, but any number of user defined claim types may be added. The claim also provides a reference to citations that support the claim. This will provide sufficient traceability for all claims while being flexible enough to be used by those who do not place traceability among their priorities. The genealogical relationships between persons are made entirely through claims - see Documenting Relationships for examples.

    The source record includes the type and quality of the source, and the title, volume, author and publisher information. Citation records are embedded within the source records and include the type and quality of the citation, and the actual text, or summary of the text, and page information. The source record also includes a reference to any contacts or repositories where the source can be located.

    The contact record includes the name, address, phone, and email of the contact or repository.

    All records allow change dates, notes, links, and research tasks to be added.

    [Other changes have been proposed that have not yet been implmented in this version. These include the ability to add new user defined record types that could then be used for virtually anything. One example would be the ability to add a chart record type that could then be linked to multiple individuals. Another suggestion is to add a thumbnail uri to the link element. Also an image element should be added which would be available for all record types. Image elements would include a type attribute, and based on its value, either a link element, or an embbedded image element. The embedded image element would include and embedded image, thumbnail and caption.]

    3 Document Details

    3.1 Introduction

    Each XML document contains one or more elements, the boundaries of which are either delimited by start-tags (i.e. <element>) and end-tags (i.e. </element>), or, for empty elements, by an empty-element tag (i.e. <element/>). Each element has a name, and may have a set of attribute specifications. Each attribute specification has a name and a value. (i.e. <element attribute="value">). Any text that occurs between start-tags and end-tags are called the elements' content. If an element appears in the content of another element, is referred to as a child-element. T he enclosing element is then referred to as a parent-element. There is only one element that does not appear in the content of any other element. This element is called the root element.

    The ampersand character (&) and the left angle bracket (<) may not appear in the content of an element. To include either of these characters, they must first be escaped using the entities "&amp;" and "&lt;" respectively. The right angle bracket (>) may be not appear in the content, when it follows the string "]]>", where it must first be escaped using the entity "&gt;". [XML 1.0 (Second Edition)] defines five such entities that may be used in the content of any element:

    3.1.1 XML Conventions

    The following XML conventions are used throughout this document to define the constructs.

    DelimitersDescription
    Parentheses (()) a group of attributes or elements
    Comma (,) all of the attributes values or elements in a group are permitted and must occur in the order specified
    Pipe (|) only one of the attributes values or elements in a group is permitted
    No Symbol the attribute, element, or group must exist
    Question Mark (?)the attribute, element, or group may exist 0 or 1 time only
    Astrisk (*) the attribute, element, or group may exist any number of times
    Plus Sign (+) the attribute, element, or group must exist 1 or more times
    Equal (=) assigns an attribute value to an attribute
    Colon (:) when an optional attribute is omitted, the default attribute value specified is assigned to the attribute

    3.1.2 Data Types

    GREnDL uses the following datatypes to define elements and attribute values.

    3.1.2.1 unsignedInt

    The unsignedInt datatype represents numbers in XML, and is the set of finite-length sequences of decimal digits (#x30-#x39) in the range of 0 and 4294967295 inclusive. No leading zeros are permitted.

    3.1.2.2 positiveInteger

    The positiveInteger datatype represents numbers in XML, and is the set of finite-length sequences of decimal digits (#x30-#x39) in the range of 1 and 4294967295 inclusive. No leading zeros are permitted.

    3.1.2.3 ID

    The ID datatype represents the unique identifier of the element and must not appear more than once in an XML document. Values of type ID must match the Name production as defined in [XML 1.0 (Second Edition)] (i.e. the ID may start with a letter, underscore or colon, and may then be followed by any number of characters).

    3.1.2.4 IDREF

    The IDREF datatype represents the unique identifier of a different element. Values of type IDREF must match the Name production and must match the value of an ID attribute on some element in the XML document; i.e. IDREF values must match the value of some ID attribute.

    3.1.2.5 string

    The string datatype represents character strings in XML, and is the set of finite-length sequences of characters (as defined in [XML 1.0 (Second Edition)]) that match the Char production from [XML 1.0 (Second Edition)].

    3.1.2.6 language

    The language datatype represents natural language identifiers as defined by [RFC 1766]. language is the set of all strings that are valid language identifiers as defined in the language identification section of [XML 1.0 (Second Edition)].

    3.1.2.7 anyURI

    The anyURI datatype represents a Uniform Resource Identifier Reference (URI). An anyURI value can be absolute or relative, and may have an optional fragment identifier (i.e., it may be a URI Reference). This type should be used to specify the intention that the value fulfills the role of a URI as defined by [RFC 2396], as amended by [RFC 2732].

    3.1.2.8 time

    The time datatype represents a specific instant of time in the proleptic Gregorian Calendar, and is represented using the following format: hh:mm:ss. The component "hh" represents the hour in the range of 0 and 24 inclusive. "mm" represents the minute in the range of 0 and 60 inclusive. "ss"represents the second in the range of 0 and 60 inclusive. No components are optional. Leading zeros are required when component values would otherwise have fewer digits than those shown in the representation.

    For example, to indicate 1:20 pm, one would write: 13:20:00.

    3.1.2.9 date

    The date datatype represents a calendar date and is represented using the following format: [-]CCYY[/CCYY]-MM-DD. The "CC" component represents the century, "YY" the year, "MM" the month and "DD" the day, preceded by an optional leading "-" sign to indicate a negative year. If the sign is omitted, "+" is assumed. An optional duplicate century and year may be included as applicable. Leading zeros are required when component values would otherwise have fewer digits than those shown in the representation. date may be reduced by omitting components from the right-side of the representation (right-truncated). For instance, -DD or -MM-DD may be omitted. No left truncation is allowed. date is not restricted to any particular calendar, therefore, the range values for each component are bounded only by the calendar type being used.

    3.1.2.10 crc

    The crc datatype represents CRC-32 the International Standard 32-Bit CRC and is of the type unsignedInt.

    3.1.2.11 html

    The html datatype represents formatted text strings and supports the Text, List and Table features as defined by [HTML 4.01].

    3.1.3 Syntax Example

    The following example uses the listed XML conventions for describing the document syntax. In this example there is a parent-element (element) which has two attributes, the first of which (attribute1) must exist one time only. The second attribute (attribute2) may optionally exist, but only one time. It may also have one of two possible values (attribute-value2a or attribute-value2b). If attibute2 is omitted, the value is assumed to be attribute-value2a.

    The content of the parent-element includes a list of child-elements that may optionally exist one time only. If child-elements are specified, element1 is required and must occur before any other elements. element2a or element2b may exist, but only one time, and must occur before element3 or element 4. element3 may exist an unbounded number of times, or may not exist at all and must occur before element4. element4 must also exist at least one time, but may exist an unbounded number of times, and must occur last. 

    <element
  attribute1 = "attribute-value1"
  attribute2 = ("attribute-value2a" | "attribute-value2b")? : "attribute-value2a">
  Content: (element1, (element2a | element2b)?, element3*, element4+)?
</element>

    3.1.4 Data Security

    The body element and all of the record elements provide a security attribute which can be set to "public", "private", or "local". Private is defined as data that is either sensitive or copyrighted, and should not be made available to public databases or viewers without consent. For instance, if a user creates a website which is available to the public, it should not display the private data such as information about living persons. Local data is similar to private data, but provides an intermediate level of security so that data may be made available to a local group, but not to the public. Public data is of course without any security, and may be made available to all viewers.

    The security attribute of the body element will supercede those of all the record elements whose attribute is set to a lower security level, where "private" is the highest level, and "public" is the lowest. This allows the security level of the entire body's contents to be increased simply setting the body security attribute.

    Security attributes should be used by both importing and exporting applications to protect the content of the record elements. Importing applications should not import "private" elements' content when presenting that data to public or local viewers. Likewise, they should not import "private" or "local" elements' content when presenting that data to public viewers. Exporting applications should not export "private" elements' content when providing content to public or local viewers. Likewise, they should not export "private" or "local" element's content when providing content to public viewers.

    As an example, an exporting system should export a private element as follows: 

    <person id="ID1" security="private" existance="living" />
    Note that because there is no content, the element is represented by an empty-tag.

    3.1.5 Data Integrity

    GREnDL provides placement for a crc formatted as CRC-32, the International Standard 32-Bit CRC. The crc includes the entire contents of the grendl element.

    3.1.6 Documenting Relationships

    Relationships between persons, locations, and objects are defined through the use the of claim elements. The type attribute or the claimtype element are provided for defining the relationships.

    Defining a parent is done as follows: 

    <claim type="parent" quality="known">
  <personref refid="ID1" />
</claim>

    Defining a child is done as follows: 

    <claim type="child" quality="known">
  <personref refid="ID2" />
</claim>

    Defining a spouse is done as follows: 

    <claim type="marriage" quality="known">
  <personref refid="ID3" />
  <when><date>1900-01-01</date></when>
  <location>
   <city>Chicago</city>
   <state>Illinois</state>
  </location>
</claim>

    If it is desired to document non-genealogical relationships, such as adopted child, then a new claim type should be added as follows: 

    <claim type="userDefined" quality="known">
  <claimtype>Adopted Child<claimtype>
  <personref refid="ID4" />
</claim>

    If a relationship is uncertain as to whether a person is the child or grandchild of another person, then multiple claims should be made, inventing intervening persons where necessary, making sure to set the claim quality and person existance attributes appropriately.

    3.1.7 Documenting Attributes

    If it is desired to document attributes of a person such as occupation, or cause of death, a claimtype will need to be added, and the data set appropriately. 

    <claim type="userDefined" quality="known">
  <claimtype>Cause of Death<claimtype>
  <data>Shot 5 times by Indians</data>
</claim>

    3.1.8 Documenting Events

    If it is desired to document events such as graduation, or coronation, a claimtype will need to be added, and the data set appropriately. 

    <claim type="userDefined" quality="known">
  <claimtype>Graduation<claimtype>
  <data>University of Florida</data>
  <when><date>1955</date></when>
  <location><state>Florida</state></location>
</claim>

    3.1.9 Validation

    There are two methods provided for validating a GREnDL file: a Document Type Declaration (DTD) and an XML Schema (Schema). The DTD and Schema are included in two separate files grendl11.dtd and grendl11.xsd respectively. Both files should be downloaded and saved to a server, and then included in the file. The files can be linked to the server as follows: 

    <?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE grendl SYSTEM "grendl11.dtd">
<grendl xmlns:grendl="http://www.rumblefische.com/util/grendl/grendl11"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="grendl11.xsd"
        version="1.1"
        lang="en">
  ...
</grendl>

    These files both define the structure of the GREnDL 1.0 data model, though in slightly different ways. To validate the GREnDL file against the DTD or Schema, you must use a validating program of which many may be found online. Listed below are two:
    http://www.stg.brown.edu/service/xmlvalid/ (DTD)
    http://www.w3.org/2001/03/webdata/xsv (Schema)

    You may also download a validating program ( validator.exe) that will validate XML files against DTDs and Schemas as well as checking for well-formedness.

    A test file is also provided which makes use of most of the features of the data model and may be downloaded for conformance testing. (test1.xml).

    3.2 File Structure

    GREnDL documents should begin with an XML declaration which specifies the version of XML and the character encoding being used. This is then followed by the root element (grendl) and its contents. The root element includes a required attribute which specifies the version of GREnDL supported, and an optional attribute specifying the language of the data. See Validation for adding support for document type declarations and XML Schemas See Appendix A for adding support for XSL Stylesheets. 

    <?xml version="1.0" encoding="ISO-8859-1"?>
<grendl version="1.1" lang="language"? : "en">
  Content: head?, body, crc?
</grendl>

    3.2.1 head

    The head element contains information that does not pertain directly to the data represented. 

    <head>
  Content: file?, exporter?, submitter?
</head>
    3.2.1.1 file

    The file element contains data pertaining to the XML file. 

    <file>
  Content: title?, version?, modified*, copyright?, description?, link*, note*
</file>

    An example of a file element: 

    <file>
  <title>The Genealogy of John Doe</title>
  <version>1.0</version>
  <modified>
   <date>1999-05-31</date><time>18:20:00</time>
   <note>I lied. This file was never modified.</note>
  </modified>
  <copyright>The data is not copyrighted, guaranteed, or warranted.  Use at your own risk</copyright>
  <description>This file does not exist.</description>
</file>
    3.2.1.1.1 version

    The version element contains string text formatted in html 

    <version>
  Content: string
</version>

    An example of a version element: 

    <version>
  1.0b
</version>
    3.2.1.1.2 The copyright Data-Element

    The copyright element contains formatted text to be used as a copyright statement. 

    <copyright>
  Content: string
</copyright>

    An example of a copyright element: 

    <copyright>
  This file is copyrighted 2001 by the author
</copyright>
    3.2.1.2 exporter

    The exporter element contains data pertaining to the application that exported this file. The name and version of the exporter are required in the content. 

    <exporter>
  Content: description, version, address?, phone*, email*, link?, note*
</exporter>

    An example of a exporter element: 

    <exporter>
  <description>Adam</description>
  <version>1.0</version>
  <address><city>Austin</city><state>TX</state></address>
  <phone>512-000-0000</phone>
  <email>johndoe@gmail.com</email>
</exporter>
    3.2.1.3 submitter

    The submitter element contains data pertaining to the person or group who exported the file. The name of the submitter is required in the content. 

    <submitter>
  Content: description, address?, phone*, email*, link?, note*
</submitter>

    An example of a submitter element: 

    <submitter>
  <description>John Doe</description>
  <address><city>Austin</city><state>TX</state></address>
  <phone>512-000-0000</phone>
  <email>johndoe@gmail.com</email>
</submitter>

    3.2.2 body

    The body element contains the represented data. An optional security attribute is provided to set the security level for the entire body. See the section on Data Security for more information on how to use the security attributes. 

    <body security = ("private" | "public" | "local")? : "public">
  Content: contact*, source*, person*
</body>
    3.2.2.1 person

    The person includes an attribute specifying the unique id of the person. Also included are optional attributes specifying the security level of the person, the gender and the existance type. 

    <person
  id="ID"
  security = ("private" | "public" | "local")? : "public"
  gender = ("male" | "female" | "unknown")? : "unknown"
  existance = ("living" | "deceased" | "invented" | "mythical" | "unknown")? : "deceased">
  Content: mergeref?, name?, claim*, link*, research*, note*, modified*
</person>

    An example of a person element: 

    <person id="ID1" security="public" existance="living">
 <mergeref refid="ID1"/>
 <name>
  <given>John</given>
  <middle>Cornelius</middle>
  <surname>Doe</surname>
 </name>
 <claim type="birth">
  <when><date>1999-09-09</date></when>
  <location><city>Austin</city><state>TX</state></location>
  <citationref refid="ID1" />
 </claim>
</person>
    3.2.2.1.1 mergeref

    The mergeref element contains the id of another element of the same type which has been determined to be the primary equivalent element. 

    <mergeref refid = "IDREF"/>

    An example of a mergeref element: 

    <mergeref refid="ID1"/>
    3.2.2.1.2 name

    The name element specifies the various parts of the name for a person. 

    <name>
  Content: honorific?, nickname*, given?, taken*, called*, middle?, religious?, prefix?, surname, ordinal?, suffix?,
           agnomen*, designation*
</name>

    An example of a name element: 

    <name>
  <honorific>Sir</honorific>
  <nickname>Sticks</nickname>
  <given>Cornelius</given>
  <taken>John</taken>
  <called>Johnny</called>
  <middle>Martinez</middle>
  <religious>Garcia</religious>
  <prefix>de la</prefix>
  <surname>Doe</surname>
  <oridinal>III</oridinal>
  <suffix>M.D.</suffix>
  <agnomen>The Great</agnomen>
  <designation>Baron of Dunkirk</designation>
</name>
    3.2.2.1.2.1 honorific

    The honorific element contains the prefixes to a name to show honor or respect, such as: Sir, Dame, Mr., Mrs., Sgt., Lt., Hon., Lord, Baron, King, Queen, etc. 

    <honorific>
  Content: string
</honorific>

    An example of a honorific element: 

    <honorific>
 Sir
</honorific>
    3.2.2.1.2.2 nickname

    The nickname element contains the nickname or alias that a person was called during their lifetime. 

    <nickname>
  Content: string
</nickname>

    An example of a nickname element: 

    <nickname>
 Sticks
</nickname>
    3.2.2.1.2.3 given

    The given element contains the persons given or proper first name. 

    <given>
  Content: string
</given>

    An example of a given element: 

    <given>
 Jonathan
</given>
    3.2.2.1.2.4 taken

    The taken element contains the name that a person took during their lifetime. This may have been a name change, or done for religious or political reasons. 

    <taken>
  Content: string
</taken>

    An example of a taken element: 

    <taken>
 David
</taken>
    3.2.2.1.2.5 called

    The called element contains the name that a person was called during their lifetime. 

    <taken>
  Content: string
</taken>

    An example of a called element: 

    <called>
 Johnny
</called>
    3.2.2.1.2.6 middle

    The middle element contains the middle name(s) of a person. 

    <middle>
  Content: string
</middle>

    An example of a middle element: 

    <middle>
 Cornelius
</middle>
    3.2.2.1.2.7 religious

    The religious element contains the religious name(s) of a person. 

    <religious>
  Content: string
</religious>

    An example of a religious element: 

    <religious>
 Garcia
</religious>
    3.2.2.1.2.8 prefix

    The prefix element contains the surname prefixes in the form of articles and determiners, such as de, la, Le, Del, von, van, fitz, verch, ap, etc. 

    <prefix>
  Content: string
</prefix>

    An example of a prefix element: 

    <prefix>
 de la
</prefix>
    3.2.2.1.2.9 surname

    The surname element contains the surname of a person. An optional attribute is provided to specify the type of surname. 

    <surname type = ("family" | "clan" | "patronynic" | "matronynic" | "tektronynic" | "inherited" |
                 "religious" | "occupational" | "locational" | "characteristic" | "other" |
                 "unknown")? : "unknown">
  Content: string
</surname>

    An example of a surname element: 

    <surname type="family">
 Doe
</surname>
    3.2.2.1.2.10 ordinal

    The ordinal element contains the surname suffix which represents descent of a family name or title 

    <ordinal>
  Content: string
</ordinal>

    An example of a ordinal element: 

    <ordinal>
 III
</ordinal>
    3.2.2.1.2.11 suffix

    The suffix element contains the surname suffix, such as Jr., M.D. D.V.M. Esq., etc. 

    <suffix>
  Content: string
</suffix>

    An example of a suffix element: 

    <suffix>
 Jr.
</suffix>
    3.2.2.1.2.12 agnomen

    The agnomen element contains a phrase given to a person, not neccesarily while they were living, which describes that person, such as "the great", "the white", "of Ireland", etc. 

    <agnomen>
  Content: string
</agnomen>

    An example of a agnomen element: 

    <agnomen>
 The Great
</agnomen>
    3.2.2.1.2.13 designation

    The designation element contains a person's titles that are hereditary, appointed, elected, or earned, such as: King of England, Professor of Biology, Supreme Court Justice, etc. 

    <designation>
  Content: string
</designation>

    An example of a designation element: 

    <designation>
 Baron of Dunkirk
</designation>
    3.2.2.1.3 claim

    An analysis of each citation should generate any number of claim elements. Claim elements are embdded in Person elements. It includes optional attributes specifying the security level of the claim, quality, and the type. The type may be "userDefined", in which case, a claimtype element is expected. Reference elements are provided for the generating citations. 

    <claim
  security = ("private" | "public" | "local")? : "public"
  type = ("name" | "age" | "numberOfChildren" | "orderOfBirth" | "parent" |
          "child" | "spouse" | "birth" | "baptism" | "death" |
          "burial" | "marriage" | "union" | "divorce" | "seperation" | "annulment" |
          "emigration" | "immigration" | "ship" | "lived" | "userDefined")? : "userDefined">
  quality = ("known" | "probable" | "possible" | "questionable" | "improbable" |
             "impossible" | "unknown")? : "unknown">
  Content: claimtype?, (data | personref)?, when?, location?, citationref*, link*, research*, note*, modified*
</claim>

    An example of a claim element: 

    <claim security="public" type="name" quality="likely">
  <data>John Cornelius Doe</data>
  <citationref refid="ID1" />
</claim>

    An example of a claim element: 

    <claim type="birth">
  <when><date>1999-09-09</date></when>
  <location><city>Austin</city><state>TX</state></location>
  <citationref refid="ID1" />
</claim>

    An example of a claim element: 

    <claim type="marriage">
  <personref refid="ID1" />
  <when><date>1999-09-09</date></when>
  <location><city>Austin</city><state>TX</state></location>
  <citationref refid="ID1" />
</claim>
    3.2.2.1.3.1 claimtype

    The claimtype element contains a user defined type of claim of which there may be an unbounded number defined. 

    <claimtype>
  Content: string
</claimtype>

    An example of a claimtype element: 

    <claimtype>
 occupation
</claimtype>
    3.2.2.1.3.2 data

    The data element contains the data associated with a claim. 

    <data>
  Content: string
</data>

    An example of a data element: 

    <data>
 farmer
</data>
    3.2.2.1.3.3 personref

    The personref element contains the id of a person element referenced by this element. 

    <personref
  refid = "IDREF" />

    An example of a personref element: 

    <personref refid="ID1"/>
    3.2.2.1.3.4 when

    The when element contains the date of an event or the date of an occurance of an attribute. It includes an optional attribute specifying the type of date. 

    <when type = ("known" | "exact" | "quoted" | "calculated" | "estimated" | "derived" |
              "approximated" | "unknown")? : "unknown"
  Content: ((about | before | after | ((date, time?, era?, calendar?) | jdn | age | description)) | from | between)
</when>

    An example of a when element: 

    <when type="calculated">
 <date>1974</date>
</when>
    3.2.2.1.3.4.1 about

    The about element contains an appoximate date of an event or occurance of an attribute. 

    <about>
  Content: ((date, time?, era?, calendar?) | jdn | age | description))
</about>

    An example of a about element: 

    <about>
 <date>1974</date>
</about>
    3.2.2.1.3.4.2 before

    The before element contains a date after an event or occurance of an attribute . 

    <before>
  Content: ((date, time?, era?, calendar?) | jdn | age | description))
</before>

    An example of a before element: 

    <before>
 <date>1974</date>
</before>
    3.2.2.1.3.4.3 after

    The after element contains a date before an event or occurance of an attribute. 

    <after>
  Content: ((date, time?, era?, calendar?) | jdn | age | description))
</after>

    An example of a after element: 

    <after>
 <date>1974</date>
</after>
    3.2.2.1.3.4.4 from

    The from element contains the range of dates encompassing an event occured, or for which an attribute was true (i.e. WWII occured from 1941 to 1945, or John worked as a farmer from 1941 to 1945). 

    <from>
  Content: (about | before | after | ((date, time?, era?, calendar?) | jdn | age | description)), to
</from>

    An example of a from element: 

    <from>
 <about><date>1974</date></about>
 <to><before><date>1985</date></before></to>
</from>
    3.2.2.1.3.4.4.1 to

    The to element is used along with the from element to specify a range of dates. 

    <to>
  Content: (about | before | after | ((date, time?, era?, calendar?) | jdn | age | description))
</to>

    An example of a to element: See from.

    3.2.2.1.3.4.5 between

    The between element contains the range of dates during which an event may have occured, or for which an attribute may have been true (i.e. John died between Jan 9, 1941 and Dec 2, 1945). 

    <between>
  Content: (about | before | after | ((date, time?, era?, calendar?) | jdn | age | description)), and
</between>

    An example of a between element: 

    <between>
 <after><date>1974</date></after>
 <and><before><date>1985</date></before></and>
</between>
    3.2.2.1.3.4.5.1 and

    The and element is used along with the between element to specify a range of dates. 

    <and>
  Content: (about | before | after | ((date, time?, era?, calendar?) | jdn | age | description))
</and>

    An example of a and element: See between.

    3.2.2.1.3.4.6 date

    The date element contains an date of an event or occurance of an attribute. 

    <date>
  Content: date
</date>

    An example of a date element: 

    <date>
 1974-01-23
</date>
    3.2.2.1.3.4.7 time

    The time element contains an optional attribute to specify whether or not the time is in Coordinated Universal Time (UTC). Otherwise the time is considered to be local. 

    <time>
  utc = "boolean"? : "FALSE"
  Content: time
</time>

    An example of a time element: 

    <time utc="TRUE">
  18:20:00
</time>
    3.2.2.1.3.4.8 era

    The era element specifies era of a date (i.e. A.D., B.C., B.C.E., in the reign of Caeser). 

    <era>
  Content: string
</era>

    An example of a era element: 

    <era>
 B.C.E.
</era>
    3.2.2.1.3.4.9 calendar

    The calendar element contains the date's calendar. 

    <calendar>
  Content: string
</calendar>

    An example of a calendar element: 

    <calendar>
 Gregorian
</calendar>
    3.2.2.1.3.4.10 jdn

    The jdn element contains an Julian Day Number of an event or occurance of an attribute. 

    <jdn>
  Content: positiveInteger
</jdn>

    An example of a jdn element: 

    <jdn>
 198475643
</jdn>
    3.2.2.1.3.4.11 age

    The age element contains a person's age when an event occured, or an attribute was present. 

    <age>
  Content: unsignedInt
</age>

    An example of a age element: 

    <age>
 34
</age>
    3.2.2.1.3.4 location

    The location element contains the data for a location referenced in a claim. 

    <location>
  Content: description?, address?, longitude?, latitude?, elevation?, link*, note*
</location>

    An example of a location element: 

    <location>
  <desciption>Austin, TX</desciption>
  <address>
   <city>Austin</city><state>TX</state>
  </address>
</location>
    3.2.2.1.3.4.1 address

    The address element specifies the address of the location. 

    <address>
  Content: street*, city?, county?, state?, country?, continent?, postalcode?
</address>

    An example of a address element: 

    <address>
  <street>111 S. North West Street</street>
  <street>Apt. #112</street>
  <city>Dunkirk</city>
  <county>Waterford County</county>
  <state>Colorado</state>
  <country>Ireland</country>
  <continent>Asia</continent>
  <postalcode>76543-5764</postalcode>
</address>
    3.2.2.1.3.4.1.1 street

    The street element lists the street of the location. 

    <street>
  Content: string
</street>

    An example of a street element: 

    <street>
 P.O. Box 11232
</street>
    3.2.2.1.3.4.1.2 city

    The city element lists the city of the location. An attribute is provided to specify the type of city. 

    <city>
  type = ("farm" | "community" | "village" | "town" | "city" | "diocese" |
          "parish" | "municipality")? : "city"
  Content: string
</city>

    An example of a city element: 

    <city type="city">
 Chicago
</city>
    3.2.2.1.3.4.1.3 county

    The county element lists the county of the location. An attribute is provided to specify the type of county. 

    <county type = ("county" | "district" | "provence" | "principality")? : "county">
  Content: string
</county>

    An example of a county element: 

    <county type="county">
 Cook Co.
</county>
    3.2.2.1.3.4.1.4 state

    The state element lists the state of the location. 

    <state>
  Content: string
</state>

    An example of a state element: 

    <state>
 Illinois
</state>
    3.2.2.1.3.4.1.5 country

    The country element lists the country of the location. 

    <country>
  Content: string
</country>

    An example of a country element: 

    <country>
 U.S.A.
</country>
    3.2.2.1.3.4.1.6 continent

    The continent element lists the continent of the location. 

    <continent>
  Content: string
</continent>

    An example of a continent element: 

    <continent>
 N. America
</continent>
    3.2.2.1.3.4.1.7 postalcode

    The postalcode element lists the postalcode of the location. 

    <postalcode>
  Content: string
</postalcode>

    An example of a postalcode element: 

    <postalcode>
 60000-1234
</postalcode>
    3.2.2.1.3.4.2 longitude

    The longitude element specifies the longitude of the location. 

    <longitude>
  Content: string
</longitude>

    An example of a longitude element: 

    <longitude>
 35°43'9"W
</longitude>
    3.2.2.1.3.4.3 latitude

    The latitude element specifies the latitude of the location. 

    <latitude>
  Content: string
</latitude>

    An example of a latitude element: 

    <latitude>
 35°43'9"N
</latitude>
    3.2.2.1.3.4.4 elevation

    The elevation element specifies the elevation of the location. 

    <elevation>
  Content: string
</elevation>

    An example of a elevation element: 

    <elevation>
 1000ft
</elevation>
    3.2.2.1.3.5 citationref

    The citationref element contains the id of a citation element referenced by this element. 

    <citationref refid = "IDREF" />

    An example of a citationref element: 

    <citationref refid="ID1" />
    3.2.2.1.4 link

    The link element contains a caption and uri for an internal or external link. 

    <link type = ("internal" | "external")? : "external">
  Content: uri, caption?
</link>

    An example of a link element: 

    <link type="external">
  <uri>http://www.TheMonaLisa.com</uri>
  <caption>The Mona Lisa</caption>
</link>
    3.2.2.1.4.1 uri

    The uri element contains a uri for a link. 

    <uri>
  Content: anyURI
</uri>

    An example of a uri element: 

    <uri>
  http://www.ancestry.com
</uri>
    3.2.2.1.4.2 caption

    The caption element contains a caption for a link. 

    <caption>
  Content: string
</caption>

    An example of a caption element: 

    <caption>
  Ancestry.com
</caption>
    3.2.2.1.5 research

    The research element contains the data for a research task associated with the element. It includes optional attributes specifying the status and prioity of the research task. 

    <research
  status = ("complete" | "partial" | "incomplete" | "dismissed")? : "incomplete"
  priority = ("urgent" | "high" | "medium" | "low")? : "low">
  Content: objective, resolution?
</research>

    An example of a research element: 

    <research status="incomplete" priority="high">
  <objective>Check the census records for this person.  Was he born in 1880?</objective>
  <resolution>Have checked 1880 census for the following four towns: A, B, C, D</resolution>
</research>
    3.2.2.1.5.1 objective

    The objective element contains a objective for the research task. 

    <objective>
  Content: string
</objective>

    An example of a objective element: 

    <objective>
  Search for parents' birth certificates
</objective>
    3.2.2.1.5.2 resolution

    The resolution element contains a resolution for the research task. 

    <resolution>
  Content: string
</resolution>

    An example of a resolution element: 

    <resolution>
  The birth certificates were obtained by sending a request with
  a check for $5.00 to the following address: ...
</resolution>
    3.2.2.1.6 note

    The note element contains notes about the element 

    <note>
  Content: (string | htmlblock)*
</note>

    An example of a note element: 

    <note>
  blah, blah, blah
</note>
    3.2.2.1.6.1 htmlblock

    The htmlblock element contains string text formatted in html 

    <htmlblock>
  Content: html
</htmlblock>

    An example of a htmlblock element: 

    <htmlblock>
  Hello<br/>Goodbye
</htmlblock>
    3.2.2.1.7 modified

    The modified element contains the date and time the element was modified, and optionally a description of the change. 

    <modified>
  Content: date, time?, note*
</modified>

    An example of a modified element: 

    <modified>
  <date>1999-05-31</date>
  <time>18:20:00</time>
  <note>The birthdate was changed because it was discovered to be wrong.</note>
</modified>
    3.2.2.2 source

    The source element includes an attribute specifying the unique id of the source. Also included are optional attributes specifying the security level of the source, the source type, the reference type, the media format, the condition, and the quality of the source. 

    <source
  id = "ID"
  security = ("private" | "public" | "local")? : "public"
  type = ("book" | "volume" | "periodical" | "tombstone" | "bible" | "courtRecord" |
          "churchRecord" | "censusRecord" | "birthRecord" | "deathRecord" | "marriageRecord" |
          "burialRecord" | "landRecord" | "visitation" | "roll" | "manuscript" |
          "electronicDatabase" | "privateRecord" | "letter" | "other" | "unknown")? :
          "unknown"
  reference = ("original" | "reprint" | "copy" | "image" | "transcription" | "other" |
               "unknown")? : "unknown"
  media = ("audio" | "video" | "microfische" | "microfilm" | "photo" | "printed" | "handwritten" |
           "inscription" | "other" | "unknown")? : "unknown"
  condition = ("legible" | "partiallyLegible" | "partiallyIllegible" | "illegible" | "unknown")? :
               "unknown"
  quality = ("proofed" | "unproofed" | "unknown")? : "unknown">
  Content: mergeref?, title?, abbr?, author*, publisher*, volume?, issue?, number?, citation*, contactref*, link*,
           research*, note*, modified*
</source>

    An example of a source element: 

    <source id="ID1" security="public" type="book" reference="original" media="printed"
        condition="legible" quality="proofed">
  <mergeref refid="ID1"/>
  <title>The Colonial Ancestors of John Doe</title>
  <abbr>CAJD</abbr>
  <author>John Doe, Sr.</author>
  <publisher><date>2000</date><note>Self Published</note></publisher>
  <volume>1</volume>
  <citation>
   <text>John Doe died young</text>
  </citation>
  <contactref refid="ID1" />
  <contactref refid="ID2">
   <code>123.4.5n</code>
  </contactref>
</source>
    3.2.2.2.1 title

    The title element contains the title of a source or file. 

    <title>
  Content: string
</title>

    An example of a title element: 

    <title>
  The Colonial Ancestors of John Doe
</title>
    3.2.2.2.2 abbr

    The abbr element contains an abbreviation of a source title. 

    <abbr>
  Content: string
</abbr>

    An example of a abbr element: 

    <abbr>
  The Green Book
</abbr>
    3.2.2.2.3 author

    The author element contains the name of an author. Optional attributes are provided to specify the type of author, and the placement order. 

    <author
  order = "positiveInteger"? : "1"
  type = ("author" | "editor" | "contributor")? : "author">
  Content: string
</author>

    An example of a author element: 

    <author order="1" type="contributor">
  Mrs. John Doe
</author>
    3.2.2.2.4 publisher

    The publisher element contains the name of the publisher and specific information about the publication. 

    <publisher>
  Content: description, date?, address?, isbn?, issn?, note*
</publisher>

    An example of a publisher element: 

    <publisher>
  <description>John Doe, Sr.</description>
  <date>Jan 2000</date>
  <address><city>Austin</city><state>TX</state></address>
  <isbn>000-0000-000</isbn>
  <issn>00-000000</issn>
  <note>Self Published</note>
</publisher>
    3.2.2.2.4.1 isbn

    The isbn element contains the 10-digit International Standard Book Number of the publication. 

    <isbn>
  Content: string
</isbn>

    An example of a isbn element: 

    <isbn>
  000-0000-000
</isbn>
    3.2.2.2.4.2 issn

    The issn element contains the 8-digit International Standard Serial Number of the publication. 

    <issn>
  Content: string
</issn>

    An example of a issn element: 

    <issn>
  00-000000
</issn>
    3.2.2.2.5 volume

    The volume element contains the volume number of the publication. 

    <volume>
  Content: string
</volume>

    An example of a volume element: 

    <volume>
  IV
</volume>
    3.2.2.2.6 issue

    The issue element contains the issue of the publication. 

    <issue>
  Content: string
</issue>

    An example of a issue element: 

    <issue>
  3
</issue>
    3.2.2.2.7 number

    The number element contains the volume or issue number of the publication. 

    <number>
  Content: string
</number>

    An example of a number element: 

    <number>
  15
</number>
    3.2.2.2.8 citation

    The citation element includes an attribute specifying the unique id of the citation. Also included are optional attributes specifying the security level of the citation, the format, and the reliabaility. 

    <citation
  id = "ID"
  security = ("private" | "public" | "local")? : "public"
  format = ("transcript" | "extract" | "abstract" | "unknown")? : "unknown"
  reliability = ("primary" | "secondary" | "unquestionable" | "reliable" | "questionable" |
                 "unreliabale" | "unknown")? : "unknown"
  Content: part?, section?, chapter?, page?, paragraph?, text?, link*, research*, note*, modified*
</citation>

    An example of a citation element: 

    <citation id="ID1" security="public" format="transcript" reliability="secondary">
  <part>I</part>
  <section>2</section>
  <chapter>18</chapter>
  <page>345</page>
  <paragraph>2</paragraph>
  <text>I am citation text, see me roar!</text>
</citation>
    3.2.2.2.8.1 part

    The part element contains the part number of a citation in a multipart work. 

    <part>
  Content: string
</part>

    An example of a part element: 

    <part>
  III
</part>
    3.2.2.2.8.2 section

    The section element contains the section number of a citation in a multisection work. 

    <section>
  Content: string
</section>

    An example of a section element: 

    <section>
  2
</section>
    3.2.2.2.8.3 chapter

    The chapter element contains the chapter number of a citation in a multichapter work. 

    <chapter>
  Content: string
</chapter>

    An example of a chapter element: 

    <chapter>
  1: The Immigrants
</chapter>
    3.2.2.2.8.4 page

    The page element contains the page number of a citation. 

    <page>
  Content: string
</page>

    An example of a page element: 

    <page>
  123
</page>
    3.2.2.2.8.5 paragraph

    The paragraph element contains a page's paragraph number of a citation 

    <paragraph>
  Content: string
</paragraph>

    An example of a paragraph element: 

    <paragraph>
 2
</paragraph>
    3.2.2.2.8.6 text

    The text element contains the the actual text of a citation, or a summary of the text, formatted to match the source as closely as possible. 

    <text>
  Content: (string | htmlblock)*
</text>

    An example of a text element: 

    <text>
  He was born in Germany.
</text>
    3.2.2.2.9 contactref

    The contactref element contains the id of a contact element referenced by this element. 

    <contactref refid = "IDREF">
  Content: code?
</contactref>

    An example of a contactref element: 

    <contactref refid="ID1">
 <code>123.fde65g</code>
</contactref>

or

<contactref refid="ID1" />
    3.2.2.2.9.1 code

    The code element contains the reference code used by a particular contact to refer to a source. It is only used when the reference occurs under a source element. 

    <code>
  Content: string
</code>

    An example of a code element: 

     <code>
   123.fde65g
 </code>
    3.2.2.3 contact

    There will be a contact element for each repository or personal contact. It includes an attribute specifying the unique id of the contact. Also included are optional attributes specifying the security level of the contact, and the contact type. 

    <contact
  id = "ID"
  security = ("private" | "public" | "local")? : "public""
  merge = ("primary" | "nonprimary")? : "primary""
  type = ("repository" | "business" | "personal")? : "repository">
  Content: mergeref?, description, address?, phone*, email*, link*, research*, note*, modified*
</contact>

    An example of a contact element: 

    <contact id="ID1" security="public" type="repository">
  <mergeref refid="ID1"/>
  <description>The Austin Library</description>
  <address><city>Austin</city><state>TX</state></address>
  <phone>512-000-0000</phone>
  <email>johndoe@gmail.com</email>
</contact>
    3.2.2.3.1 description

    The description element is used to describe an element. 

    <description>
  Content: string
</description>

    An example of a description element: 

    <description>
  A big black thing
</description>
    3.2.2.3.2 phone

    The phone element contains a phone number. An optional attribute is provided to specify the type of phone number listed. 

    <phone type = ("home" | "office" | "cell" | "pager" | "fax" | "other")? : "other">
  Content: string
</phone>

    An example of a phone element: 

    <phone type="office">
  512-000-0000
</phone>
    3.2.2.3.3 email

    The email element contains an email address. An optional attribute is provided to specify the type of email address listed. 

    <email type = ("home" | "office" | "other")? : "other">
  Content: string
</email>

    An example of a email element: 

    <email type="office">
  johndoe@gmail.com
</email>

    3.2.3 crc

    The crc element contains a 32-bit cyclic redundancy check (CRC) of the grendl element. This is used to verify the integrity of the content. Changing the contents of the grendl element either intentionally through manual editing, or accidently through file corruption, will invalidate the CRC. Importing applications should inform the user that the data integrity has been compromised. See the section on Data Integrity for more information on how to calculate and verify the CRC. 

    <crc>
  Content: crc
</crc>

    An example of a crc element: 

    <crc>
 3446326246
</crc>

    4 Appendix A: Representing the Data

    XML is not a representation language, and therefore GREnDL does not have representation abilities incorporated within the data model. There are any number of ways that the XML data could be transformed for display purposes. I will discuss only one method here. This method is easy enough for anyone to use.

    XML supports XSL stylesheets which allow you to transform your data into any number of output formats. I have provided XSL stylesheets for converting your GREnDL file into HTML by two seperate means. The first method includes two stylesheets that will display your XML file as HTML in a web browser such as Internet Explorer 6.0. This method however is slow on large files and therefore does not provide an easy method for streaming your pages over the internet, so a second set of stylesheets is provided for that purpose.

    Method 1: To display your GREnDL file in HTML in your browser, you will need to download three files: grendl11.xsl , templates.grendl.xsl and style.css. The last two files are included by the first file. You must then include the following at the start of your file 

    <?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet type="text/xsl" href="grendl11.xsl"?>
 ...
<grendl version="1.1"> ... </grendl>
    This can be tested by downloading the test file test1.xml and opening it in a web browser.

    Method 2: To create a set of HTML pages for streaming over the internet, you must download two files: publish.grendl.xsl , templates.grendl.xsl and style.css. The last two files are included by the first file. You must then download the free utility saxon.exe Execute the following on the command line to create a set of HTML pages. 

    saxon test1.xml publish.grendl.xsl

    All of the stylesheets may be modified to suit your needs. These are only provided here as examples.

    5 Appendix B: Converting the Data

    I have written a conversion program, refered to as Adam (adam.exe), to convert from a GEDCOM 5.5 file to a GREnDL 1.0 file.

    The conversion program converts the most commonly used GEDCOM tags only. Unsupported tags will be printed to the screen and to a log file (log.html). The program expects any specified paths to already exist. The convert the files execute the following: 

    adam -i path/input.ged -g path/output.xml

    6 References

    HTML 4.01
    World Wide Web Consortium. Hypertext Markup Language, version 4.01. 24 December 1999. Available at: http://www.w3.org/TR/1999/REC-html401-19991224/
    RFC 1766
    H. Alvestrand, ed. RFC 1766: Tags for the Identification of Languages. March 1995. Available at: http://www.ietf.org/rfc/rfc1766.txt
    RFC 2396
    Tim Berners-Lee, et. al. RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax.. August 1998. Available at: http://www.ietf.org/rfc/rfc2396.txt
    RFC 2732
    RFC 2732: Format for Literal IPv6 Addresses in URL's. December 1999. Available at: http://www.ietf.org/rfc/rfc2732.txt
    XML 1.0 (Second Edition)
    World Wide Web Consortium. Extensible Markup Language (XML) 1.0, Second Edition. 6 October 2000. Available at: http://www.w3.org/TR/2000/REC-xml-20001006

    7 Index


    abbr
    about
    address
    after
    age
    agnomen
    and
    author
    before
    between
    body
    calendar
    called
    caption
    chapter
    claim
    claimtype
    citation
    citationref
    city
    code
    contact
    contactref
    continent
    copyright     		  
    country
    county
    crc
    crc
    data
    date
    description
    designation
    elevation
    email
    era
    exporter
    file
    from
    given
    grendl
    head
    honorific
    htmlblock
    isbn
    issn
    issue
    jdn
    latitude
    link     		  
    location
    longitude
    mergeref
    middle
    modified
    name
    nickname
    note
    number
    objective
    ordinal
    page
    paragraph
    person
    part
    personref
    phone
    postalcode
    prefix
    publisher
    religious
    research
    resolution
    section
    source     		  
    state
    street
    submitter
    suffix
    surname
    taken
    text
    time
    title
    to
    uri
    version
    volume
    when