[Esip-discovery] proposed mods for collection-level responses

[Steve Richard]

I like the idea of IANA registration as well. 

The current RFC for media type specification and registration procedures is
http://tools.ietf.org/html/rfc6838. 

 

Looks like the 'application/vnd.' tree makes sense. For the THREDDS,
OpenDAP, NetCDF world, is  Unidata the producer, or is the THREDDS server
the producer?

application/vnd.unidata or application/vnd.thredds

 

then it gets interesting. OpenDAP is a protocol, THREDDS is a server
implementation, NetCDF is a file format. (well, sort of .)  Which part of
this is the media type?  I copied the rfc6838 authors on this to see if they
have any suggestions.

 

>From 

http://docs.opendap.org/index.php/DAP4_Web_Services_v3

"The Data Service provides DAP4 data access to a dataset, and is the
(primary) way that DAP4 returns data to a client. The Data service accepts a
query string (constraint expression) which allows you to subset the data and
invoke server side functions. When the service is invoked it returns the
DAP4 data object. On the wire this is a binary document with MIME type
application/vnd.opendap.org.dap4.data."

 

application/x-netcdf has been used for NetCDF

 

Neither of these seems to be registered.

 

steve

 

> -----Original Message-----

> From: esip-discovery-bounces at lists.esipfed.org [mailto:esip-discovery-

> bounces at lists.esipfed.org] On Behalf Of Lynnes, Christopher S. (GSFC-6102)

> Sent: Saturday, February 09, 2013 6:43 AM

> To: Mattmann, Chris A

> Cc: <esip-discovery at lists.esipfed.org>

> Subject: Re: [Esip-discovery] proposed mods for collection-level responses

> 

. snip.

> 

> According to this, we should be using a vnd.<producer>.subtype, so perhaps
it

> would be:

> vnd.opendap.directory

> 

> Also, RFC 3023 lays out a policy of using '+xml' suffix for XML-based
mime-types,

> so we would have:

> vnd.unidata.thredds+xml

> Pending agreement with Unidata of course.

> 

> We could actually submit these for registration to IANA:

>  <http://www.iana.org/cgi-bin/mediatypes.pl>
http://www.iana.org/cgi-bin/mediatypes.pl

> 

> >

> > Or in general:

> >

> > <primary type [1 of 8]>/[extension denoted by x-]<sub

> > type>[-protocol][-ESIP Open Search type]

> >

> > Or did I guess it wrong?

> >

> > Cheers,

> > Chris

> >

> > On 2/8/13 2:24 PM, "Lynnes, Christopher S. (GSFC-6102)"

> > < <mailto:christopher.s.lynnes at nasa.gov> christopher.s.lynnes at nasa.gov>
wrote:

> >

> >> As I was working with Ruth on a collection casting example, we ran

> >> across an area that we have not fully specified, namely how to

> >> identify links that access data collections that are NOT simply URLs
for

> OpenSearches.

> >> These access points may be single-file datasets, OPeNDAP, THREDDS,

> >> FTP directories, databases, order forms, dataset landing pages with

> >> links to access points...

> >>

> >> OTOH, we would like to keep the scheme congruent with a granule level

> >> response as much as possible.  So I propose the following

> >> Collection Access Point         rel                         type

> >> =======================               ===============

>             ==================================

> >> ==

> >> FTP Directory tree   archives               application/x-ftp-directory

> >> OPeNDAP Directory Tree      archives
application/x-opendap-

> directory+html

> >> (would also include xlink:arcrole=#dir)

> >> THREDDS Catalog                   archives
application/x-thredds-

> catalog+xml (would also

> >> include xlink:arcrole=#thredds)

> >> Single-file dataset    enclosure            <depends on data format>

> >> Order form                archives               text/html

> >> Dataset landing page             archives               text/html

> >>

> >> Comments?

> >> --

> >> Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185

> >> "Perfection is achieved, not when there is nothing left to add, but

> >> when there is nothing left to take away" -- A. de Saint-Exupery

> >>

> >>

> >>

> >>

> >>

> >>

> >> _______________________________________________

> >> Esip-discovery mailing list

> >>  <mailto:Esip-discovery at lists.esipfed.org>
Esip-discovery at lists.esipfed.org

> >>  <http://www.lists.esipfed.org/mailman/listinfo/esip-discovery>
http://www.lists.esipfed.org/mailman/listinfo/esip-discovery

> >

> 

> --

> Dr. Christopher Lynnes, NASA/GSFC, ph: 301-614-5185

> 

> 

> 

> _______________________________________________

> Esip-discovery mailing list

>  <mailto:Esip-discovery at lists.esipfed.org>
Esip-discovery at lists.esipfed.org

>  <http://www.lists.esipfed.org/mailman/listinfo/esip-discovery>
http://www.lists.esipfed.org/mailman/listinfo/esip-discovery

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-discovery/attachments/20130210/7208a244/attachment.html>