Discovery Telecon 2012-03-13

From Earth Science Information Partners (ESIP)

<< Back to the Discovery Telecons page


  • 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



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