Discovery Telecon 2012-03-13

<< 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
  • http://wiki.esipfed.org/index.php/Summer_2012_Meeting#Submit_a_Session
• 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