The DAP is a stateless protocol. Each of the DAP's entry points (i.e., the messages a data server will respond to) does a single isolated job and they can be issued in any order (although in many applications it will not make sense to get the values for a variable before finding out the name of the variable ...). The stateless nature of the DAP fits well within the context of the data delivery system described in DODS--Data Delivery Architecture. In that paper a client-server architecture for remote access is described which relies on the HTTPD/CGI mechanism to build a data server. One implementation of that architecture is described in DODS--Data Delivery Design uses three CGI modules, one of each of the three DAP entry points.
In this paper we talk about messages to the data server as if it is a stateful server like ftpd. However, that is merely a convient way to phrase the discussion of the DAP--in fact the data server is a stateless machine accessed by getting the value of a URL.
Each DODS data server must respond to three URLs; one for each of the objects (DAS, DDS and variable) which the server returns. These URLs are formed by appending a suffix to the base URL which references the data set. In addition, individual variables may be accessed using the constraint expression mechanism described here. The paper DODS--Uniform Resource Locator conatins more information on this scheme.
Two messages are provided to access the data set descriptor structure (DDS)
and the data set attribute structure (DAS). The response to these messages
is text formated using the respective grammars in
Tables ![[*]](file:/usr/share/latex2html/icons/crossref.png){kind=icon}
and . This text can then be parsed by the
caller to determine the structure of the data set, types and sizes of each of
its components and their attributes. These structures are derived both from
information contained in the data set and for ancillary information supplied
by the data set maintainers in separate text files (in the data delivery design the origin
of these structures is described in detail). They provide information that is
often referred to as `metadata' and may be cached by the client system.
Future accesses to the same data set can then skip the retrieval of these
structures.
All variables are read from a data set individually using a single `read' message. The message must include the name of the variable to read, and optionally, may include an expression that describes the range of values desired. No other information need be sent to the server. In response to this message the value(s) of the variable(s) is/are then sent back to the client. Base type variables return only a single value when accessed, but other types may return more values. For example, a structure with three int32 and two float64 members will return five values (unless an expression constrains the access).
One important capability of the DODS API, which it inherits from JGOFS, is the ability to set constraints on variables (JGOFS calls this `using selection and projection' operators). Constraints are used to control the values and/or members of constructor types that are returned when a variable is accessed. For some data sets and some variables, constraints make little or no difference in how the variables are accessed. However, for certain types of data, constraining access can vastly reduce the amount of data the application needs to process and, in DODS case, transmit over the network.
Constraint expressions provide more flexibility in the way data is accessed.
In a data set with many interrelated variables, or with very large variables,
these expressions are a way for the user program to move some of the complex
logic needed to search data, in order to find those data with some desired
set of properties, away from the user program and into the data supply
system. Different types of constraint expressions make sense for different
types of data. The grammar for constraint expressions is given in
Table . In the table Operator is one of the
variable-class dependent operators listed in Table ,
! is boolean not and & is boolean and.
