Discovery March 2012

Abstract/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
    • 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

Discovery Testbed

"Relax NG" Validator Service

Actions: 
  • 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
Citation:
Lynnes, C.; Hua, H.; Discovery March 2012; Telecon Minutes. ESIP Commons , April 2012