Talk:Discovery Cast Atom Response Format v1.1

Possible namespace suggestions -- Clynnes 12:33, 15 February 2011 (MST)

In the Namespace section, I think we should come out with one recommendation rather than just multiple-choice. I suggest it be

• discovery: "http://esipfed.org/ns/discovery/1.1/"

Use of IANA-standard rel values -- Clynnes 12:52, 15 February 2011 (MST)

Discussions with OGC and OpenSearch resulted in a suggestion we use IANA standard values where possible. I endorse that, and suggest that the section be revised as follows:

rel links

Where possible, the ESIP Discovery convention uses values from the registry of the Internet Assigned Numbers Authority (IANA). We map common discovery link types as follow:

Link type	IANA Relation Type	Note
data	enclosure	Default data link. See following for alternate data links.
browse	icon	Appropriate for smaller browse images. See following for alternate browse links.
documentation	describedby	Default documentation. See following for alternate documentation links.

The above IANA mapping is intended for the simplest cases, where returned items include only one type data link, one type of documentation link, and a small browse image. For deviations from this scenario, such as multiple data links (say, an HDF version and a netCDF version) or documentation links (e.g., User's Guide vs. Quality Guide), the server is expected to use ESIP namespaced rel links. This is also the case for link types that do not map well to an IANA type, such as "event" or "metadata".

Currently, the supported rel links of "http://esipfed.org/ns/discovery/1.1/cast_type#" where "cast_type" is of one of the following values:

• data
  • Data Casting Granules. OpenSearch Granules response
• collection
  • Data Casting Collection. Not for OpenSearch Collection response which uses OSDD instead.
• service
  • Service Casting
• event
  • natural phenomenon
• feed
  • feed of various feeds
• browse
  • browse image
• documentation
  • arbitrary documentation
• metadata
  • data and collection metadata

The rel links shall have types. Currently, there are no constraints on allowed types. Though a mime-type is highly recommended.