Discovery March 2012
- 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: Error Handling Best Practices for Discovery Repsonse
- Planning for ESIP summer meeting
- Discovery_Testbed_Work_Plan contains Use Cases and Functional Requirements
- Brian's service cast "Relax NG" validator service
- deprecated (withdrawn)
- replaced by DCP-3
- deprecated (withdrawn)
- replaced by DCP-4
- is this ready for voting?
- currently just about OPeNDAP links
- vote on DCP-4 as a move forward, then generalize
- we needed an extra attribute to express that the service was OPeNDAP
- Brian will write the generalized version
- Chris will set up Doodle poll
Has James updated the examples per Pedro's request? (yes)
- The server might be configured to give you an error message or an HDF file, so it could be type="text/plain"
- The default case is an error message
- James should right up more justifying why the example has the attributes it does, and maybe add more examples
Is there any need to have a dereferenceable xlink:role?
- Yes, but it should not be required
- An XSD is as good of a URI as any
- Should the OPeNDAP URL (example 2 as of meeting time) be rel="enclosure" since it should return metadata?
Keep the xlink:role consistent across links (whether ddx, das, or whatever)
- This will not work because there are multiple kinds of metadata (ddx is XML and others are text plain)
If the OPeNDAP link only gives an error message, there should be a preferred link for clients that don't speak OPeNDAP
- If the rel="enclosure" you will get the whole file, if the rel="describedBy" you will get the OPeNDAP error response
Need to standardize the rel for DCP-4 (Chris suggests rel="service" for OPeNDAP)
- rel="service" is used in other ways for Atom, so we'd be repurposing it
- This all derives from one of the limitations of DAP2 (because of differences in server configuration)
Atom spec would suggest the use of rel="alternate"
- "alternate" means a different representation of the metadata, not the resource itself
- Should we be using a "length" attribute for rel="enclosure"?
- Do we really need to worry so much about the rel attribute (will an arbitrary Atom client)
We should use the HTML OPeNDAP page as a "landing page"?
- This works well with a browser, but not so well with OPeNDAP clients (need to provide the endpoint URL somehow)
Put a length attribute in an example
- For HDF files, we can add the length attribute; for NetCDF file, this probably will not be possible
- Don't include metadata responses because OPeNDAP clients will know how to get that...
- Only a few hours left to comment
- OGC will be following the same standard!
Brian wanted to extend the Query tag to tell you what the XML tags will be in the responses
- and will try to make progress on this later (through the custom parameters DCP)
- Using codes from the HTTP/1.1 spec
for OpenSearch requests with invalid request parameters
- return 400 Bad Request with appropriate error message.
- do not return successfully and rely on OpenSearch <Query> element to repeat the valid parameters.
- users need to know if any of their request parameters are not used in the constraint search.
follow the HTTP error message handling spec that comes with the status codes.
- For an invalid OpenSearch request with unrecognized parameter field(s), it should result in a 400 Bad Request with error essage. Do not return successfully and rely on OpenSearch <Query> element to repeat the valid parameters. Users need to know if any of their request parameters are not used in the constraint search.
Always have well-formed response with mime-type, but do not use Atom responses for bad requests.
- We decided not to embed the error messages in Atom's content tag
- Detailed error message is almost always read by a human (we should only use text/plain or text/html errors)
- 403 Forbidden: for security reasons, might not want to explain the reason why.
- 502 Bad Gateway: for security reasons, might not want to explain the reason why.
Planning for ESIP Summer Meeting
"Relax NG" Validator Service
- Chris or Hook will deprecate DCP-2 and DCP-3 on DCP page
- Brian will work on generalized version of DCP-4 (Pedro will contribute examples for WxS)
- Chris will send out Doodle poll for DCP-4
- James will update examples for DCP-4 with details and additional examples (also include all the different OPeNDAP MIME types) (also, try to use real links) (also put an example with a "length" attribute)
- All review DCP-6 if interested (only a few hours left!)
- Hook will continue to tweak DCP-7 before voting
Lynnes, C.; Hua, H.; Discovery March 2012; Telecon Minutes. ESIP Commons , April 2012
Submitted by superadmin on 2012-04-25 21:58.