The Ajax Command Definition (ACD) language was designed for writing ACD files for EMBOSS applications. Every application in EMBOSS or EMBASSY has an ACD file. The ACD syntax allows for very flexible descriptions of an application's parameters and its command line interface. It can specify everything that can appear on the command line or in another interface such as a web page.

ACD files are plain ASCII text files and must have the extension .acd. Typically they have the same name as the application, but this is not mandatory.

An ACD file contains a single application definition and a data definition for each parameter. The application definition is given first, followed by the data definitions. Data definitions are organised into sections (see Section A.1.6, “ACD File Sections”).

Application and data definitions have the following general form: a single text token followed by a colon ':' (or '=') and a white space, followed by a second token. The definition body follows, which is one or more attributes delimited by a mandatory pair of square brackets [ ], which can span multiple lines. Each attribute is a name: value pair with the attribute value given between quotes (" "):

Either:

token: token 
[
   Attribute1Name: "Attribute1Value"
   Attribute2Name: "Attribute2Value"
]

Or:

token=token 
[
   Attribute1Name: "Attribute1Value"
   Attribute2Name: "Attribute2Value"
]

The first token is either application: (for the application definition) or an AJAX datatype (e.g. sequence) for data definitions. The second token is either the name of the application (e.g. seqret) or the name of parameter (e.g. asequence).

Application definition:

application: ApplicationName 
[
   ApplicationAttribute1Name: "ApplicationAttribute1Value"
   ApplicationAttribute2Name: "ApplicationAttribute2Value"
]

Data definition:

Datatype: ParameterName 
[
   DataAttribute1Name: "DataAttribute1Value"
   DataAttribute2Name: "DataAttribute2Value"
]

The application token and tokens for the datatype and attribute names can be can be abbreviated up to the point where they are not ambiguous. Such abbreviations are not recommended however because they tend to make the ACD file more difficult to read.

Attribute values are normally enclosed in double quotes, although this is only mandatory for values (typically strings) which include whitespace.

application: ApplicationName 
[
   ApplicationAttribute1Name: "ApplicationAttribute1Value"
   ApplicationAttribute2Name: "ApplicationAttribute2Value"
]

Datatype: ParameterName 
[
   DataAttribute1Name: "DataAttribute1Value"
   DataAttribute2Name: "DataAttribute2Value"
]

Application attributes may be defined for an application definition (Section A.3, “Application Attributes”).

There are three basic types of attributes that may be defined for a data definition:

Additionally, there are various "datatype associated" command line qualifiers (or simply "associated qualifiers") that are inbuilt for certain ACD datatypes may also be defined as attributes in the appropriate data definition. These are listed in the datatype descriptions (Section A.2, “Datatypes”).

Every data definition in the ACD file can be defined via an appropriate attribute to be one of the following:

with the default being:

They differ in terms of how they are prompted for, how they may be specified on the command line and whether help information for them appears.

This behaviour is summarised in the table below (Table A.2, “Behaviour of Command line Parameters and Qualifiers”). "Flag" indicates whether the flag (parameter or qualifier name) must be given on the command line. "Prompt" indicates whether a value will be prompted for if one is not specified on the command line. Additional qualifiers will only be prompted for if -options is specified. "Help" indicates where the information from the built-in -help qualifier is shown. For more information, see Section 4.5, “Controlling the Prompt”.

Any data definitions in an ACD file must be contained within an appropriate section and given in the correct order. The sections must appear in this order:

Subsections with arbitrary names can also be defined. They can appear in any order but must be nested in a major section.

Sections and subsections have the following general syntax:

section: SectionName 
[
  information: "SectionName section"
  type: "page"
]
.
. (data definitions go here)
.
   section: NestedSectionName 
   [
   information: "NestedSectionName section"
   type: "page"
   ]
   .
   . (data definitions go here)
   .
   endsection: NestedSectionName
.
endsection: SectionName

For example:

section: input 
[
  information: "Input section"
  type: "page"
]
.
. (input data definitions go here)
.
   section: inputsubsection 
   [
   information: "Input sub-section"
   type: "page"
   ]
.
. (input sub-section data definitions go here)
.
endsection: inputsubsection

endsection: input

The section contents is summarised in the table (Table A.3, “ACD File Sections”).