[RFC-004]Comment-18

Organization: SCCWRP

Attached is my review of the DAP 2 specs. I'd like to add that we have had nothing but good experiences with the NVODS community. They have always provided positive, timely support for our efforts. Most of our challenges have been solved in hours as opposed to weeks. They community is populated with technical wizards that provide assistance in an understandable way.

==========================================================================

Review of DAP2 specification

NASA's Earth Science Data Systems Standards Process Group (SPG) is considering the Data Access Protocol, Version 2, (DAP2) for adoption as a community standard. You are invited to review the DAP2 Request For Comment (RFC) (see review questions below).

Please send comments before November 12, 2004 to ese–rfc–004@spg.gsfc.nasa.gov

(Your background)

My agency has used the specification to both make data available from a server environment and to develop client software to use the data provided through the server. We have used it to transfer both physical oceanographic measures from CTD instruments and bacterial measures.

(Complete) Does the specification provide all the detail you need to implement it in software?

The specification is very complete and we were able to implement it without much difficulty. The few times that we needed additional assistance, the DODS community readily supplied it.

(Accurate) Do any parts of the specification contain inaccuracies, or internal inconsistencies?

At the time this specification was published, there was not a uniform way to handle time values and we had to work around that. Since the release of this version, that problem has be resolved.

(Clear) Is any part of the specification ambiguous, or poorly explained?

The specification provides both clear explanations and good examples for the files required to implement the protocol.

(Balanced) Does the standard describe the right set of concepts, behavior, data types, and data operations for its intended users?

The protocol deals with the four most prevalent representations including grids, sequences, structures and arrays. In our case, structures were the representation of our data. We had no problems with it after the time issue was resolved.

(Useful) How well does this specification meet your information sharing needs? (e.g., Does it work well with the data types and data manipulations in your application? Does it improve on alternative methods, such as file exchange or proprietary software?)

The specification works very well for us. Once the server was set up to use the protocol, it has not needed any maintenance what so ever. We were able to bring in data to our client from the three desired servers in our system and the data appeared seamless in our client software.

(Implementable) What implementation challenges does the proposed standard present? (e.g., Does it require advanced processing power, large amounts of memory, complex configuration, etc.? Does it scale to a production environment?)

Our implementation serves up five years of water column measurements for ten variables. The only technical limitation we have encountered has been related to band width available between the client and servers. It has sometimes taken as long as 20 minutes to refresh a portion of the data from a server, but the connection that we had was a DSL line, so it is somewhat less than optimal. Even this did not provide an impediment to the protocols usefulness to us. We simply have the datasets refreshed over night.