Subversion Repositories tendra.SVN

Rev

Details | Last modification | View Log | RSS feed

Rev Author Line No. Line
2 7u83 1 
<!-- Crown Copyright (c) 1998 -->
2 
<HTML>
3 
<HEAD>
4 
<TITLE>Describing the Structure</TITLE>
5 
</HEAD>
6 
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
7 
<H1><A NAME=S9>TDF Specification, Issue 4.0</A></H1>
8 
<H3>January 1998</H3>
9 
<A HREF="spec7.html"><IMG SRC="../images/next.gif" ALT="next section"></A>
10 
<A HREF="spec5.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
11 
<A HREF="spec1.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
12 
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
13 
</A>
14 
<A HREF="spec12.html"><IMG SRC="../images/index.gif" ALT="document index"></A>
15 
<P>
16 
<HR>
17 
<H1>3. Describing the Structure</H1>
18 
<A NAME=M1>The following examples show how TDF constructs are described
19 
in this document. The first is the construct
20 
<A HREF="spec8.html#M282"><I>floating</I></A>:
21 
<PRE>
22 
	<I>fv</I>:		FLOATING_VARIETY
23 
		   -&gt; SHAPE
24 
</PRE>
25 
<A NAME=M2>The constructs' arguments (one in this case) precede the
26 
&quot;<I>-&gt;</I>&quot; and the result follows it. Each argument
27 
is shown as follows:
28 
<PRE>
29 
	<I>name</I>:	 	SORT
30 
</PRE>
31 
The name standing before the colon is for use in the accompanying
32 
English description within the specification. It has no other significance.
33 
<P>
34 
The example given above indicates that <I>floating</I> takes one argument.
35 
This argument, <I>v</I>, is of <CODE>SORT FLOATING_VARIETY</CODE>.
36 
After the &quot;<CODE>-&gt;</CODE>&quot; comes the <CODE>SORT</CODE>
37 
of the result of <I>floating</I>. It is a <CODE>SHAPE</CODE>.
38 
<P>
39 
In the case of <I>floating</I> the formal description supplies the
40 
syntax and the accompanying English text supplies the semantics. However,
41 
in the case of some constructs it is convenient to specify more information
42 
in the formal section. For example, the specification of the construct
43 
<A HREF="spec8.html#M116"><I>floating_negate</I></A>
44 
not only states that it has an <CODE>EXP</CODE> argument and an <CODE>EXP</CODE>
45 
result:
46 
<PRE>
47 
	<I>flpt_err</I>:	 ERROR_TREATMENT
48 
	<I>arg1</I>:		EXP FLOATING(<I>f</I>)
49 
		   -&gt; EXP FLOATING(<I>f</I>)
50 
</PRE>
51 
it also supplies additional information about those <CODE>EXP</CODE>s.
52 
It specifies that these expressions will be floating point numbers
53 
of the same kind.
54 
<P>
55 
<A NAME=M3>Some construct's arguments are optional. This is denoted
56 
as follows (from <A HREF="spec8.html#M80"><I>apply_proc</I></A>):
57 
<PRE>
58 
	<I>result_shape</I>:	SHAPE
59 
	<I>p</I>:		EXP PROC
60 
	<I>params</I>:		LIST(EXP)
61 
	<I>var_param</I>:	OPTION(EXP)
62 
		   -&gt; EXP <I>result_shape</I>
63 
</PRE>
64 
<I>var_param</I> is an optional argument to the <I>apply_proc</I>
65 
construct shown above.
66 
<P>
67 
<A NAME=M4>Some constructs take a varying number of arguments.
68 
<I>params</I> in the above construct is an example. These are denoted
69 
by <CODE>LIST</CODE>. There is a similar construction, <CODE>SLIST</CODE>,
70 
which differs only in having a different encoding.
71 
<P>
72 
Some constructs' results are governed by the values of their arguments.
73 
This is denoted by the &quot;<CODE>?</CODE>&quot; formation shown
74 
in the specification of the <A HREF="spec8.html#M89"><I>case</I></A>
75 
construct shown below:
76 
<PRE>
77 
	<I>exhaustive</I>:	BOOL
78 
	<I>control</I>:	EXP INTEGER(<I>v</I>)
79 
	<I>branches</I>:	LIST(CASELIM)
80 
		   -&gt; EXP (<I>exhaustive</I> ? BOTTOM : TOP)
