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

Mattmann, Chris A (388J) chris.a.mattmann at jpl.nasa.gov
Sat Feb 9 13:07:52 EST 2013

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

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

Which I found here:


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

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:
>Pending agreement with Unidata of course.

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

>We could actually submit these for registration to IANA:

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


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

More information about the Esip-discovery mailing list