Subject: ODL and ASN.1

From: leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman)
Date: Tue, 30 Jun 1992 21:58:57 GMT

Bob Hill asked me a question about ODL and ASN.1 and the answer got just
preachy enough that I think I might just as well post it here as well.  :-)

> In article <leb.709920119 at Hypatia>, you write...
> >data description languages out there, Object Description Language (ODL) and
> >Abstract Syntax Notation 1 (ASN.1), just to name two.  Perhaps the scientists
> 
> Lee,
> 
> Do you have any references for these?  Maybe one reference that discusses
> both concisely?
> 
>  - Bob Hill
> 

ODL is used by the Planetary Data System to describe all of the data they are
distributing on CD-ROM. (I think they were calling it 'PDL' for a while. I can't
remember what the 'P' stood for but I don't think it was planetary.)  ODL is
also an integral part of the Standard Formatted Data Unit (SFDU) Red Book
standards put out by NASA and a bunch of other international space agencies.
You should be able to get at least the Red Book standards from the NASA Office
of Standards and Technology (NOST) at NSSDC.  Try sending E-mail to ncf::nost.

ASN.1 is an Open System Interconnection (OSI) standard, document ISO 8824.  I
learned about it my last networking class at Johns Hopkins.  It is used to
precisely describe the formats of the Protocol Data Units (i.e. packets)
shipped around in OSI networks.  Even the TCP/IP guys have started using it to
define the structures of the TCP and IP packets.  

Basically you have an "abstract syntax" which describes the data stream in
a notation vaguely like Pascal.  Then the abstract syntax is "interpreted" into
a "transfer syntax" which specifies the bit stream to be transmitted.  An
example from my text book goes like this...

Given a structure like:   
< Pascal >                               < C >
type dinosaur = record                    struct dinosaur {
     name: array [1..12] of character;        char name[12];
     length: integer;                         int  length;
     carnivorous: boolean;                    int  carnivorous;
     bones: integer;                          int  bones;
     discovery: integer;                      int discovery;
end;                                      }

The ASN.1 abstract syntax would be:

Dinosaur ::= SEQUENCE {
     name        OCTET STRING, -- 12 characters
     length      INTEGER,
     carnivorous BOOLEAN,
     bones       INTEGER,
     discovery   INTEGER
}

Primitive data types are indicated with all upper case characters.  It is also
possible to define your own data types which are formed from primitive types.
Note that the comment following the "--" is just that, a comment.  The length
of the name of the dinosaur is not encoded (if you think about it, there's
just no need to have to specify the maximum length of the dinosaurs name,
and there is quite a bit of variation anyway, so it's best to leave it open.)

When the ASN.1 abstract syntax is encoded for transmission, each of the fields
is translated into a type-length-value bytestream.  The type is a single octet
which is split into: (a) 2 bits to denote whether the data type is universal
(i.e. predefined), application, context-specific, or private; (b) 1 bit to
denote whether the type is constructed or primitive (all the types in the
example above are primitive); and (c) 5 bits for the type code.  Provisions are
made for type fields larger than one octet.  The length is however many bytes
it takes to give the length of the field, and the data for the field
immediately follow the length.  There is an optional end-of-contents flag if
the length of the data object is unknown.

The above example, when given the value { "stegosaurus", 10, FALSE, 300, 1877 }
encodes into the following byte stream (all numbers are in hexidecimal):

ASN.1            Type   Length   Value

SEQUENCE          40      1B    (The value is the object describing a dinosaur)
OCTET STRING      04      0B    73 74 65 67 6F 73 61 75 72 75 73
				"stegosaurus" in ISO 646 (ASCII)
INTEGER           02      01    0A     = 10 decimal
BOOLEAN           01      01    00     = FALSE
INTEGER           02      02    2C 01  = 300 decimal (little-endian)
INTEGER           02      02    55 07  = 1877 decimal

Or, all together: 40 1B 04 0B 73 74 65 67 6F 73 61 75 72 75 73
                  02 01 0A 01 01 00 02 02 2C 01 02 02 55 07 

I may have a few bits wrong here or there -- that's why God gave us computers
to figure this crap out!

I think that ODL is probably the most used abstract object description language
in the NASA environment, given the scads of data from the planetary, space and
earth science folks (note that no discipline other than astronomy uses FITS, we 
are truly alone).  When OSI is thrust down our throats in the form of GOSIP, I
think we'll be seeing a lot about ASN.1 (or ASN.2, whatever is coming down the
pike).  The main thing about ASN.1 is that it has a whole pile of money and
politics pushing it along.

Now, was that answer long-winded enough?  :-)

-- 
-- Lee E. Brotzman                    Internet:  leb at hypatia.gsfc.nasa.gov
-- Hughes STX                         DECNET:    NDADSA::BROTZMAN
-- National Space Science Data Center BITNET:    ZMLEB at SCFMVS
-- NASA Goddard Space Flight Center

--
-- Lee E. Brotzman                    Internet:  leb at hypatia.gsfc.nasa.gov
-- Hughes STX                         DECNET:    NDADSA::BROTZMAN
-- National Space Science Data Center BITNET:    ZMLEB at SCFMVS
-- NASA Goddard Space Flight Center

---

From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Date: 30 Jun 92 22:46:00 GMT

In article <leb.709941537 at Hypatia>, leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman)
writes...

>define the structures of the TCP and IP packets.  

	(rest of message deleted to save space)

I think there may be some subtle distinctions between ODL as used by the PDS
and PVL (parameter-value language) as incorporated into SFDUs.  But they are
related; I believe PVL was inspired by ODL.  The "Object" in the name may be
slightly misleading.  Nowadays the term "objects" is used to refer not only the
structure of the data, but also the structure of the operations that can be
performed on the data.  The description of ASN.1 is described as resembling C
or Pascal structures.

I think that where the ASN.1 most naturally fits into FITS binary tables is to
consider that an entire binary table defines a structure, and that the records
(rows) of that database are instances of that structure.

The object-oriented software for this structure would have to sit on top of the
primitives that directly interact with the binary table.  Right now we seem to
be most concerned with getting the binary representation of the data correct so
that we can most efficiently build the higher level software that understands
complex objects.

Bill Thompson

---

From: cflatter at nrao.edu (Chris Flatters,208,7209,homephone)
Date: Tue, 30 Jun 1992 23:45:47 GMT

In article 709941537 at Hypatia, leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman) writes:
> ...

ASN.1 is intended to be used for the encoding of data for transmission over
a network connecting computers of different architectures (hence the stream
orientation).  It is similar to XDR save that information in an ASN.1 data
stream contains type tags while information in an XDR stream does not.  In both
cases a program reading the data needs to know what types of data to expect
in what order to be able to process the data stream (but an ASN.1 reader can
detect that it isn't getting the data it expects while an XDR reader will just
read garbage).

FITS files describe both the format of the data contained in them and supply
hints on how it is to be interpreted.  ASN.1 streams describe the data contained
in them but give no information on how that data is to be interpreted.

	Chris Flatters
	cflatter at nrao.edu