The dataset attribute structure (DAS) and dataset descriptor structure (DDS) objects are used to store information about a data set's variables. These objects are used on both the client and server sides, although there are class features that only pertain to one or another of the roles. They can be thought of as metadata objects. In this book, however, we will avoid the term metadata because often this is data to many users.
It might be said that neither the DAS nor the DDS contain actual science data -- the DAS contains attribute information from the data set while the DDS contains structural information about the data set and variables in the data set. Since the boundary between data and metadata (or data attributes) is often a blurry one, this is not a distinction we will insist on.
To build both the DAS and DDS, the server either reads information directly from the dataset or from DODS-specific ancillary data files, depending on the capabilities of the data access API used to access the data. The DAS and DDS server filter programs do this and then transmit the resulting object to the client.
On the client side, the DODS client2 uses information in the DAS and DDS to satisfy API calls issued by the user program requesting information about variables, their type, shape, and attributes. The client requests both of these objects when it first contacts the remote data set. The DAS and DDS objects are then stored as part of a virtual connection to that data set and can be used repeatedly by the client library without retransmission.
The DAS and DDS objects have both an internal and an external representation. Internal to the DODS client or server, these structures are stored as C++ objects, while their external representation is as text. The object is sent from the server to the client using this text representation. Each of the two classes contains a parser which can read the text representation and recreate the object's internal representation. In addition, it is possible to write the text representation for either object (using a text editor) and then use the parser to create the internal, C++, object. Furthermore, the text representation is a type of persistence and can be used to build a flexible object caching mechanism.
One possible use for this caching mechanism is to store the DAS and DDS for a dataset and use the stored versions in place of opening the data set and reading information about it and its contents. For large data sets with many variables this can result in a significant performance improvement, and several of the packaged DODS servers use it.
The caching mechanism may also be used on the server-side to store extra information about the data set--information that is not present in the data set proper, but which the data provider would like included when people access the data set via DODS. In this scenario, the data server first integrates the data set file(s) using the API and builds the DAS and DDS. Once an initial version of the DAS and DDS are resident in memory, the parser is used to read an external text file which contains additions to, or corrections of, the information extracted from the data file. This information is the ancillary data introduced above. Several of the DODS servers use this mechanism.