fferent 
a base 
idjust- 
eoTeX 
ndjust- 
Then, 
neters, 
called 
ucture 
xpres- 
The 
(1) 
neters 
nents, 
, etc.), 
ax pi 
sense 
ticular 
a type 
(2) 
meter, 
ber, $1 
oordi- 
Last, 
nce of 
5. (3) 
1 look 
(4) 
eter is 
; (8) 
Cm 18 
follow 
T 
À 
3 used 
3, net- 
work abstract data types and network discrete mod- 
els. 
Data standards and some of their implications are 
discussed in Section 4.1. Note that data standards 
is à concept mainly related to data management and 
processing. 
Network abstract data types, either for a data base 
or for a program, deal again with management and 
processing. Actually, Section 3 deals with just a small 
part of the problem of defining a consistent and com- 
prehensive set of abstract data types for a network 
adjustment program. 
A network discrete model is, on the contrary, a 
pure mathematical concept. It is motivated and in- 
troduced in Section 4.3. 
4.1 Data standards, grammars and the Geo- 
TeX 1/O kernel 
A data standard is nothing but a set of formal 
rules describing the structure and meaning of data, 
that is, a language. Geodetic data, as many other 
types of data, may be expressed by means of a for- 
mal language. This is important from many stand- 
points: aesthetics, automatic language recognition, 
automatic code generation, etc. 
A language is defined by a grammar. Grammars 
are always formal and some of them can be automat- 
ically processed by a computer. In fact, it is possible 
to create a tool —a compiler-compiler— which, us- 
ing a formal description of a grammar G —i.e. a 
metalanguage— as input, generates software able to 
recognize text files written in G [1]. A well known 
commercial example of such tools is the Lex & Yacc 
package [13]. 
As discussed in Section 3 and also in Section 2, the 
formal structure of the observables, parameters, etc. 
may be represented by means of polymorphic abstract 
data types. An immediate —and very important— 
consequence of this fact is that only a single limited 
grammar is required to define the language describing 
those geodetic items. Thus, only couples of modules 
have to be coded for the reading and writing basic 
operations. 
The GeoTeX I/O kernel has been implemented 
following these principles. First of all, the AdIL 
grammar, which represents the formal geodetic data 
model, was defined. Then, a compiler-compiler tool, 
GDL, was developed. GDL uses that grammar to 
automatically generate the skeletons of the I/O mod- 
ules. At this point, the software is able to decide 
whether a text is written in AdIL or not (that is, to 
decide if that text is syntactically correct).? Finally, 
  
3Note that the tools known as compiler-compilers are only 
able to generate the syntactical parsers. That means that the 
659 
  
  
  
  
  
  
G.co Te X applications 
OPT*** ERR*** 
modules AdIL** modules modules 
  
  
  
  
  
  
  
OPT OPT  DLB FLB AdUL AdiL ELB  ELB 
  
  
  
Figure 1: GeoTeX I/O kernel. 
all the semantic procedures were coded. 
Specifically, the GeoTeX I / O kernel is composed 
of: 
e À descriptor library (DLB), used to describe 
the particularities of the observables, parame- 
ters, sensors and constraints. One record —a 
descriptor— is stored in this file for each single 
instance of those geodetic elements. 
* AdIL** modules. The GeoTeX I/O kernel con- 
sists of couples of modules (which are used to 
read and write the observables, etc.). The out- 
put modules also use a format library (FLB), cre- 
ated and tailored by the user, to write the output 
AdIL files according to the user's preferences. 
These previous components have been specifically 
designed for the GeoTeX system. Additionally, other 
general input/output subsystems, shared by many 
other applications of the ICC, are used. Exactly 
the same rationale —formal grammars, abstract data 
types and automatic code generation— can be and 
has been applied to these types of data —not only to 
geodetic. 
The additional general I/O subsystems are: 
eo OPT*** modules (OPT grammar). These two 
modules are used to read and write the “run op- 
tion files” (that is, the set of options controlling 
the behavior of a program). 
  
modules created in this way can only recognize whether a text 
is written according to a grammar or not. The semantic pro- 
cess of the information contained in the input file has to be 
implemented manually. Nevertheless, the syntactical recogni- 
tion of a text is a hard problem to solve, so the availability of 
those tools is of a great help. 
The difference between syntactical and semantic processes 
is shown by the following example: if 182.4527 is a string of 
characters representing an angular magnitude, the syntacti- 
cal process of such a string would check whether the format 
DDD.MMSS is used or not; the semantic treatment would 
transform, for instance, this magnitude from gons to radians.