DAP4: Overview

From OPeNDAP Documentation
⧼opendap2-jumptonavigation⧽

DAP4 is the result of a three year effort by OPeNDAP and Unidata. When we started the DAP4 project there were a number of goals we had in mind, but none was more pressing than that the utility of DAP2 be extended by making it easier to build servers and clients that would be interoperable. This would make the effort spent n developing those tools more rewarding and less risky.

In many ways DAP4 is an extension of ideas already present in DAP2 or ideas that were introduced into DAP2 in the 10+ years that the protocol underwent evolution as its use spread within the Earth Sciences community. Most developers will find that adapting existing software that implements DAP2 to support DAP4 also is easy.

In this overview of DAP4, we highlight the important differences between DAP2 and DAP4. The information here should be useful to developers and to users. For developers this will provide a roadmap to changes they will have to make to support DAP4, including information about changes to the data model, response format, and content. For example, the Grid data type has been extended to support a more general notion of discrete functions, one that is very similar to the ODG's idea of a coverage or a scientific data type in the Common Data Model (CDM) developed by Unidata. For users it will provide information about new capabilities to look for in DAP4 clients. For example, all DAP4 servers will return checksums with every data access operation but different clients will provide those in different ways. Neither of these differences affects the underlying nature of DAP (2 or 4) which is that data values are accessed using subsetting operations in a way that shields the user from the idiosyncrasies of particular data formats or storage devices.

How the DAP4 Protocol is Specified

The DAP4 specification is provided in two volumes: One that describes the Data Model and Request/Response objects; and one that describes how DAP4 servers use HTTP and the existing web infrastructure. In addition, additional volumes that describe extensions to DAP4 will be supported. Planned extensions will cover a JSON encoding for DAP4 metadata and data and the operation of server processing operations. The division of the DAP4 specification into these separate documents makes it simpler to see how the data access operations that are central to DAP4 are separate from the network transfer protocol. By formalized this separation, we have paved the way for DAP4 extension documents to describe how the protocol might be used with other transport protocols. The extensions documents provide a way for developers to continue the evolution of the protocol without the expense and complexity of yet another protocol development project.

DAP4 and Data Access

Data Model

The DAP4 data model is

  • Metadata in one response
  • Data model: Coverages, Groups, 64-bit integers, other types
  • Checksums for all data responses
  • Encoding of data responses
    • Reader makes right
    • reliable error delivery while returning data
  • Constraints
    • Subsetting coverages
    • Filters are per variable
  • DSR: per-dataset capabilities document; fixes an inconsistency when a 'bare URL' is dereferenced
  • Asynchronous behavior

How DAP4 Works with HTTP

  • Web services
    • Defines how the protocol is used with HTTP --> implies that we've thought explicitly about using it with other protocols
    • Alternate media types - content negotiation
    • DSR --> HATEOS