Rev 2 | Blame | Compare with Previous | Last modification | View Log | RSS feed
<!-- Crown Copyright (c) 1998 -->
<HTML>
<HEAD>
<TITLE>Describing the Structure</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
<H1><A NAME=S9>TDF Specification, Issue 4.0</A></H1>
<H3>January 1998</H3>
<A HREF="spec7.html"><IMG SRC="../images/next.gif" ALT="next section"></A>
<A HREF="spec5.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
<A HREF="spec1.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
</A>
<A HREF="spec12.html"><IMG SRC="../images/index.gif" ALT="document index"></A>
<P>
<HR>
<H1>3. Describing the Structure</H1>
<A NAME=M1>The following examples show how TDF constructs are described
in this document. The first is the construct
<A HREF="spec8.html#M282"><I>floating</I></A>:
<PRE>
<I>fv</I>: FLOATING_VARIETY
-> SHAPE
</PRE>
<A NAME=M2>The constructs' arguments (one in this case) precede the
"<I>-></I>" and the result follows it. Each argument
is shown as follows:
<PRE>
<I>name</I>: SORT
</PRE>
The name standing before the colon is for use in the accompanying
English description within the specification. It has no other significance.
<P>
The example given above indicates that <I>floating</I> takes one argument.
This argument, <I>v</I>, is of <CODE>SORT FLOATING_VARIETY</CODE>.
After the "<CODE>-></CODE>" comes the <CODE>SORT</CODE>
of the result of <I>floating</I>. It is a <CODE>SHAPE</CODE>.
<P>
In the case of <I>floating</I> 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
<A HREF="spec8.html#M116"><I>floating_negate</I></A>
not only states that it has an <CODE>EXP</CODE> argument and an <CODE>EXP</CODE>
result:
<PRE>
<I>flpt_err</I>: ERROR_TREATMENT
<I>arg1</I>: EXP FLOATING(<I>f</I>)
-> EXP FLOATING(<I>f</I>)
</PRE>
it also supplies additional information about those <CODE>EXP</CODE>s.
It specifies that these expressions will be floating point numbers
of the same kind.
<P>
<A NAME=M3>Some construct's arguments are optional. This is denoted
as follows (from <A HREF="spec8.html#M80"><I>apply_proc</I></A>):
<PRE>
<I>result_shape</I>: SHAPE
<I>p</I>: EXP PROC
<I>params</I>: LIST(EXP)
<I>var_param</I>: OPTION(EXP)
-> EXP <I>result_shape</I>
</PRE>
<I>var_param</I> is an optional argument to the <I>apply_proc</I>
construct shown above.
<P>
<A NAME=M4>Some constructs take a varying number of arguments.
<I>params</I> in the above construct is an example. These are denoted
by <CODE>LIST</CODE>. There is a similar construction, <CODE>SLIST</CODE>,
which differs only in having a different encoding.
<P>
Some constructs' results are governed by the values of their arguments.
This is denoted by the "<CODE>?</CODE>" formation shown
in the specification of the <A HREF="spec8.html#M89"><I>case</I></A>
construct shown below:
<PRE>
<I>exhaustive</I>: BOOL
<I>control</I>: EXP INTEGER(<I>v</I>)
<I>branches</I>: LIST(CASELIM)
-> EXP (<I>exhaustive</I> ? BOTTOM : TOP)
</PRE>
If <I>exhaustive</I> is true, the resulting <CODE>EXP</CODE> has the
<CODE>SHAPE BOTTOM</CODE>: otherwise it is <CODE>TOP</CODE>.
<P>
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 <I>x_cond</I> constructs
(where <I>x</I> stands for a <CODE>SORT</CODE>, e.g.
<A HREF="spec8.html#M75"><I>exp_cond</I></A>. 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. <CODE>BITSTREAM</CODE>s and
<CODE>BYTESTREAM</CODE>s are formations which permit this. In the
encoding they are prefaced with information about their length.
<P>
Some constructs' arguments are defined as being <CODE>BITSTREAM</CODE>s
or <CODE>BYTESTREAM</CODE>s, even though the constructs specify them
to be of a particular <CODE>SORT</CODE>. In these cases the argument's
<CODE>SORT</CODE> is denoted as, for example, <CODE>BITSTREAM FLOATING_VARIETY
</CODE>. This construct must have a
<CODE>FLOATING_VARIETY</CODE> 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.
<P>
The nature of the <CODE>UNIT</CODE>s in a <CODE>GROUP</CODE> is determined
by unit identifications. These occur in <I>make_capsule</I>. The values
used for unit identifications are specified in the text as follows:
<BLOCKQUOTE>
<B>Unit identification</B>: <I><A NAME=M5><A NAME=M6>some_name</I>
</BLOCKQUOTE>
where <I>some_name</I> might be <I>tokdec</I>, <I>tokdef</I> etc.
<P>
The kinds of linkable entity used are determined by linkable entity
identifications. These occur in <I>make_capsule</I>. The values used
for linkable entity identification are specified in the text as follows:
<BLOCKQUOTE>
<B>Linkable entity identification</B>: <I><A NAME=M7><A NAME=M8>some_name</I>
</BLOCKQUOTE>
where <I>some_name</I> might be <I>tag</I>, <I>token</I> etc.
<P>
The bit encodings are also specified in this document. The details
are given in <A HREF="spec11.html#0">The bit encoding of TDF</A>.
This section describes the encoding in terms of information given
with the descriptions of the <CODE>SORT</CODE>s and constructs.
<P>
With each <CODE>SORT</CODE> the number of bits used to encode the
constructs is given in the following form:
<BLOCKQUOTE>
<B>Number of encoding bits</B>: <I><A NAME=M9>n</I>
</BLOCKQUOTE>
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:
<BLOCKQUOTE>
<B>Is coding extendable</B>: <A NAME=M10><A NAME=M11>yes/no
</BLOCKQUOTE>
With each construct the number used to encode it is given in the following
form:
<BLOCKQUOTE>
<B>Encoding number</B>: <I><A NAME=M12>n</I>
</BLOCKQUOTE>
If the number of encoding bits is zero, <I>n</I> will be zero.
<P>
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
<A NAME=M13><CODE>BYTE_ALIGN</CODE> before the component
<CODE>SORT</CODE>.
<P>
<HR>
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
Copyright © 1998.</I></P>
</BODY>
</HTML>