Difference between revisions of "Discovery Telecon 2012-03-13"
From Earth Science Information Partners (ESIP)
Line 80: | Line 80: | ||
*** For HDF files, we can add the length attribute; for NetCDF file, this probably will not be possible | *** 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... | ** Don't include metadata responses because OPeNDAP clients will know how to get that... | ||
− | |||
* DCP-6 | * DCP-6 | ||
** Only a few hours left to comment | ** Only a few hours left to comment | ||
Line 88: | Line 87: | ||
* DCP-7 | * DCP-7 | ||
** Using codes from the HTTP/1.1 spec | ** Using codes from the HTTP/1.1 spec | ||
− | ** Detailed error message is almost always read by a human (we should only use text/plain or text/html errors | + | ** 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 === | === Planning for ESIP Summer Meeting === |
Revision as of 15:48, March 13, 2012
<< Back to the Discovery Telecons page
- Tuesday, March 13, 2012. 4:00pm ET / 1:00pm PT
- WebEx Info:
- Call-in toll-free number (US/Canada): 1-877-668-4493
- Attendee access code: 231 407 50
- To start the online portion of the Personal Conference meeting , go to https://esipfed.webex.com/mw0306ld/mywebex/default.do?siteurl=esipfed&service=1 and select the Discovery Cluster meeting.
Attendees
- Chris Lynnes
- Hook Hua
- Christine White (3)
- Eric Rozell
- Erin Robinson
- Brian Wilson (6)
- Pedro Goncalves
- James Gallagher (7)
Action Items
- 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
Agenda
- DCP updates
- 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
- Discovery_Testbed_Work_Plan contains Use Cases and Functional Requirements
- Brian's service cast "Relax NG" validator service
Notes
DCP Updates
- DCP-2
- deprecated (withdrawn)
- replaced by DCP-3
- DCP-3
- deprecated (withdrawn)
- replaced by DCP-4
- 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...
- DCP-6
- 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)
- DCP-7
- 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.