Discovery Change Proposal-2

[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]

DCP-2: Canonicalizing Granule-level OPeNDAP Links

• Progress (fill in the dates as the process moves forward)

1. Submitted on: 15 June 2011
2. Review period: the review period
3. Revision: when revisions are being made based on feedback
4. Vote: the voting period
5. Final review: when final adjustments are being made and final review
6. Ratified: when approved.
7. Rejected: or when rejected.

• Facilitator: the primary editor to help the DCP move along the process.

Description

This DCP proposes a way to canonicalize how <link> elements can be identified as granule-level OPeNDAP URLs.

Problem Addressed

This allows clients to unambiguously distinguish OPeNDAP URLs from simple download URLs, without relying on parsing the path of the URL pattern for telltale strings like "dodsC". (These paths can vary with implementation and with deployment site and are thus unreliable). The restriction of the Root OPeNDAP URL allows the client to distinguish between, say, an HDF file that is downloaded in a netCDF response, vs. a NetCDF file that is served by the OPeNDAP. The former case, the URL in the Atom response will end in HDF (with possible suffixes for compression), e.g., http://disc2.nascom.nasa.gov/opendap/TRMM_3Hourly_3B42/2011/001/3B42.110101.12.6A.HDF.Z, while the latter case will end in .nc.

Proposed Solution

1. The rel attribute for link elements in the Atom or RSS response should unambiguously identify OPeNDAP end points for the individual granule at a granule level. The rel attribute value to indicate this shall be http://xml.opendap.org/ns/DAP/3.3# to indicate compliance with version 3.3 of the DAP specification. Servers compatible with other versions of DAP should substitute the appropriate version in the URL. (Note, these URIs are not dereferencible.)
2. OPeNDAP URLs shall be construed to point to the "root" URL, i.e., without any specific response suffix (.html, .asc, .nc, .dds, .das, .ddx, etc.).

Rationale for the Solution

This solution follows the pattern already used in ESIP Federated search to use a rel attribute with an unambiguous namespace URI to identify a specific kind of link.

Discussions

Talk:Discovery_Change_Proposal-2

Consensus

Voting results: TBD