Talk:Discovery Cast Atom Response Format v1.1
- 1 Possible namespace suggestions -- Clynnes 12:33, 15 February 2011 (MST)
- 2 Use of IANA-standard rel values -- Clynnes 12:52, 15 February 2011 (MST)
- 3 rel links
- 4 Pagination -- Rduerr 14:17, 15 February 2011 (MST)
- 5 Geo extensions -- Hook 12:59, 8 March 2011 (MST)
- 6 Comments & Questions about the spec. -- Bdwilson 12:01, 8 March 2011 (PST)
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/"
Re: Possible namespace suggestions -- Hook 13:52, 15 February 2011 (MST)
I was hoping we can select one. The choices were the ones floated at our working session. I just updated the format spec page with the "discovery" namespace.
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:
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 Casting Granules. OpenSearch Granules response
- Data Casting Collection. Not for OpenSearch Collection response which uses OSDD instead.
- Service Casting
- natural phenomenon
- feed of various feeds
- browse image
- arbitrary documentation
- 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.
Should we just skip the mapping and just adopt the values from the registry of the Internet Assigned Numbers Authority (IANA) conventions where applicable? Something like this:
|enclosure||(IANA) Default data link. Data Casting Granules. OpenSearch Granules response.|
|icon||(IANA) Appropriate for smaller browse images. See following for alternate browse links.|
|describedby||(IANA) Default documentation. See following for alternate documentation links.|
|metadata||Data, collection, and service metadata.|
|collection||Data Casting Collection. Not for OpenSearch Collection response which uses OSDD instead.|
|feed||Feed of various feeds.|
According to the Atom spec (sec. 220.127.116.11, we can't use a bare string for non-IANA link-types; it needs to be an IRI. Hence the "http://esip.org/ns..." business. And we still need to recommend what to do for "extra" data or documentation types.
Pagination -- Rduerr 14:17, 15 February 2011 (MST)
The text currently asks whether we should follow the OpenSearch pagination rules. I say yes (I can't think of anything better to replace it with).
Geo extensions -- Hook 12:59, 8 March 2011 (MST)
The Geo extensions section has been updated with more concrete examples. Note the support of box, circle, and polygon types. Also note that radius, line, and point are not in yet. Should we specify that all discovery services must support the full GeoRSS-Simple spec?
Comments & Questions about the spec. -- Bdwilson 12:01, 8 March 2011 (PST)
- Concerning 'rel' attributes, I don't think we should try to use too many
existing IANA rels. We could define our own in a namespace, and then possibly also duplicate links with generic names. In particular, I think 'enclosure', 'icon', and 'describedBy' are too generic, and should only be used as a generic duplicate for a more specific rel. Perhaps we need a new 'rel' table that has our types (data, browse, etc.) with suggested generic duplicates.
- Is a rectangular bbox in the response always required? Even if the
'natural' bounds are a circle or polygon?
- This spec. seems like a 'baseline' specification of the opensearch
response format. The details of how collection or granule metadata should be embedded in the response is missing. For granule responses, the current RSS datacasting needs to be reconciled with our Atom response.
- When a user searches for collections with an opensearch, sometimes he
wants collection metadata and other times he may want to be directed to the granule-level opensearch for that collection. We need to cover both cases.
- Here is a suggested 'rel' table. Our typed links use a namespace like
http://esipfed.org/ns/discovery/1.1/. The IANA types don't have a namespace.
|Link type (in Discovery namespace)||Alternate IANA type||Description|
|data||enclosure||Pointer to data file. Data Casting Granules. OpenSearch Granules response.|
|browse||icon||Pointer to browse image.|
|documentation||describedby||Pointer to human-readable documentation.|
|metadata||describedby||Data, collection, and service metadata.|
|collection||<no memberof in IANA?>||Pointer to collection cast, or pointer to OSDD document for granule search.|
|service||<IANA service is the wrong thing?>||Pointer to service cast, presumably that allows access to granules/collections
one is looking at.
|event||<None>||Pointer to an event cast for a natural phenomenon.|
|feed||<?>||Pointer to a feed of various feeds.|
Re: Comments & Questions about the spec. -- Hook 15:47, 8 March 2011 (MST)
We went over these and other questions at the Discovery_Telecon_2011-03-08