OPULS Development

OPULS Process

Design Proposal Process

DAP4 Features

This is a straw man design, broken down into sections. It is incomplete and its content is subject to revision.

1. Versions
2. Checksum
3. DAP Service Terminus
4. Data Model and a XML Schema that provides one representation for the data model.
5. Requests
6. Responses
7. Web Services

Proposals

DAP4 Data Model Proposals

Proposal	Status	Author	Date Proposed
Grids Ideas	Accepted	Dennis, et al.	(Cleaned up 4/10/2012)
Old Version of Grids Proposal	Obsolete	Dennis	4/10/2012
XML Use in DAP4	Accepted	Dennis	2/25/2012
Constraints and Shared Dimensions	Under Review, closely related to Grids Ideas	James & Dennis	Modified 04/12/2012
Ideas for Defining VLens (and Sequences)	Under Consideration	Dennis	02/25/2012
Path Specification in DAP4	New	Dennis	3/30/2012
Character Escape Mechanisms in DAP4	New	Dennis	4/5/2012
Asynchronous Responses	New	Nathan	4/5/2012
Coordinate Systems Element	New	Dennis	4/10/2012
DAP4 Capabilities and Versioning	New	EthanDavis	4/10/2012
DAP4 Asynchronous Request-Response Proposal	New	EthanDavis	4/10/2012
Nested Attributes	New	Dennis	4/12/2012
Top Level Group	New	Dennis	4/12/2012

Other Proposals

Proposal	Status	Author	Date Proposed
Proposed DAP4 On-The-Wire Format	New	Dennis	4/8/2012
Possible Notation for Server Commands	New	Dennis	Modified 04/12/2012
DAP4 DDX Grammar	New	Dennis
DAP4: DDX Lexical Elements	New	Dennis	2/28/2012

Commentary on DAP4 Related Topics

These are not intended as specific proposal, but rather as commentary on some issues with DAP4 that need addressing with specific proposals.

1. Characterization of URL Annotations (Modified: 2/26/2012)
2. Constructing a DDX from a Query (new: 04/12/2012)

OPULS Implementation Thoughts

Unidata's Current Thoughts

Unidata needs:

 1) DAP4 C client library for use in netCDF-C library
 2) DAP4 Java client library for use in netCDF-Java library
 3) DAP4 Java server library for use in TDS
 4) Conformance test service against which a DAP4 client library can
    be tested
 5) Conformance test service against which a DAP4 server can be
    tested

The current CDM and TDS use of opendap-java library has performance problems due to extra API layers and extra copying of data. We would prefer direct serialization between CDM objects and the DAP on-the-wire data and would recommend that the OPeNDAP Java library leverage the netCDF-Java libraries.

If there are needs that the DAP4 opendap-java library be independent of the netCDF-Java library, then in order for CDM and TDS to use the opendap-java library, we would need the performance concerns mentioned above addressed. A reasonable metric would be within some percentage of cdmremote[1], say within 20-25%.

Unidata's performance requirements for Java libraries:

 1) The netCDF-Java library performance reading DAP4 through the DAP4
    Java client library must perform within 20-25% of cdmremote [1].
 2) TDS performance when handling DAP4 requests using the DAP4 Java
    server library should perform within 20-25% of cdmremote [1].

We believe this means that the DAP4 Java libraries must provide a sufficiently generic API that can be used directly with the CDM/TDS IOSP interface.

Unidata will:

 1) Write the DAP4 C client library.
 2) ??? some part of Java server library
 3) ??? some parts of conformance testing services

NOTES:

[1] cdmremote is an experimental CDM streaming service. It is basically a direct serialization of the CDM.

OPULS references

• http://www.mnot.net/blog/2011/10/25/web_api_versioning_smackdown

Old DAP4 Design and Implementation

• DAP3/4
• DAP 4.0 Design and DAP 4.0 Essential Features The design is meant to be a complete document while essential features are the minimal see we want to release. Since this task has been stalled for nearly a year, doing the latter seems like a noble goal.