DAP Capabilities: Difference between revisions

From OPeNDAP Documentation
⧼opendap2-jumptonavigation⧽
Line 20: Line 20:
=== Ownership ===
=== Ownership ===
     <dap:Contact>
     <dap:Contact>
         <dap:email>name@org.org</dap:email>
         <dap:Email>name@org.org</dap:Email>
     <dap:/Contact>
     <dap:/Contact>



Revision as of 19:24, 5 March 2010

Overview

Develop a definition of what a DAP servers Capabilities response should ;ook like.


What is a Capabilities response?

In the world of OGC it's a document that contains a description of the ownership (ows:ServiceProvider), service identification (ows:ServiceIdentification), service access (ows:OperationsMetadata), and holdings (*:Contents) of the server.


What are we doing now that's similar?

  • Ownership Nothing similar. Data providers can (but none that I have seen have) configure the OLFS to replace the standard documentation found through the Documentation link on every contents.html page. Otherwise they might get an email address about weho to write of the BES sends one in an error. The OLFS saves propagates the email address support@opendap.org from 14 different places in the code through a number of HTML responses . These could be modified by determined Hyrax installer, but it would be a hassle and wouldn't persist between installs. We have no structured response in this regard.
  • Service Identification Nothing similar. In the current version of Hyrax we return an list of the DAP versions the server supports in a larger XML document containing the names and version numbers of the software components running on the server.
  • Service Access Nothing similar
  • Holdings Currently we provide a linked list of holdings through THREDDS catalogs. Our THREDDS catalogs do not contain any THREDDS metadata, (or WCS metadata for that matter)


How might a DAP Capabilities response look

Ownership

   <dap:Contact>
       <dap:Email>name@org.org</dap:Email>
   <dap:/Contact>

Server-side functions.

We need to develop XML machine readable description of server side functions. Here's a straw man:

   <dap:ServerSideFunctions>
       <dap:ServerSideFunction>
           <dap:Name>geogrid</dap:Name>
           <dap:Parameter>
               <dap:Name></dap:Name>
               <dap:Type>Float</dap:Type>
               <dap:Description></dap:Description>
           </Parameter>
       </dap:ServerSideFunction>
   </dap:ServerSideFunctions>

Holdings

         <dap:CatalogRoot xlink:href="/opendap/catalog.xml" >


Services

   <dap:Services>
   
       <dap:ServiceIdentification name="hyrax" base="/opendap/hyrax/" >
         <dap:ServiceType>DAP</dap:ServiceType>
         <dap:Version>2.0</dap:Version>
         <dap:Version>3.1</dap:Version>
         <dap:Version>3.2</dap:Version>
         <dap:CatalogRoot xlink:href="/opendap/catalog.xml" >
       <dap:ServiceIdentification>
       
       <dap:ServiceIdentification name="hyrax-WCS" base="/opendap/WCS/" >
         <dap:ServiceType>WCS</dap:ServiceType>
         <dap:Version>1.1.2</dap:Version>
         <dap:CatalogRoot xlink:href="/opendap/WCS?service=WCS&version=1.1.2&request=GetCapabilities" >
       <dap:ServiceIdentification>
       
   </dap:Services>