81 
</PRE>
82 
If <I>exhaustive</I> is true, the resulting <CODE>EXP</CODE> has the
83 
<CODE>SHAPE BOTTOM</CODE>: otherwise it is <CODE>TOP</CODE>.
84 
<P>
85 
Depending on a TDF-processing tool's purpose, not all of some constructs'
86 
arguments need necessarily be processed. For instance, installers
87 
do not need to process one of the arguments of the <I>x_cond</I> constructs
88 
(where <I>x</I> stands for a <CODE>SORT</CODE>, e.g.
89 
<A HREF="spec8.html#M75"><I>exp_cond</I></A>. Secondly, standard tools
90 
might want to ignore embedded fragments of TDF adhering to some private
91 
standard. In these cases it is desirable for tools to be able to skip
92 
the irrelevant pieces of TDF. <CODE>BITSTREAM</CODE>s and
93 
<CODE>BYTESTREAM</CODE>s are formations which permit this. In the
94 
encoding they are prefaced with information about their length.
95 
<P>
96 
Some constructs' arguments are defined as being <CODE>BITSTREAM</CODE>s
97 
or <CODE>BYTESTREAM</CODE>s, even though the constructs specify them
98 
to be of a particular <CODE>SORT</CODE>. In these cases the argument's
99 
<CODE>SORT</CODE> is denoted as, for example, <CODE>BITSTREAM FLOATING_VARIETY
100 
</CODE>.  This construct must have a
101 
<CODE>FLOATING_VARIETY</CODE> argument, but certain TDF-processing
102 
tools may benefit from being able to skip past the argument (which
103 
might itself be a very large piece of TDF) without having to read
104 
its content.
105 
<P>
106 
The nature of the <CODE>UNIT</CODE>s in a <CODE>GROUP</CODE> is determined
107 
by unit identifications. These occur in <I>make_capsule</I>. The values
108 
used for unit identifications are specified in the text as follows:
109 
<BLOCKQUOTE>
110 
<B>Unit identification</B>: <I><A NAME=M5><A NAME=M6>some_name</I>
111 
</BLOCKQUOTE>
112 
where <I>some_name</I> might be <I>tokdec</I>, <I>tokdef</I> etc.
113 
<P>
114 
The kinds of linkable entity used are determined by linkable entity
115 
identifications. These occur in <I>make_capsule</I>. The values used
116 
for linkable entity identification are specified in the text as follows:
117 
<BLOCKQUOTE>
118 
<B>Linkable entity identification</B>: <I><A NAME=M7><A NAME=M8>some_name</I>
119 
</BLOCKQUOTE>
120 
where <I>some_name</I> might be <I>tag</I>, <I>token</I> etc.
121 
<P>
122 
The bit encodings are also specified in this document. The details
123 
are given in <A HREF="spec11.html#0">The bit encoding of TDF</A>.
124 
This section describes the encoding in terms of information given
125 
with the descriptions of the <CODE>SORT</CODE>s and constructs.
126 
<P>
127 
With each <CODE>SORT</CODE> the number of bits used to encode the
128 
constructs is given in the following form:
129 
<BLOCKQUOTE>
130 
<B>Number of encoding bits</B>: <I><A NAME=M9>n</I>
131 
</BLOCKQUOTE>
132 
This number may be zero; if so the encoding is non-extendable. If
133 
it is non-zero the encoding may be extendable or non-extendable. This
134 
is specified in the following form:
135 
<BLOCKQUOTE>
136 
<B>Is coding extendable</B>: <A NAME=M10><A NAME=M11>yes/no
137 
</BLOCKQUOTE>
138 
With each construct the number used to encode it is given in the following
139 
form:
140 
<BLOCKQUOTE>
141 
<B>Encoding number</B>: <I><A NAME=M12>n</I>
142 
</BLOCKQUOTE>
143 
If the number of encoding bits is zero, <I>n</I> will be zero.
144 
<P>
145 
There may be a requirement that a component of a construct should
146 
start on a byte boundary in the encoding. This is denoted by inserting
147 
<A NAME=M13><CODE>BYTE_ALIGN</CODE> before the component
148 
<CODE>SORT</CODE>.
149 
<P>
150 
<HR>
151 
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
152 
Copyright &copy; 1998.</I></P>
153 
</BODY>
154 
</HTML>