TDF Specification, Issue 4.0

January 1998

3. Describing the Structure

The following examples show how TDF constructs are described in this document. The first is the construct floating:

	fv:		FLOATING_VARIETY
		   -> SHAPE

The constructs' arguments (one in this case) precede the "->" and the result follows it. Each argument is shown as follows:

	name:	 	SORT

The name standing before the colon is for use in the accompanying English description within the specification. It has no other significance.

The example given above indicates that floating takes one argument. This argument, v, is of SORT FLOATING_VARIETY. After the "->" comes the SORT of the result of floating. It is a SHAPE.

In the case of floating the formal description supplies the syntax and the accompanying English text supplies the semantics. However, in the case of some constructs it is convenient to specify more information in the formal section. For example, the specification of the construct floating_negate not only states that it has an EXP argument and an EXP result:

	flpt_err:	 ERROR_TREATMENT
	arg1:		EXP FLOATING(f)
		   -> EXP FLOATING(f)

it also supplies additional information about those EXPs. It specifies that these expressions will be floating point numbers of the same kind.

Some construct's arguments are optional. This is denoted as follows (from apply_proc):

	result_shape:	SHAPE
	p:		EXP PROC
	params:		LIST(EXP)
	var_param:	OPTION(EXP)
		   -> EXP result_shape

var_param is an optional argument to the apply_proc construct shown above.

Some constructs take a varying number of arguments. params in the above construct is an example. These are denoted by LIST. There is a similar construction, SLIST, which differs only in having a different encoding.

Some constructs' results are governed by the values of their arguments. This is denoted by the "?" formation shown in the specification of the case construct shown below:

	exhaustive:	BOOL
	control:	EXP INTEGER(v)
	branches:	LIST(CASELIM)
		   -> EXP (exhaustive ? BOTTOM : TOP)

If exhaustive is true, the resulting EXP has the SHAPE BOTTOM: otherwise it is TOP.

Depending on a TDF-processing tool's purpose, not all of some constructs' arguments need necessarily be processed. For instance, installers do not need to process one of the arguments of the x_cond constructs (where x stands for a SORT, e.g. exp_cond. Secondly, standard tools might want to ignore embedded fragments of TDF adhering to some private standard. In these cases it is desirable for tools to be able to skip the irrelevant pieces of TDF. BITSTREAMs and BYTESTREAMs are formations which permit this. In the encoding they are prefaced with information about their length.

Some constructs' arguments are defined as being BITSTREAMs or BYTESTREAMs, even though the constructs specify them to be of a particular SORT. In these cases the argument's SORT is denoted as, for example, BITSTREAM FLOATING_VARIETY. This construct must have a FLOATING_VARIETY argument, but certain TDF-processing tools may benefit from being able to skip past the argument (which might itself be a very large piece of TDF) without having to read its content.

The nature of the UNITs in a GROUP is determined by unit identifications. These occur in make_capsule. The values used for unit identifications are specified in the text as follows:

Unit identification: some_name

where some_name might be tokdec, tokdef etc.

The kinds of linkable entity used are determined by linkable entity identifications. These occur in make_capsule. The values used for linkable entity identification are specified in the text as follows:

Linkable entity identification: some_name

where some_name might be tag, token etc.

The bit encodings are also specified in this document. The details are given in The bit encoding of TDF. This section describes the encoding in terms of information given with the descriptions of the SORTs and constructs.

With each SORT the number of bits used to encode the constructs is given in the following form:

Number of encoding bits: n

This number may be zero; if so the encoding is non-extendable. If it is non-zero the encoding may be extendable or non-extendable. This is specified in the following form:

Is coding extendable: yes/no

With each construct the number used to encode it is given in the following form:

Encoding number: n

If the number of encoding bits is zero, n will be zero.

There may be a requirement that a component of a construct should start on a byte boundary in the encoding. This is denoted by inserting BYTE_ALIGN before the component SORT.