Difference between revisions of "Discovery Telecon 2012-03-13"
From Earth Science Information Partners (ESIP)
(12 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
[[Discovery_Telecons|<< Back to the Discovery Telecons page]] | [[Discovery_Telecons|<< Back to the Discovery Telecons page]] | ||
− | * Tuesday, | + | * Tuesday, March 13, 2012. 4:00pm ET / 1:00pm PT |
* WebEx Info: | * WebEx Info: | ||
** Call-in toll-free number (US/Canada): 1-877-668-4493 | ** Call-in toll-free number (US/Canada): 1-877-668-4493 | ||
Line 8: | Line 8: | ||
==Attendees== | ==Attendees== | ||
+ | * Chris Lynnes | ||
+ | * Hook Hua | ||
+ | * Christine White (3) | ||
+ | * Eric Rozell | ||
+ | * Erin Robinson | ||
+ | * Brian Wilson (6) | ||
+ | * Pedro Goncalves | ||
+ | * James Gallagher (7) | ||
== Action Items == | == 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 == | == Agenda == | ||
Line 17: | Line 32: | ||
** DCP-5: Use of OpenSearch <Query> tags for valid parameter values | ** 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-6: Replace overloaded time:start and time:end tags with dc:date | ||
− | ** DCP-7: | + | ** [[Discovery_Change_Proposal-7 | DCP-7: Error Handling Best Practices for Discovery Repsonse]] |
* Planning for ESIP summer meeting | * Planning for ESIP summer meeting | ||
** http://wiki.esipfed.org/index.php/Summer_2012_Meeting#Submit_a_Session | ** http://wiki.esipfed.org/index.php/Summer_2012_Meeting#Submit_a_Session | ||
* Discovery Testbed | * Discovery Testbed | ||
− | ** | + | ** [[Discovery_Testbed_Work_Plan]] contains Use Cases and [[Discovery_Testbed_Requirements | Functional Requirements]] |
* Brian's service cast "Relax NG" validator service | * Brian's service cast "Relax NG" validator service | ||
== Notes == | == 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 | ||
+ | ** Detailed error message is almost always read by a human (we should only use text/plain or text/html errors | ||
+ | ** We decided not to embed the error messages in the content tag | ||
+ | ** May want to go with just what HTTP recommends | ||
+ | |||
+ | === Planning for ESIP Summer Meeting === | ||
+ | |||
+ | === Discovery Testbed === | ||
+ | |||
+ | === "Relax NG" Validator Service === |
Latest revision as of 10:24, September 19, 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
- Detailed error message is almost always read by a human (we should only use text/plain or text/html errors
- We decided not to embed the error messages in the content tag
- May want to go with just what HTTP recommends