(Proposed ADIF 3.0.4 Resources, updated 2013/07/28, annotated with changes from the previous release's ADX Schema document: green for additions, and red for deletions)

Resources for Version 3.0.4 of the Amateur Data Interchange Format (ADIF) SpecificationADX XML Schemas for Amateur Data Interchange Format (ADIF)

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

I. Introduction

This document gives details of resources that supplement the Amateur Data Interchange Format (ADIF) Specification.

The resources are version-specific.

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.:  One is specific to ADX 3.0.3 and provides the most accurate representation because it disallows deprecated features.  A second, non-version specific schema is also provided for situations where the ADX version is not known in advance.

The version-specific schema adx303.xsd is available here.
The non-version-specific schema adx303generic.xsd is available here.

II.A. Checks not Required

II.B. Limitations


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:

0
-1
10.37
.333
0008.50

Examples of invalid ADIF Numbers:

+10.37(plus sign not allowed)
0008,50(decimal point must be a dot (.))
1,000,000("thousands separator" not allowed)
10.100.500(only one decimal point allowed)
0x3c(only decimal numbers allowed)

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

Examples:

<AGE:4>50.5
<TX_PWR:3>7.5

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

Examples:

14(14 MHz / 14000 kHz)
10.1005(10.1005 MHz / 10100.5 kHz)
0.472(0.472 MHz / 472 kHz)

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

Examples:

100(100 Watts / 100000 milliwatts)
7.5(7.5 Watts / 7500 milliwatts)
0.25(0.25 Watts / 250 milliwatts)

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:

<COMMENT:0>
<NOTES:8>TEMP 24C

Examples of data length specifiers valid only when importing:

<COMMENT:000>
<NOTES:0008>TEMP 24C

Examples of invalid data length specifiers:

<NOTES:+8>TEMP 24C(plus sign (+) not permitted)
<STX:3.0>001(specifier must be an integer)

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 only for a useful minimum set of fields to include in a record representing a QSO:

QSO_DATE, TIME_ON, CALL, BAND, MODE

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.