|
|
| Line 14: |
Line 14: |
| | | | |
| | == Notes == | | == Notes == |
| − |
| |
| − | === Recap of Winter Meeting (if needed) ===
| |
| − |
| |
| − | === DCP-4: Use of xlink attributes in Atom <link> tags ===
| |
| − | * Current Version: [[DCP-4|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: [[Discovey_Change_Proposal-6|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.
| |
