[Esip-discovery] DCP-2 Review period closed, sort of
jgallagher at opendap.org
Mon Jul 11 15:59:40 EDT 2011
On Jul 8, 2011, at 2:06 PM, Lynnes, Christopher S. (GSFC-6102) wrote:
> On Jul 8, 2011, at 3:25 PM, Hua, Hook (388C) wrote:
>> Hi Chris,
>> Before you close it, I have a few comments:
>> (1) It's interesting to see that the baseline rel links are categorical:
>> http://esipfed.org/ns/discovery/1.1/data# Default data link. Data Casting Granules. OpenSearch Granules response.
>> http://esipfed.org/ns/discovery/1.1/browse# Appropriate for smaller browse images. See following for alternate browse links.
>> http://esipfed.org/ns/discovery/1.1/documentation# Default documentation. See following for alternate documentation links.
>> http://esipfed.org/ns/discovery/1.1/metadata# Data, collection, and service metadata.
>> http://esipfed.org/ns/discovery/1.1/collection# Data Casting Collection. Not for OpenSearch Collection response which uses OSDD instead.
>> http://esipfed.org/ns/discovery/1.1/service# Service Casting.
>> http://esipfed.org/ns/discovery/1.1/event# Micro-articles of natural phenomenon.
>> http://esipfed.org/ns/discovery/1.1/feed# Feed of various feeds. Enables hierarchy of feeds.
>> But the OPeNDAP rel can be considered an "instance" of rel=http://esipfed.org/ns/discovery/1.1/data#.
> It's not exactly an instance. It is really a subclass. I say subclass because in fact there are several different possible OPeNDAP URLs that could be specified, one for each response type. Alternatively, there are several different OPeNDAP implementations. Although they theoretically follow the same protocol, their capabilities are different, so that a client might find some use in subdividing the different OPeNDAPs. For now, though, I thought the one URL was sufficient.
> Also, the OPeNDAP URL in the Atom response is not the *actual* URL you would use to interact with the data, just the root. Or file-specific service endpoint if you prefer. See answer to #3 below.
>> (2) Should we specify that the OPeNDAP rel links are optional?
> Yes, I will add that to the spec.
>> That way clients conforming to the spec that do not support OPeNDAP URLs can safely ignore it.
>> (3) In the baseline spec, we had included a attributes "rel" link and "type" for mime-types. Should we specify corresponding mime-types for these OPeNDAP URLs?
> Um, we can't really do that. When you get an OPeNDAP URL, you actually get a whole group of related URLs. The root URL, if acquired, sends back the original data file with corresponding mime type. If it is HDF, it comes back as application/hdf. Add on a .nc suffix and you get a netcdf file of type 'application/octet-stream', though it should really be 'application/x-netcdf'. Add on a .das suffix, and you get text/plain. A .ddx suffix gets you 'text/xml'. And so on.
I have to say that this aspect of the protocol (DAP) has always been something I was not happy with. But it's correct that the 'DAP URL' is really the base URL to a family of responses. A more restful approach would return a document with links to the different response types, at least I think so...
>> From: esip-discovery-bounces at lists.esipfed.org [esip-discovery-bounces at lists.esipfed.org] On Behalf Of Lynnes, Christopher S. (GSFC-6102) [christopher.s.lynnes at nasa.gov]
>> Sent: Friday, July 08, 2011 11:47 AM
>> To: esip-discovery at lists.esipfed.org
>> Subject: [Esip-discovery] DCP-2 Review period closed, sort of
>> Hey folks, review period for DCP-2, Canonicalizing OPeNDAP URLs, closed yesterday, with no comments. However, if anyone has any serious heartburn with it, I'll extend the review period to COB Monday, July 11.
>> The proposal is here: http://wiki.esipfed.org/index.php/Discovery_Change_Proposal-2
>> Dr. Christopher Lynnes NASA/GSFC, Code 610.2 phone: 301-614-5185
>> Esip-discovery mailing list
>> Esip-discovery at lists.esipfed.org
> Dr. Christopher Lynnes NASA/GSFC, Code 610.2 phone: 301-614-5185
> Esip-discovery mailing list
> Esip-discovery at lists.esipfed.org
More information about the Esip-discovery