Discovery March 2012

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