Difference between revisions of "Discovery Telecon 2012-03-13"

From Earth Science Information Partners (ESIP)
(Reverted edits by Hook (talk) to last revision by Rozele)
 
(14 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, February 14, 2011. 4:00pm ET / 1:00pm PT
+
* 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 ==
 +
 +
* 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
 +
** [[Discovery_Change_Proposal-7 | DCP-7: Error Handling Best Practices for Discovery Repsonse]]
 +
* Planning for ESIP summer meeting
 +
** http://wiki.esipfed.org/index.php/Summer_2012_Meeting#Submit_a_Session
 +
* Discovery Testbed
 +
** [[Discovery_Testbed_Work_Plan]] contains Use Cases and [[Discovery_Testbed_Requirements | Functional Requirements]]
 +
* Brian's service cast "Relax NG" validator service
  
 
== Notes ==
 
== Notes ==
  
−
=== Recap of Winter Meeting (if needed) ===
+
=== 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-4: Use of xlink attributes in Atom <link> tags ===
+
* DCP-6
−
* Current Version: [[DCP-4|DCP-4: OPeNDAP Links in the Atom <link/> element]]
+
** Only a few hours left to comment
−
* Potentially use "role" and "arcrole" from xlink to capture all the semantics of DCP-3.
+
** OGC will be following the same standard!
−
* 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 wanted to extend the Query tag to tell you what the XML tags will be in the responses
−
* Brian suggests a separate DCP for the general case (e.g., using "arcrole"), this will be coming in DCP-5
+
*** and will try to make progress on this later (through the custom parameters DCP)
−
** Basically, covering the case where service casts refer to collections, or collection casts referring to services
+
* DCP-7
−
* Returning a collection cast is a different use case from returning OPeNDAP response
+
** Using codes from the HTTP/1.1 spec
−
* Pedro suggests you don't need to use something like arcrole, IANA has registered mime types and rels that should cover everything
+
** Detailed error message is almost always read by a human (we should only use text/plain or text/html errors
−
* Summary -> DCP-4 will use xlink role, DCP-5 will use xlink role and arcrole
+
** We decided not to embed the error messages in the content tag
 +
** May want to go with just what HTTP recommends
  
−
=== DCP-5: Use of OpenSearch <Query> tags for valid parameter values ===
+
=== Planning for ESIP Summer Meeting ===
−
* 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 ===
+
=== Discovery Testbed ===
−
* 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 ===
+
=== "Relax NG" Validator Service ===
−
* 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.
 

Latest revision as of 10:24, September 19, 2012

<< Back to the Discovery Telecons page

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

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

Retrieved from "https://wiki.esipfed.org/w/index.php?title=Discovery_Telecon_2012-03-13&oldid=41002"
GNU Free Documentation License 1.2
Powered by MediaWiki
Powered by Semantic MediaWiki