(Proposed ADIF 3.0.9 Resources, updated 2018/11/21, annotated with changes from the previous release: green for additions, and red for deletions)

Resources for Version 3.0.83.0.9 of the Amateur Data Interchange Format (ADIF) Specification

Table of Contents

1. Introduction
2. ADX Schemas
   1. Checks not Required
   2. Limitations
3. ADIF Implementation Notes
   1. Number Data Type
   2. ADI Data Length Specifier
   3. Minimum Fields
4. External Links

I. Introduction

II. ADX Schemas

ADIF 3.0.2 introduced ADX as an alternative file format for representing ADIF employing XML syntax.  The ADX XML Schemas supplement this, describing ADX using the XML Schema definition language 1.0

The ADX schemas can be used to determine whether ADX complies with the ADIF specification.  If used, they must be applied externally without being referenced in the <ADX> root element.

Most aspects of the ADIF specification are validated, subject to some checks that cannot be performed due to being advisory only and others which are not possible or impractical to check.

Two schemas are provided:

• adx309.xsd is specific to ADX 3.0.83.0.9 and disallows deprecated features.
  Expected use is when exporting ADIF as ADX 3.0.83.0.9
   
• adx309generic.xsd is not version-specific and includes deprecated features.  It is provided for situations where the ADX version is not known in advance and could be ADX 3.0.83.0.9 or earlier.
  Expected use is when importing ADIF as ADX.

II.A. Checks not Required

• CONTEST_ID element contents are not validated against the "Contest ID" enumeration because the ADIF field type is "String" (i.e. the enumeration is advisory).
• CNTY and MY_CNTY element contents are not validated against the "Secondary Administrative Subdivision" enumeration because the enumeration values are controlled by external organizations and so are subject to change without notice.
• SUBMODE element contents are not validated against the "Submode" enumeration because the ADIF field type is "String" (i.e. the enumeration is advisory).

II.B. Limitations

• MY_STATE and STATE element contents are not validated against the "Primary Administrative Subdivision" enumeration due to the excessively long regular expression required.
• User-defined field names (contents of the USERDEF element nested in the HEADER element) are not validated against the pre-defined ADIF field names due to the excessively long regular expression required.
• USERDEF elements nested in the HEADER element can optionally have either a RANGE or ENUM attribute but not both; this is not validated.
• Values in FIELDNAME attributes belonging to USERDEF elements nested in a RECORD element are not validated against the USERDEF elements in the HEADER element.
• USERDEF elements nested in RECORD elements do not have their contents validated against the TYPE, RANGE or ENUM (if any) attributes of the corresponding USERDEF element nested in the HEADER element.
• APP element contents are not validated against the TYPE attribute (if any) given.
• In a record or in the header, no field may appear in more than one Data Specifier; this is not validated.

III. Implementation Notes

III.A. Number Data Type

Numbers conforming to the ADIF Number data type are always decimal (base 10).  Negative numbers are preceded by a minus sign (-).  However, positive numbers are not preceded by a plus sign (+).  Leading and trailing zeros are optional.  A decimal point (.) is optional.

Using locale-sensitive library routines to read or write ADIF numbers can produce incorrect results.  For example, a locale may specify that the character representing a decimal point is a comma - this is not acceptable in ADIF.

Examples of valid ADIF Numbers:

Examples of invalid ADIF Numbers:

In some Number Data Type fields, although an integer value is typically used, the ADIF specification does not restrict the value to integers.

Examples:

Frequencies in fields are in Megahertz.  Kilohertz can be represented by digits to the right of a decimal point.

Examples:

Similarly, power levels less than one Watt can be represented by digits to the right of a decimal point.

Examples:

III.B. ADI Data Length Specifier

ADI data length specifiers are unsigned decimal (base 10) integers and may have values greater than, or equal to, zero.  Leading zeros are deprecated: they must not be created when exporting ADI, but must be accepted when reading ADI because they were permitted in earlier versions of the ADIF specification.

Examples of valid data length specifiers:

Examples of data length specifiers valid only when importing:

Examples of invalid data length specifiers:

III.C. Minimum Fields

The ADIF specification does not specify what fields must be included in a record nor does a record necessarily have to represent a QSO.

The following is a guideline for a useful minimum set of fields to include in a record representing a QSO:

Importing applications such as eQSL.cc, LoTW and Club Log typically impose additional requirements and their documentation should be consulted for details.

The value in some fields is dependent on the value in another field, and in this case both fields should be included in a record.  For example, the interpretation of the STATE field value depends on the value in the DXCC field.

IV. External Links

1. Club Log APIs and Integration Notes
2. eQSL ADIF Content Specifications
3. LoTW Developer's Information (ARRL)
4. XML Schema Part 1: Structures Second Edition (W3C)