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

[Mattmann, Chris A (388J)]

Hey Chris,

On 2/9/13 5:43 AM, "Lynnes, Christopher S. (GSFC-6102)"
<christopher.s.lynnes at nasa.gov> wrote:

>On Feb 8, 2013, at 5:35 PM, "Mattmann, Chris A (388J)"
><chris.a.mattmann at jpl.nasa.gov> wrote:
>
>> +1 this sounds good to me. Though, keeping consistent with IANA,
>>wouldn't
>> it be:
>>
>> application/x-html-opendap-directory
>> application/x-xml-thredds-catalog
>
>Did some more research on this, and apparently, the whole x- scheme is
>deprecated since at least 2005:  http://tools.ietf.org/html/rfc4288.

Yeah seems conflicting in a way (as most RFCs do sometimes ;) ) with this
one:

http://www.rfc-editor.org/rfc/rfc6838.txt (see 3.4 and Appendix A)


Which I found here:

http://www.iana.org/assignments/media-types


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

Yeah in Apache Tika we use both but since it doesn't seem to be doctrine
that you can't use x- anymore, I still use x a lot, for example we defined
an x-tika namespace wherein which we add types that are specifically
detected by Tika and no other parsers.

>
>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.

+1, I like the +xml, like application/rss+xml

>
>We could actually submit these for registration to IANA:
>http://www.iana.org/cgi-bin/mediatypes.pl

Yep we should consider doing that, since then downstream libraries like
Tika will be more encouraged to automatically detect them and deal with
them.

Cheers,
Chris

>
>>
>> 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)"
>> <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
>>> Esip-discovery at lists.esipfed.org
>>> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery
>>
>
>--
>Dr. Christopher Lynnes, NASA/GSFC, ph: 301-614-5185
>
>
>