Discovery Feb 2012
Abstract/Agenda:
- Recap of Winter Meeting (if needed)
-
Status of new DCPs
- DCP-4: Use of xlink attributes in Atom <link> tags
- DCP-5: Use of OpenSearch <Query> tags for valid parameter values
- DCP-6: Replace overloaded time:start and time:end tags with dc:date
- DCP-7: define error handling best practices
Notes:
Recap of Winter Meeting (if needed)
DCP-4: Use of xlink attributes in Atom <link> tags
- Current Version: DCP-4: OPeNDAP Links in the Atom <link/> element
- Potentially use "role" and "arcrole" from xlink to capture all the semantics of DCP-3.
- Should we change DCP-4 to the current OPeNDAP suggestion, or should there be a separate DCP for the more general case of DCP-4?
-
Brian suggests a separate DCP for the general case (e.g., using "arcrole"), this will be coming in DCP-5
- Basically, covering the case where service casts refer to collections, or collection casts referring to services
- Returning a collection cast is a different use case from returning OPeNDAP response
- Pedro suggests you don't need to use something like arcrole, IANA has registered mime types and rels that should cover everything
- Summary -> DCP-4 will use xlink role, DCP-5 will use xlink role and arcrole
DCP-5: Use of OpenSearch <Query> tags for valid parameter values
- Likely renamed to DCP-8
- Li is interested in this, will be in contact with Ruth Duerr and Discovery mailing list for further information
DCP-6: Adopt Dublin Core Date Specification in Atom Response
- Current version: DCP-6: Adopt Dublin Core Date Specification in Atom Response
- More aligned with OGC use of OpenSearch
- dc:date refers to "point or period of time for an event associated with a resource"
- should we use the convention that the parameter and XML element should match?
- dc:date is more standard than the OpenSearch parameters
- time:start and time:end were only standardized as "queryable"
-
which does ESRI prefer or suggest based on client development?
- ESRI would align more with the dc approach (since there is already a dc:date XML element)
- Not a big deal either way, but prefer things that may become standardized
- another option (considered by OGC) is using gml, but this is more complex
-
Brian seeking connection between parameters and response elements in OSDD; however, OSDD does not support this
- Only potential mechanism is "rel" and "type"
- Eric also suggests using the "rel" list capabilities of OpenSearch to tell clients of this "convention"
- The response may not actually echo all the values for search parameters
- Another avenue is to use the Query tag is someway
- Could use the <atom:Content> tags to put whatever data you want
DCP-7: define error handling best practices
- There is no standard for how errors will be handled
- Formally adopt HTTP 1.1 status codes
- HTTP 400s cover client side, 500s cover server side
- Lots of different options for responses, Atom response containing error, HTTP error code, etc.
Originally posted on the wiki: http://wiki.esipfed.org/index.php/Discovery_Telecon_2012-02-14
Citation:
Submitted by superadmin on 2012-04-25 21:51.