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