/[volute]/trunk/projects/grid/VOSI/VOSI-v1.0pr.html
ViewVC logotype

Diff of /trunk/projects/grid/VOSI/VOSI-v1.0pr.html

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1456 by rplante@ncsa.uiuc.edu, Tue May 10 19:59:34 2011 UTC revision 1457 by rplante@ncsa.uiuc.edu, Tue May 10 20:24:45 2011 UTC
# Line 1  Line 1 
1  <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">  <?xml version="1.0" encoding="iso-8859-1"?>
2  <html><head>  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
3    <html>
4    <head>
5    <style type="text/css">
6  <style type="text/css">      .issue {background-color: yellow}
7      .issue {background-color: yellow}      .postponedissue {background-color: yellow}
8      .postponedissue {background-color: yellow}      .def code
9      .def code      .future {background-color: pink}
10      .future {background-color: pink}      .draftedit {background-color: white}
11      .draftedit {background-color: white}      .draftdelete {background-color: white}
12      .draftdelete {background-color: white}      .note { margin-left: 4em }
13      .note { margin-left: 4em }      code { font-weight: bold;
14      code { font-weight: bold;             font-family: monospace }
15             font-family: monospace }  
16    div.exampleInner pre { margin-left: 1em;
17  div.exampleInner pre { margin-left: 1em;                         margin-top: 0em; margin-bottom: 0em}
18                         margin-top: 0em; margin-bottom: 0em}  div.exampleOuter {border: 4px double gray;
19  div.exampleOuter {border: 4px double gray;                    margin: 0em; padding: 0em}
20                    margin: 0em; padding: 0em}  div.exampleInner { border-top-width: 4px;
21  div.exampleInner { border-top-width: 4px;                     border-top-style: double;
22                     border-top-style: double;                     border-top-color: white;
23                     border-top-color: white;                     border-bottom-width: 4px;
24                     border-bottom-width: 4px;                     border-bottom-style: double;
25                     border-bottom-style: double;                     border-bottom-color: white;
26                     border-bottom-color: white;                     padding: 0px; margin: 0em }
27                     padding: 0px; margin: 0em }  div.exampleWrapper { margin: 4px }
28  div.exampleWrapper { margin: 4px }  div.exampleHeader { font-weight: bold;
29  div.exampleHeader { font-weight: bold;                      margin: 4px}
30                      margin: 4px}  
31    div.schemaInner pre { margin-left: 1em;
32  div.schemaInner pre { margin-left: 1em;                        margin-top: 0em; margin-bottom: 0em;
33                        margin-top: 0em; margin-bottom: 0em;                         }
34                         }  div.schemaOuter {border: 4px double gray; padding: 0em}
35  div.schemaOuter {border: 4px double gray; padding: 0em}  div.schemaInner { background-color: #eeeeee;
36  div.schemaInner { background-color: #eeeeee;                     border-top-width: 4px;
37                     border-top-width: 4px;                     border-top-style: double;
38                     border-top-style: double;                     border-top-color: #d3d3d3;
39                     border-top-color: #d3d3d3;                     border-bottom-width: 4px;
40                     border-bottom-width: 4px;                     border-bottom-style: double;
41                     border-bottom-style: double;                     border-bottom-color: #d3d3d3;
42                     border-bottom-color: #d3d3d3;                     padding: 4px; margin: 0em }
43                     padding: 4px; margin: 0em }  div.schemaHeader { font-weight: bold;
44  div.schemaHeader { font-weight: bold;                      margin: 4px}
45                      margin: 4px}  </style>
46  </style>          <title>IVOA Proposed Recommendation - IVOA Support Interfaces</title>
47          <title>IVOA Proposed Recommendation - IVOA Support Interfaces</title>          <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
48          <meta http-equiv="content-type" content="text/html; charset=UTF-8">          <meta name="keywords" content="IVOA, International, Virtual, Observatory, Alliance" />
49          <meta name="keywords" content="IVOA, International, Virtual, Observatory, Alliance">          <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
50          <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">          <meta name="maintainedBy" content="IVOA Document Coordinator, ivoadoc@ivoa.net" />
51          <meta name="maintainedBy" content="IVOA Document Coordinator, ivoadoc@ivoa.net">          <link rel="stylesheet" href="http://ivoa.net/misc/ivoa_pr.css" type="text/css" />
52          <link rel="stylesheet" href="VOSI-v1.0pr4_files/ivoa_pr.css" type="text/css">  </head>
53  </head><body>  
54  <div class="head">  <body>
55  <a href="http://www.ivoa.net/"><img alt="IVOA" src="VOSI-v1.0pr4_files/IVOA_wb_300.jpg" height="169" width="300"></a>  <div class="head">
56  <h1>IVOA Support Interfaces<br>  <a href="http://www.ivoa.net/"><img alt="IVOA" src="http://www.ivoa.net/pub/images/IVOA_wb_300.jpg" width="300" height="169"/></a>
57  Version 1.00-20101206</h1>  <h1>IVOA Support Interfaces<br/>
58  <h2>IVOA WG Proposed Recommendation 2010 December 6 </h2>  Version 1.00-20101213</h1>
59    <h2>IVOA WG Proposed Recommendation 2010 December 13 </h2>
60  <dl>  
61    <dt>This version:</dt>  <dl>
62    <dd><a href="http://www.ivoa.net/Documents/VOSI/20101206/">    <dt>This version:</dt>
63        http://www.ivoa.net/Documents/VOSI/20101206/</a></dd>    <dd><a href="http://www.ivoa.net/Documents/VOSI/20101213/">
64          http://www.ivoa.net/Documents/VOSI/20101213/</a></dd>
65    <dt>Latest version:</dt>  
66    <dd><a href="http://www.ivoa.net/Documents/latest/VOSI.html">    <dt>Latest version:</dt>
67        http://www.ivoa.net/Documents/latest/VOSI.html</a></dd>    <dd><a href="http://www.ivoa.net/Documents/latest/VOSI.html">
68          http://www.ivoa.net/Documents/latest/VOSI.html</a></dd>
69    <dt>Previous versions:</dt>  
70    <dd>PR: <a href="http://www.ivoa.net/Documents/VOSI/20100311/">    <dt>Previous versions:</dt>
71      http://www.ivoa.net/Documents/VOSI/20100311/</a> <br>    <dd>PR: <a href="http://www.ivoa.net/Documents/VOSI/20100311/">
72        WD: <a href="http://www.ivoa.net/Documents/VOSI/20090825/">      http://www.ivoa.net/Documents/VOSI/20100311/</a> <br />
73        http://www.ivoa.net/Documents/VOSI/20090825/</a> <br>        WD: <a href="http://www.ivoa.net/Documents/VOSI/20090825/">
74        WD: <a href="http://www.ivoa.net/Documents/VOSI/20081030/">        http://www.ivoa.net/Documents/VOSI/20090825/</a> <br />
75        http://www.ivoa.net/Documents/VOSI/20081030/</a></dd>        WD: <a href="http://www.ivoa.net/Documents/VOSI/20081030/">
76  </dl>        http://www.ivoa.net/Documents/VOSI/20081030/</a></dd>
77    </dl>
78  <dl>  
79          <dt>Working Group:</dt>  <dl>
80                  <dd><a href="http://www.ivoa.net/twiki/bin/view/IVOA/IvoaGridAndWebServices">          <dt>Working Group:</dt>
81    http://www.ivoa.net/twiki/bin/view/IVOA/IvoaGridAndWebServices</a></dd>                  <dd><a
82      href="http://www.ivoa.net/twiki/bin/view/IVOA/IvoaGridAndWebServices">
83    <dt>Editors:</dt>    http://www.ivoa.net/twiki/bin/view/IVOA/IvoaGridAndWebServices</a></dd>
84    <dd><a href="http://www.ivoa.net/twiki/bin/view/IVOA/MatthewGraham">Matthew  
85    Graham</a><br>    <dt>Editors:</dt>
86      <a href="http://www.ivoa.net/twiki/bin/view/IVOA/GuyRixon">Guy Rixon</a></dd>    <dd><a
87          <dt>Author(s):</dt>    href="http://www.ivoa.net/twiki/bin/view/IVOA/MatthewGraham">Matthew
88                  <dd>    Graham</a><br/>
89                          <a href="http://www.ivoa.net/twiki/bin/view/IVOA/IvoaGridAndWebServices">Grid and Web      <a
90    Services Working Group</a><br>    href="http://www.ivoa.net/twiki/bin/view/IVOA/GuyRixon">Guy Rixon</a></dd>
91                          <a href="http://www.ivoa.net/twiki/bin/view/IVOA/"></a>          <dt>Author(s):</dt>
92                  </dd>                  <dd>
93  </dl>                          <a
94  <hr></div>    href="http://www.ivoa.net/twiki/bin/view/IVOA/IvoaGridAndWebServices">Grid and Web
95      Services Working Group</a><br/>
96  <h2><a name="abstract" id="abstract">Abstract</a></h2>                          <a href="http://www.ivoa.net/twiki/bin/view/IVOA/"></a>
97                    </dd>
98  <p>  </dl>
99  This document describes the minimum interface that a (SOAP- or REST-based) web service requires to participate in the IVOA.  <hr/></div>
100  </p>  
101    <h2><a name="abstract" id="abstract">Abstract</a></h2>
102  <div class="status">  
103  <h2><a name="status" id="status">Status of this Document</a></h2>  <p>
104    This document describes the minimum interface that a (SOAP- or REST-based) web service requires to participate in the IVOA.
105  <!-- Choose one of the following (and remove the rest)-->  </p>
106  <!--Note-->  
107    <div class="status">
108    <h2><a name="status" id="status">Status of this Document</a></h2>
109    
110    <!-- Choose one of the following (and remove the rest)-->
111    <!--Note-->
112  <!--  <!--
113  <p>This is an IVOA Note expressing suggestions from and opinions of the authors.<br/>  <p>This is an IVOA Note expressing suggestions from and opinions of the authors.<br/>
114  It is intended to share best practices, possible approaches, or other perspectives on interoperability with the Virtual Observatory.  It is intended to share best practices, possible approaches, or other perspectives on interoperability with the Virtual Observatory.
115  It should not be referenced or otherwise interpreted as a standard specification.</p>  It should not be referenced or otherwise interpreted as a standard specification.</p>
116  <p>This is an IVOA Working Draft for review by IVOA members and other interested parties.<br/>  <p>This is an IVOA Working Draft for review by IVOA members and other interested parties.<br/>
117  It is a draft document and may be updated, replaced, or obsoleted by other documents at any time.  It is a draft document and may be updated, replaced, or obsoleted by other documents at any time.
118  It is inappropriate to use IVOA Working Drafts as reference materials -->  It is inappropriate to use IVOA Working Drafts as reference materials -->
119    <!--or to cite them as other than "work in progress.</p>    <!--or to cite them as other than "work in progress.</p>
120    -->    -->
121  <!--Proposed Recommendation-->  <!--Proposed Recommendation-->
122  <p>This is an IVOA Proposed Recommendation made available for public review.<br>  <p>This is an IVOA Proposed Recommendation made available for public review.<br/>
123  It is appropriate to reference this document only as a recommended standard that is under review and which may be changed  It is appropriate to reference this document only as a recommended standard that is under review and which may be changed
124  before it is accepted as a full recommendation.<br>  before it is accepted as a full recommendation.<br/>
125  The first release of this document was 2010 March 11 .  The first release of this document was 2010 March 11 .
126  </p>  </p>
127  <!--Recommendation  <!--Recommendation
128  <p>This document has been produced by the IVOA "WG Name"  Working Group.<br/>  <p>This document has been produced by the IVOA "WG Name"  Working Group.<br/>
129  It has been reviewed by IVOA Members and other interested parties, and has been endorsed by the IVOA Executive Committee as an IVOA Recommendation.  It has been reviewed by IVOA Members and other interested parties, and has been endorsed by the IVOA Executive Committee as an IVOA Recommendation.
130  It is a stable document and may be used as reference material or cited as a normative reference from another document. IVOA's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment.  It is a stable document and may be used as reference material or cited as a normative reference from another document. IVOA's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment.
131  This enhances the functionality and interoperability inside the Astronomical Community.</p>  This enhances the functionality and interoperability inside the Astronomical Community.</p>
132  -->  -->
133    
134  A list of <a href="http://www.ivoa.net/Documents/">current IVOA Recommendations and other technical documents</a> can be found at http://www.ivoa.net/Documents/.  A list of <a href="http://www.ivoa.net/Documents/">current IVOA Recommendations and other technical documents</a> can be found at http://www.ivoa.net/Documents/.
135    
136  </div><br>  </div><br />
137    
138  <h2><a name="acknowledgments" id="acknowledgments">Acknowledgments</a></h2>  <h2><a name="acknowledgments" id="acknowledgments">Acknowledgments</a></h2>
139  <p>This document has been developed with support from the  <p>This document has been developed with support from the
140  <a href="http://www.nsf.gov/">National Science Foundation's</a>  <a href="http://www.nsf.gov/">National Science Foundation's</a>
141  Information Technology Research Program under Cooperative Agreement  Information Technology Research Program under Cooperative Agreement
142  AST0122449 with The Johns Hopkins University, from the  AST0122449 with The Johns Hopkins University, from the
143  <a href="http://www.pparc.ac.uk/">UK Particle Physics and Astronomy  <a href="http://www.pparc.ac.uk/">UK Particle Physics and Astronomy
144  Research Council (PPARC)</a>, from the European Commission's (EC)  Research Council (PPARC)</a>, from the European Commission's (EC)
145  <a href="http://cordis.europa.eu/fp6/">Sixth  <a href="http://cordis.europa.eu/fp6/">Sixth
146  Framework Programme</a> via the <a href="http://www.astro-opticon.org/">  Framework Programme</a> via the <a href="http://www.astro-opticon.org/">
147  Optical Infrared Coordination Network (OPTICON)</a>, and from EC's  Optical Infrared Coordination Network (OPTICON)</a>, and from EC's
148  <a href="http://cordis.europa.eu/fp7/">Seventh Framework Programme</a>  <a href="http://cordis.europa.eu/fp7/">Seventh Framework Programme</a>
149  via its  via its
150  <a href="http://cordis.europa.eu/fp7/ict/e-infrastructure/home_en.html">  <a href="http://cordis.europa.eu/fp7/ict/e-infrastructure/home_en.html">
151  eInfrastructure Science Repositories initiative</a>.  </p>  eInfrastructure Science Repositories initiative</a>.  </p>
152    
153  <p>This work is based on discussions and actions from the 2003 IVOA  <p>This work is based on discussions and actions from the 2003 IVOA
154  meeting in Strasbourg and further discussions on registry  meeting in Strasbourg and further discussions on registry
155  functionality at JHU late in 2003. Later inputs came from a local  functionality at JHU late in 2003. Later inputs came from a local
156  meeting at JHU in Sept. 2004. William O'Mullane and Ani Thakar were the editors and primary authors for these early versions.</p>  meeting at JHU in Sept. 2004. William O'Mullane and Ani Thakar were the editors and primary authors for these early versions.</p>
157  <p>  <p>
158  The decision to split the interfaces into a mandatory set and optional  The decision to split the interfaces into a mandatory set and optional logging interfaces was taken by GWS-WG at the IVOA meeting of May 2006.
159  logging interfaces was taken by GWS-WG at the IVOA meeting of May 2006.  </p>
160  </p>  
161    <h2><a name="conformance" id="conformance">Conformance related definitions</a></h2>
162  <h2><a name="conformance" id="conformance">Conformance related definitions</a></h2>  <p>The words "MUST", "SHALL", "SHOULD", "MAY", "RECOMMENDED", and "OPTIONAL" (in upper or lower case) used in this document are to be interpreted as described in IETF standard, RFC 2119 [RFC 2119].</p><p>
163  <p>The words "MUST", "SHALL", "SHOULD", "MAY", "RECOMMENDED", and  The <strong>Virtual Observatory (VO)</strong> is a general term for a
164  "OPTIONAL" (in upper or lower case) used in this document are to be  collection of federated resources that can be used to conduct
165  interpreted as described in IETF standard, RFC 2119 [0].</p><p>  astronomical research, education, and outreach. The <strong>International Virtual Observatory Alliance (IVOA)</strong> is a global collaboration of separately funded projects to develop standards and infrastructure that enable VO applications. The International Virtual Observatory (IVO) application is an application that takes advantage of IVOA standards and infrastructure to provide some VO service.
166  The <strong>Virtual Observatory (VO)</strong> is a general term for a  </p>
167  collection of federated resources that can be used to conduct  
168  astronomical research, education, and outreach. The <strong>International Virtual Observatory Alliance (IVOA)</strong>  <h2><a id="contents" name="contents">Contents</a></h2>
169   is a global collaboration of separately funded projects to develop  <div class="head">
170  standards and infrastructure that enable VO applications. The  <ul class="toc">
171  International Virtual Observatory (IVO) application is an application  <li><a href="#abstract">Abstract</a></li>
172  that takes advantage of IVOA standards and infrastructure to provide  <li><a href="#status">Status</a></li>
173  some VO service.  <li><a href="#acknowledgments">Acknowledgments</a></li>
174  </p>  <li><a href="#contents">Contents</a></li>
175    <li><a href="#sec1">1. Introduction</a></li>
176  <h2><a id="contents" name="contents">Contents</a></h2>  <ul class="toc"><li><a href="#sec1_1">1.1 The role in the IVOA Architecture</a></li></ul>
177  <div class="head">  <li><a href="#sec2">2. Interfaces bindings</a></li>
178  <ul class="toc">  <li><a href="#sec3">3. Metadata specification</a>
179  <li><a href="#abstract">Abstract</a></li>          <ul class="toc">
180  <li><a href="#status">Status</a></li>          <li><a href="#sec3_1">3.1 Capability metadata</a></li>
181  <li><a href="#acknowledgments">Acknowledgments</a></li>          <li><a href="#sec3_2">3.2 Non-service metadata (non-normative)</a></li>
182  <li><a href="#contents">Contents</a></li>          <li><a href="#sec3_3">3.3 Availability metadata</a></li>
183  <li><a href="#sec1">1. Introduction</a></li>          <li><a href="#sec3_4">3.4 Table metadata</a></li>
184  <ul class="toc"><li><a href="#sec1_1">1.1 The role in the IVOA Architecture</a></li></ul>          </ul></li>
185  <li><a href="#sec2">2. Interface bindings</a></li>  <li><a href="#sec4">4. Registration of VOSI endpoints</a></li>
186  <li><a href="#sec3">3. Metadata specification</a></li>  <li><a href="#sec5">5. Example VOSI responses</a></li>
187          <ul class="toc">  <br/>
188          <li><a href="#sec3_1">2.1 Capability metadata</a></li>  <li><a href="#appA">Appendix A: VOSI XML schemas</a></li>
189          <li><a href="#sec3_2">2.2 Non-service metadata (non-normative)</a></li>  <li><a href="#appB">Appendix B: Changes from previous versions</a></li>
190          <li><a href="#sec3_3">2.3 Availability metadata</a></li>  <li><a href="#ref">References</a></li>
191          <li><a href="#sec3_4">2.4 Table metadata</a></li>  </ul>
192          </ul>  </div>
193  <li><a href="#sec4">4. Registration of VOSI endpoints</a></li>  <hr/>
194  <li><a href="#sec5">5. Example VOSI responses</a></li>  
195  <br>  
196  <li><a href="#appA">Appendix A: VOSI XML schemas</a></li>  <br/>
197  <li><a href="#appB">Appendix B: Changes from previous versions</a></li>  <h2><a name="sec1">1. Introduction</a></h2>
198  <li><a href="#ref">References</a></li>  <p>The web services that comprise much of the Virtual Observatory (VO)
199  </ul>  come in two forms: SOAP-based (Simple Object Access Protocol, [1])
200  </div>  ones such as footprint and spectrum services [2], SkyNodes and Open
201  <hr>  SkyQuery [3], registry interfaces [4] and CDS access [5]; and RESTful
202    (REpresentational State Transfer, [6]) ones such as TAP [7] and other
203    second generation data access (DAL) services, and VOSpace 2.0
204  <br>  [8]. This document describes a set of common basic functions that all
205  <h2><a name="sec1">1. Introduction</a></h2>  these services should provide in the form of a standard support interface
206  <p>The web services that comprise much of the Virtual Observatory (VO)  in order to support the effective management of the VO.
207  come in two forms: SOAP-based (Simple Object Access Protocol, [1])  </p>
208  ones such as footprint and spectrum services [2], SkyNodes and Open  <p>
209  SkyQuery [3], registry interfaces [4] and CDS access [5]; and RESTful  The IVOA Web Services Basic Profile [9] mandates that a compliant
210  (REpresentational State Transfer, [6]) ones such as TAP [7] and other  SOAP-based web service should have the interface defined in this
211  second generation data access (DAL) services, and VOSpace 2.0  specification, as expressed using the standard WSDL (Web Services
212  [8]. This document describes a set of common basic functions that all  Description Language, [10]) format. For RESTful services, the
213  these services should provide in the form of a standard support interface  requirement for the support interface is stated in the specification for each kind of service. A contract for a RESTful service may specify extra constraints (e.g., on the form of the URIs) for the support interface. </p>
214  in order to support the effective management of the VO.  
215  </p>  
216  <p>  <h3><a name="sec1_2">1.2 The role in the IVOA Architecture</a></h3>
217  The IVOA Web Services Basic Profile [9] mandates that a compliant  <p>The IVOA Architecture [11] provides a high-level view of how IVOA
218  SOAP-based web service should have the interface defined in this  standards work together to connect users and applications with
219  specification, as expressed using the standard WSDL (Web Services  providers of data and services, as depicted in the diagram in Fig. 1.
220  Description Language, [10]) format. For RESTful services, the  </p>
221  requirement for the support interface is stated in the specification for  
222   each kind of service. A contract for a RESTful service may specify  <p>
223  extra constraints (e.g., on the form of the URIs) for the support  <center>
224  interface. </p>  <font size="-1">
225    <img src="vosi-in-arch.png" width="756"/> <br />
226    <blockquote>
227  <h3><a name="sec1_2">1.2 The role in the IVOA Architecture</a></h3>  <strong>Figure 1. VOSI in the IVOA Architecture.</strong>
228  <p>The IVOA Architecture [11] provides a high-level view of how IVOA  VOSI is the standard that defines the basic functions that all VO
229  standards work together to connect users and applications with  services should provide in order to support management of the VO.
230  providers of data and services, as depicted in the diagram in Fig. 1.  </blockquote>
231  </p>  </font>
232    </center>
233  <p>  </p>
234  </p><center>  
235  <font size="-1">  <p>In this architecture, users employ a variety of tools (from the
236  <img src="VOSI-v1.0pr4_files/vosi-in-arch.png" width="756"> <br>  User Layer) to discover and access archives and services--that is,
237  <blockquote>  resources--of interest (represented in the Resource Layer).  A
238  <strong>Figure 1. VOSI in the IVOA Architecture.</strong>  registry plays a role in discovery by harvesting metadata that
239  VOSI is the standard that defines the basic functions that all VO  describe archives and services and making them searchable from a
240  services should provide in order to support management of the VO.  central service.  The VOSI interface provides a means for a service to
241  </blockquote>  provide some of this metadata itself; this allows a registry to pull
242  </font>  the metadata from the service rather than relying on a human to
243  </center>  provide it (e.g. by typing the data into a registration form
244    manually).  This mechanism can aake it easier to collect highly
245    detailed metadata (e.g. descriptions of columns in a catalog) that
246  <p>In this architecture, users employ a variety of tools (from the  might not be practically provided otherwise.  As some of this metadata
247  User Layer) to discover and access archives and services--that is,  describes the service interface and how it behaves, other applications
248  resources--of interest (represented in the Resource Layer).  A  can use this information for controlling how they use the service.
249  registry plays a role in discovery by harvesting metadata that  Even when the service is "discovered" through some means other than a
250  describe archives and services and making them searchable from a  registry, an application can still understand how to use the service
251  central service.  The VOSI interface provides a means for a service to  by querying for this information directly.  
252  provide some of this metadata itself; this allows a registry to pull  <p>
253  the metadata from the service rather than relying on a human to  
254  provide it (e.g. by typing the data into a registration form  <p>
255  manually).  This mechanism can make it easier to collect highly  Once a user discovers data and services of interest, she will want to
256  detailed metadata (e.g. descriptions of columns in a catalog) that  use engage them in an analysis process.  Success requires that the selected
257  might not be practically provided otherwise.  As some of this metadata  services are actually up and running properly as a down service can
258  describes the service interface and how it behaves, other applications  cause auotmated processing to fail completely.  Registry and workflow
259  can use this information for controlling how they use the service.  services can assist with this by tracking the availability of
260  Even when the service is "discovered" through some means other than a  services and alerting users about downtime.  We envision that VOSI
261  registry, an application can still understand how to use the service  will allow VO projects to better track the overall health of the VO
262  by querying for this information directly.    ecosystem.
263  </p>  </p>
264    
265  <p>  <h2><a name="sec2">2. Interface bindings</a></h2>
266  Once a user discovers data and services of interest, she will want to  <p>The standard interface returns metadata without changing the
267  use engage them in an analysis process.  Success requires that the selected  state of the service with which it is associated. This could, in principle, be
268  services are actually up and running properly as a down service can  implemented in any of three ways:</p>
269  cause auotmated processing to fail completely.  Registry and workflow  <ol type="1">
270  services can assist with this by tracking the availability of  <li> As extra SOAP operations on an existing SOAP endpoint of the
271  services and alerting users about downtime.  We envision that VOSI    service with which it is associated. This would be a 'SOAP binding' of VOSI.
272  will allow VO projects to better track the overall health of the VO  <li> As SOAP operations on a separate SOAP endpoint. This would be an alternate form of the SOAP binding.
273  ecosystem.  <li> As web resources with distinct URLs, without using the SOAP protocol. This is the 'REST binding' for the standard interface.
274  </p>  </ol><p>
275    This standard requires the REST binding of VOSI even when applied to
276    services that otherwise use SOAP. No details of the SOAP binding are
277  <h2><a name="sec2">2. Interface bindings</a></h2>  given in this version of the standard. </p>
278  <p>The standard interface returns metadata without changing the  <p>
279  state of the service with which it is associated. This could, in principle, be  In the REST binding, the support interfaces shall have distinct URLs
280  implemented in any of three ways:</p>  in the HTTP scheme and shall be accessible by the GET operation in the
281  <ol type="1">  HTTP protocol. The response to an HTTP POST, PUT or DELETE to these
282  <li> As extra SOAP operations on an existing SOAP endpoint of the  resources is not defined by this specification. However, if an
283    service with which it is associated. This would be a 'SOAP binding' of VOSI.  implementation has no special action to perform for these requests,
284  </li><li> As SOAP operations on a separate SOAP endpoint. This would be an alternate form of the SOAP binding.  the normal response would be a HTTP 405 "Method not allowed" status code. </p><p>
285  </li><li> As web resources with distinct URLs, without using the SOAP protocol. This is the 'REST binding' for the standard interface.  The endpoints and interface types for the support interface shall be
286  </li></ol><p>  defined in the service's registration using one <i>Capability</i> element for
287  This standard requires the REST binding of VOSI even when applied to  each interface. The values of the <i>standardID</i> attribute for these <i>Capability</i>s are given in section 4.</p><p>
288  services that otherwise use SOAP. No details of the SOAP binding are  When using the REST binding, any HTTP URLs may be used. The client
289  given in this version of the standard. </p>  must find the appropriate URLs from the service's entry in the VO registry and, in general, should not try and infer the URLs from any other URLs for that service. However, standards for specific services may put extra constraints on the form of the URLs.</p>
290  <p>  </p>
291  In the REST binding, the support interfaces shall have distinct URLs  
292  in the HTTP scheme and shall be accessible by the GET operation in the  
293  HTTP protocol. The response to an HTTP POST, PUT or DELETE to these  <h2><a name="sec3">3. Metadata specification</a></h2>
294  resources is not defined by this specification. However, if an  <p>
295  implementation has no special action to perform for these requests,  There are various classes of metadata that might be returned by a
296  the normal response would be a HTTP 405 "Method not allowed" status code. </p><p>  service through its standard interface:</p>
297  The endpoints and interface types for the support interface shall be  <ul>
298  defined in the service's registration using one <i>Capability</i> element for  <li> those describing its functional capabilities
299  each interface. The values of the <i>standardID</i> attribute for these <i>Capability</i>s are given in section 4.</p><p>  <li> those describing its operational behaviour - availability,
300  When using the REST binding, any HTTP URLs may be used. The client    reliability, etc.
301  must find the appropriate URLs from the service's entry in the VO  <li> those describing tabular data handled by the service
302  registry and, in general, should not try and infer the URLs from any  <li> those describing other aspects of the service
303  other URLs for that service. However, standards for specific services  </ul>
304  may put extra constraints on the form of the URLs.</p>  <p>This section defines how each of these classes is represented. The
305    following typographic convention is used to represent a XML element defined
306    within a particular namespace:</p>
307    <pre>
308  <h2><a name="sec3">3. Metadata specification</a></h2>  {http://some.name.space}elementName
309  <p>  </pre>
310  There are various classes of metadata that might be returned by a  <p>For example,
311  service through its standard interface:</p>  <i>{http://www.ivoa.net/xml/VOResource/v1.0}resource</i> indicates a
312  <ul>  XML element named <i>resource</i> that is described in the XML schema
313  <li> those describing its functional capabilities  associated with the 'http://www.ivoa.net/xml/VOResource/v1.0'
314  </li><li> those describing its operational behaviour - availability,  namespace - in this case, this would be VOResource.xsd [12].
315    reliability, etc.  </p>
316  </li><li> those describing tabular data handled by the service  
317  </li><li> those describing other aspects of the service  <h3><a name="sec3_1">3.1 Capability metadata</a></h3>
318  </li></ul>  
319  <p>This section defines how each of these classes is represented. The  <p></p
320  following typographic convention is used to represent a XML element defined  <blockquote>
321  within a particular namespace:</p>  <table bgcolor="#dddddd" border="2" cellpadding="5"><tbody><tr><td>
322  <pre>{http://some.name.space}elementName  <dl style="margin-top: 0pt; margin-bottom: 0pt">
323  </pre>    <dt> <strong>Note:</strong> </dt>
324  <p>For example,    <dd>'Capability' is unfortunately an overloaded term in the VO
325  <i>{http://www.ivoa.net/xml/VOResource/v1.0}resource</i> indicates a      referring to both a functional aspect of a service
326  XML element named <i>resource</i> that is described in the XML schema      and also particular pieces of metadata defined by various XML
327  associated with the 'http://www.ivoa.net/xml/VOResource/v1.0'      schema. When referring to an XML element called 'capability', it
328  namespace - in this case, this would be VOResource.xsd [12].      shall be be put in italics. Its parent namespace may also be
329  </p>      included (using the syntax described above) if it is ambiguous
330        which XML schema is being referred to.
331  <h3><a name="sec3_1">3.1 Capability metadata</a></h3>    </dd>
332    </dl>
333  <p></p><blockquote>  </td></tr></tbody></table>
334  <table bgcolor="#dddddd" border="2" cellpadding="5"><tbody><tr><td>  </blockquote>
335  <dl style="margin-top: 0pt; margin-bottom: 0pt;">  <p></p>
336    <dt> <strong>Note:</strong> </dt>  
337    <dd>'Capability' is unfortunately an overloaded term in the VO  <p>This interface provides the service metadata in the form of a list
338      referring to both a functional aspect of a service  of <i>Capability</i> descriptions. Each of these descriptions is an XML element that: </p>
339      and also particular pieces of metadata defined by various XML  <ul>
340      schema. When referring to an XML element called 'capability', it    <li> states that the service provides a particular, IVOA-standard function;
341      shall be be put in italics. Its parent namespace may also be    <li> lists the interfaces for invoking that function;
342      included (using the syntax described above) if it is ambiguous   <li> records any details of the implementation of the function that
343      which XML schema is being referred to.    are not defined as default or constant in the standard for that function.
344    </dd>    </ul>
345  </dl>    <p>
346  </td></tr></tbody></table>  For example, one capability might describe a cone search function and
347  </blockquote>    another the TAP implementation but these two might well apply to the same service.</p><p>
348  <p></p>  An entry for a service in the resource registry - i.e., its VOResource
349      - contains the Dublin Core resource metadata (identifier, curation
350  <p>This interface provides the service metadata in the form of a list    information, content description, etc.) followed by the service's
351  of <i>Capability</i> descriptions. Each of these descriptions is an XML element that: </p>    capability descriptions (expressed as a series of
352  <ul>    <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i> elements). Effectively, the resource metadata describes the service to human users and the capability list describes it to software. Therefore, the latter list has two uses:</p>
353    <li> states that the service provides a particular, IVOA-standard function;  <ul><li>it may be read by a client application to find out how to invoke the service. This presumes that the service has been already been selected and the VOSI endpoint located.
354    </li><li> lists the interfaces for invoking that function;  <li>it may be read by the registry itself to compile the registry entry for the service. In this case, the resource metadata are entered into the registry directly and the service metadata are then read from the service. Since the service implementation usually knows its capabilities, this removes the need for a human to type them into the registry.
355   </li><li> records any details of the implementation of the function that  </ul></p>
356    are not defined as default or constant in the standard for that function.  
357    </li></ul>  <p>
358    <p>  The service metadata shall be represented as an XML document with the
359  For example, one capability might describe a cone search function and  root element
360    another the TAP implementation but these two might well apply to the same service.</p><p>  <i>{http://www.ivoa.net/xml/VOSICapabilities/v1.0}capabilities</i>.
361  An entry for a service in the resource registry - i.e., its VOResource  (See <a href="#appA1">Appendix A.1</a> for the definition of the
362    - contains the Dublin Core resource metadata (identifier, curation  VOSICapabilities XML schema.)  This element must contain one or more child
363    information, content description, etc.) followed by the service's  <i>capability</i> elements that describe the capabilities of the
364    capability descriptions (expressed as a series of  service.  Given that the <i>capability</i> element is defined to be of type
365    <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i> elements).  <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i>, a <i>capability</i>
366  Effectively, the resource metadata describes the service to human users  element may be represented by a legal sub-type of
367  and the capability list describes it to software. Therefore, the latter  <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i>, in which
368  list has two uses:</p>  case, the <i>capability</i> element must use an <i>xsi:type</i>
369  <ul><li>it may be read by a client application to find out how to invoke  attribute to identify the sub-type (see section 2.2.1 of
370   the service. This presumes that the service has been already been  [<a href="#ref:vor">1</a>]).
371  selected and the VOSI endpoint located.  </p>
372  </li><li>it may be read by the registry itself to compile the registry  
373  entry for the service. In this case, the resource metadata are entered  <p></p
374  into the registry directly and the service metadata are then read from  <blockquote>
375  the service. Since the service implementation usually knows its  <table bgcolor="#dddddd" border="2" cellpadding="5"><tbody><tr><td>
376  capabilities, this removes the need for a human to type them into the  <dl style="margin-top: 0pt; margin-bottom: 0pt">
377  registry.    <dt> <strong>Note:</strong> </dt>
378  </li></ul>    <dd> The value of the <i>capability</i> element's standardID attribute is used
379       to indicate the service's support for particular standard protocols
380  <p>     (such as Simple Image Access, Simple Cone Search, etc.).  In the
381  The service metadata shall be represented as an XML document with the     case of some protocols, the support for the standard is further
382  root element     characterized by additional metadata provided by a standard XML
383  <i>{http://www.ivoa.net/xml/VOSICapabilities/v1.0}capabilities</i>.      schema extension of <i>Capability</i> for that protocol. The extension metadata is enabled by
384  (See <a href="#appA1">Appendix A.1</a> for the definition of the     adding a <i>xsi:type</i> attribute to the <i>capability</i> element set to the
385  VOSICapabilities XML schema.)  This element must contain one or more child     <i>Capability</i> sub-type value defined in the extension schema for that protocol (see the examples in <a href="#sec5">section 5</a> below).  </dd>
386  <i>capability</i> elements that describe the capabilities of the  </dl>
387  service.  Given that the <i>capability</i> element is defined to be of type  </td></tr></tbody></table>
388  <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i>, a <i>capability</i>  </blockquote>
389  element may be represented by a legal sub-type of  <p></p>
390  <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i>, in which  
391  case, the <i>capability</i> element must use an <i>xsi:type</i>  <p>
392  attribute to identify the sub-type (see section 2.2.1 of  The VOResource list of capabilities should include capabilities describing VOSI
393  [<a href="#ref:vor">1</a>]).  endpoints as specified in <a href="#sec4">section 4</a>.
394  </p>  </p>
395    
396  <p></p><blockquote>  
397  <table bgcolor="#dddddd" border="2" cellpadding="5"><tbody><tr><td>  <p>
398  <dl style="margin-top: 0pt; margin-bottom: 0pt;">  In the REST binding, the service metadata shall be a single web
399    <dt> <strong>Note:</strong> </dt>  resource with a registered URL. The date and time at which the
400    <dd> The value of the <i>capability</i> element's standardID attribute is used  metadata last changed shall be obtained from the <i>Last-Modified</i>
401     to indicate the service's support for particular standard protocols  HTTP Header keyword sent in the response to a GET or HEAD request to the registered URI.</p><p>
402     (such as Simple Image Access, Simple Cone Search, etc.).  In the  All VO services should provide this interface.
403     case of some protocols, the support for the standard is further  </p>
404     characterized by additional metadata provided by a standard XML  
405      schema extension of <i>Capability</i> for that protocol. The extension metadata is enabled by  <h3><a name="sec3_2">3.2 Non-service metadata (non-normative)</a></h3>
406     adding a <i>xsi:type</i> attribute to the <i>capability</i> element set to the  <p>There may be other metadata associated with a service than the capability metadata described above.
407     <i>Capability</i> sub-type value defined in the extension schema for that protocol (see example below).  </dd>  <ul><li> Every service has the Dublin Core resource metadata [13].
408  </dl>  <li> Some services are associated with registered applications.
409  </td></tr></tbody></table>  <li> Some services are associated with registered data collections.
410  </blockquote>  </ul></p><p>None of these are explicitly provided for in this version of VOSI. Some might be covered in later versions of VOSI.
411  <p></p>  </p>
412    
413  <p>  <h3><a name="sec3_3">3.3 Availability metadata</a></h3>
414  The VOResource list of capabilities should include capabilities describing VOSI  <p>This interface indicates whether the service is operable and the reliability of the service for extended and scheduled requests.
415  endpoints as specified in section 4.  The availability shall be represented as an XML document in which the
416  </p>  root element is <i>{http://www.ivoa.net/xml/Availability/v1.0}availability</i>. This element
417    shall contain child elements providing the following information.</p>
418    <ul>
419  <p>  <li> <i>available</i> - whether the service is currently accepting requests
420  In the REST binding, the service metadata shall be a single web  <li> <i>upSince</i> - duration for which the service has been continuously available
421  resource with a registered URL. The date and time at which the  <li> <i>downAt</i> - the instant at which the service is next scheduled to be unavailable
422  metadata last changed shall be obtained from the <i>Last-Modified</i>  <li> <i>backAt</i> - the instant at which the service is scheduled to become available again after down time;
423  HTTP Header keyword sent in the response to a GET or HEAD request to the registered URI.</p><p>  <li> <i>note</i> - textual note, e.g. explaining the reason for unavailaility.
424  All VO services should provide this interface.  </ul><p>
425  </p>    The elements <i>upSince</i>, <i>downAt</i>, <i>backAt</i> and <i>note</i> are optional. The <i>available</i> element is mandatory. There may be more than one <i>note</i> element.</p><p>
426    The XML document shall conform to the schema given in appendix A.2 of this specification.</p><p>
427  <h3><a name="sec3_2">3.2 Non-service metadata (non-normative)</a></h3>  When reporting availability, the service should do a good check on its underlying parts to see if it is still operational and not just make a simple return from a web server, e.g., if it relies on a database it should check that the database is still up. If any of these checks fail, the service should set <i>available</i> to false in the availability output.</p><p>
428  <p>There may be other metadata associated with a service than the capability metadata described above.  If a service is to be online but unavailable for work (e.g., when a service with a work queue intends to shut down after draining the queue) then the service should set <i>available</i> to false.</p><p>
429  </p><ul><li> Every service has the Dublin Core resource metadata [13].  There are no special elements in the availability document for the
430  </li><li> Some services are associated with registered applications.  contact details of the service operator. These details may be given as
431  </li><li> Some services are associated with registered data collections.  a <i>note</i> element if they are known to the service.</p>
432  </li></ul><p>None of these are explicitly provided for in this version of VOSI. Some might be covered in later versions of VOSI.  <p>
433  </p>  In the REST binding, the availability shall be a single web resource with a registered URL</p><p>
434    All VO services shall provide this interface.
435  <h3><a name="sec3_3">3.3 Availability metadata</a></h3>  </p>
436  <p>This interface indicates whether the service is operable and the  
437  reliability of the service for extended and scheduled requests.  <h3><a name="sec3_4">3.4 Table metadata</a></h3>
438  The availability shall be represented as an XML document in which the  <p>
439  root element is <i>{http://www.ivoa.net/xml/Availability/v1.0}availability</i>. This element  Some services deal with tabular data. These data may be the target of
440  shall contain child elements providing the following information.</p>  ADQL queries, as in TAP [14], or they may be the output of other operations, as in SIAP queries. In each case, it is useful if the service describes the details of the tables concerned. It is more useful if this description can be captured in the resource registry.</p><p>
441  <ul>  The <i>VODataService</i> standard [<a href="#ref:vos">2</a>] defines XML elements for describing a set of tables. These elements can be included in a resource document for a service.</p><p>
442  <li> <i>available</i> - whether the service is currently accepting requests  A service which uses tables in its interface should define a VOSI
443  </li><li> <i>upSince</i> - duration for which the service has been continuously available  endpoint from which table metadata can be read. The table metadata
444  </li><li> <i>downAt</i> - the instant at which the service is next scheduled to be unavailable  shall be represented as an XML document  of which the root element is
445  </li><li> <i>backAt</i> - the instant at which the service is scheduled to become available again after down time;  of type
446  </li><li> <i>note</i> - textual note, e.g. explaining the reason for unavailaility.  <i>{http://www.ivoa.net/xml/VODataService/v1.1}TableSet</i>. This
447  </li></ul><p>  element may contain any mix of elements allowed by the VODataService
448    The elements <i>upSince</i>, <i>downAt</i>, <i>backAt</i> and <i>note</i> are optional. The <i>available</i> element is mandatory. There may be more than one <i>note</i> element.</p><p>  XML schema.</p><p>
449  The XML document shall conform to the schema given in appendix A.2 of this specification.</p><p>  In the REST binding, the table metadata shall be a single web resource with a registered URL.
450  When reporting availability, the service should do a good check on its  </p>
451  underlying parts to see if it is still operational and not just make a  
452  simple return from a web server, e.g., if it relies on a database it  <h2><a name="sec4">4. Registration of VOSI endpoints</a></h2>
453  should check that the database is still up. If any of these checks fail,  <p>
454   the service should set <i>available</i> to false in the availability output.</p><p>  The endpoints for the service and availability metadata shall be
455  If a service is to be online but unavailable for work (e.g., when a  included in the registration of each service that provides them.
456  service with a work queue intends to shut down after draining the queue)  </p>
457   then the service should set <i>available</i> to false.</p><p>  <center>
458  There are no special elements in the availability document for the  <table>
459  contact details of the service operator. These details may be given as    <tr><th align="left">Endpoint type</th><th align="left">standardID value</th></tr>
460  a <i>note</i> element if they are known to the service.</p>    <tr><td>availability</td><td>ivo://ivoa.net/std/VOSI#availability</td></tr>
461  <p>    <tr><td>capabilties</td><td>ivo://ivoa.net/std/VOSI#capabilities</td></tr>
462  In the REST binding, the availability shall be a single web resource with a registered URL</p><p>    <tr><td>tables</td><td>ivo://ivoa.net/std/VOSI#tables</td></tr>
463  All VO services shall provide this interface.    </table>
464  </p>    </center>
465    <p>
466  <h3><a name="sec3_4">3.4 Table metadata</a></h3>  An availability endpoint shall be represented by an element named
467  <p>  <i>capability</i>, of type
468  Some services deal with tabular data. These data may be the target of  <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i> (defined by
469  ADQL queries, as in TAP [7], or they may be the output of other  the standard VOResource XML schema [<a href="ref:vor">1</a>]). The
470  operations, as in SIAP queries. In each case, it is useful if the  value of the <i>standardID</i> attribute of the <i>capability</i>
471  service describes the details of the tables concerned. It is more useful  shall be <i>ivo://ivoa.net/std/VOSI#availability</i>.
472   if this description can be captured in the resource registry.</p><p>  </p>
473  The <i>VODataService</i> standard [<a href="#ref:14">14</a>] defines XML elements for describing a set of tables. These elements can be included in a resource document for a service.</p><p>  
474  A service which uses tables in its interface should define a VOSI  <p>
475  endpoint from which table metadata can be read. The table metadata  A capabilities endpoint should be represented by  an element named
476  shall be represented as an XML document  of which the root element is    <i>capability</i>, of type
477  of type    <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i>. If such
478  <i>{http://www.ivoa.net/xml/VODataService/v1.1}TableSet</i>. This    a <i>capability</i> is provided then the value of the <i>standardID</i> attribute must be <i>ivo://ivoa.net/std/VOSI#capabilities.</i></p><p>
479  element may contain any mix of elements allowed by the VODataService  A tables endpoint should be represented by an element named
480  XML schema.</p><p>    <i>capability</i>, of type
481  In the REST binding, the table metadata shall be a single web resource with a registered URL.    <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i>. If such
482  </p>    a <i>capability</i> is provided then the value of the <i>standardID</i> attribute must be <i>ivo://ivoa.net/std/VOSI#tables</i>.
483    </p>
484  <h2><a name="sec4">4. Registration of VOSI endpoints</a></h2>  
485  <p>  <p>
486  The endpoints for the service and availability metadata shall be  With all three VOSI functions, the capability element that describes
487  included in the registration of each service that provides them.  the function must contain an interface element of a type semantically
488  </p>  appropriate for the binding of the function to the service; the
489  <center>  <i>accessURL</i> element within the interface element indicates the
490  <table>  endpoint for the VOSI function.  For the REST binding, this
491    <tbody><tr><th align="left">Endpoint type</th><th align="left">standardID value</th></tr>  <i>accessURL</i> element must set the <i>use</i> attribute to "full".
492    <tr><td>availability</td><td>ivo://ivoa.net/std/VOSI#availability</td></tr>  Furthermore, for the REST binding, this document recommends using the
493    <tr><td>capabilties</td><td>ivo://ivoa.net/std/VOSI#capabilities</td></tr>  <i>{http://www.ivoa.net/xml/VODataService/v1.1}ParamHTTP</i> interface
494    <tr><td>tables</td><td>ivo://ivoa.net/std/VOSI#tables</td></tr>  type to encode VOSI endpoints (see examples given in
495    </tbody></table>  <a href="#sec5">section 5</a>).
496    </center>  </p>
497  <p>  
498  An availability endpoint shall be represented by an element named  
499  <i>capability</i>, of type  <h2><a name="sec5">5. Example VOSI responses</a></h2>
500  <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i> (defined by  
 the standard VOResource XML schema [<a href="ref:12">12</a>]). The  
 value of the <i>standardID</i> attribute of the <i>capability</i>  
 shall be <i>ivo://ivoa.net/std/VOSI#availability</i>.  
 </p>  
   
 <p>  
 A capabilities endpoint should be represented by  an element named  
   <i>capability</i>, of type  
   <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i>. If such  
   a <i>capability</i> is provided then the value of the <i>standardID</i> attribute must be <i>ivo://ivoa.net/std/VOSI#capabilities.</i></p><p>  
 A tables endpoint should be represented by an element named  
   <i>capability</i>, of type  
   <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i>. If such  
   a <i>capability</i> is provided then the value of the <i>standardID</i> attribute must be <i>ivo://ivoa.net/std/VOSI#tables</i>.  
 </p>  
   
 <p>  
 With all three VOSI functions, the capability element that describes  
 the function must contain an interface element of a type semantically  
 appropriate for the binding of the function to the service; the  
 <i>accessURL</i> element within the interface element indicates the  
 endpoint for the VOSI function.  For the REST binding, this  
 <i>accessURL</i> element must set the <i>use</i> attribute to "full".  
 Furthermore, for the REST binding, this document recommends using the  
 <i>{http://www.ivoa.net/xml/VODataService/v1.1}ParamHTTP</i> interface  
 type to encode VOSI endpoints (see example given in section 2.1).  
 </p>  
   
   
 <h2><a name="sec5">5. Example VOSI responses</a></h2>  
   
501  <!-- Space to push page break in PDF version  <!-- Space to push page break in PDF version
502  <br />  <br />
503  <br />  <br />
  -->  
   
 <div class="exampleOuter">  
 <a name="ex:caps">  
 </a><div class="exampleHeader">Example 1:</div>  
 <div class="exampleWrapper">A sample response from a capabilities  
 resource describing an SIA service.  </div>  
 <div class="exampleInner" style="background-color: rgb(213, 222, 227);">  
 <pre>&lt;?xml version="1.0" encoding="UTF-8"?&gt;  
 &lt;vosi:capabilities xmlns:vosi="http://www.ivoa.net/xml/VOSICapabilities/v1.0"  
                       xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"  
                       xmlns:vs="http://www.ivoa.net/xml/VODataService/v1.0"  
                       xmlns:sia="http://www.ivoa.net/xml/SIA/v1.0"  
                       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
                       xsi:schemaLocation="http://www.ivoa.net/xml/VOSI/v1.0  
                                           http://www.ivoa.net/xml/VOSI/v1.0  
                                           http://www.ivoa.net/xml/VOResource/v1.0  
                                           http://www.ivoa.net/xml/VOResource/v1.0  
                                           http://www.ivoa.net/xml/VODataService/v1.0  
                                           http://www.ivoa.net/xml/VODataService/v1.0  
                                           http://www.ivoa.net/xml/SIA/v1.0  
                                           http://www.ivoa.net/xml/SIA/v1.0"&gt;  
   
   &lt;!-- a generic capability (for custom, non-standard interfaces) --&gt;  
   &lt;capability&gt;  
     &lt;interface xsi:type="vr:WebBrowser"&gt;  
       &lt;accessURL use="full"&gt; http://adil.ncsa.uiuc.edu/siaform.html &lt;/accessURL&gt;  
     &lt;/interface&gt;  
   &lt;/capability&gt;  
     
   &lt;!-- the SIA capability --&gt;  
   &lt;capability xsi:type="sia:SimpleImageAccess" standardID="ivo://ivoa.net/std/SIA"&gt;  
     &lt;interface xsi:type="vs:ParamHTTP" role="std"&gt;  
       &lt;accessURL&gt; http://adil.ncsa.uiuc.edu/cgi-bin/voimquery?survey=f&amp;amp; &lt;/accessURL&gt;  
     &lt;/interface&gt;  
   
     &lt;imageServiceType&gt;Pointed&lt;/imageServiceType&gt;  
     &lt;maxQueryRegionSize&gt;  
       &lt;long&gt;360.0&lt;/long&gt;  
       &lt;lat&gt;180.0&lt;/lat&gt;  
     &lt;/maxQueryRegionSize&gt;  
     &lt;maxImageExtent&gt;  
       &lt;long&gt;360.0&lt;/long&gt;  
       &lt;lat&gt;180.0&lt;/lat&gt;  
     &lt;/maxImageExtent&gt;  
     &lt;maxImageSize&gt;  
       &lt;long&gt;5000&lt;/long&gt;  
       &lt;lat&gt;5000&lt;/lat&gt;  
     &lt;/maxImageSize&gt;  
     &lt;maxFileSize&gt;100000000&lt;/maxFileSize&gt;  
     &lt;maxRecords&gt;5000&lt;/maxRecords&gt;  
   &lt;/capability&gt;  
   
   &lt;!-- the interface that returns this document --&gt;  
   &lt;capability standardID="ivo://ivoa.net/std/VOSI#capabilities"&gt;  
     &lt;interface xsi:type="vs:ParamHTTP" role="std"&gt;  
       &lt;accessURL use="full"&gt; http://adil.ncsa.uiuc.edu/cgi-bin/voimquery/capabilities &lt;/accessURL&gt;  
     &lt;/interface&gt;  
   &lt;/capability&gt;  
   
   &lt;!-- the interface that returns this document --&gt;  
   &lt;capability standardID="ivo://ivoa.net/std/VOSI#availability"&gt;  
     &lt;interface xsi:type="vs:ParamHTTP" role="std"&gt;  
       &lt;accessURL use="full"&gt; http://adil.ncsa.uiuc.edu/cgi-bin/voimquery/availability &lt;/accessURL&gt;  
     &lt;/interface&gt;  
   &lt;/capability&gt;  
 &lt;/vosi:capabilities&gt;  
 </pre>  
 </div></div>  
 <br>  
 <div class="exampleOuter">  
 <a name="ex:caps">  
 </a><div class="exampleHeader">Example 2:</div>  
 <div class="exampleWrapper">A sample response from a tables  
 resource describing a TAP service.  </div>  
 <div class="exampleInner" style="background-color: rgb(213, 222, 227);">  
 <pre>&lt;?xml version="1.0" encoding="UTF-8"?&gt;  
 &lt;vosi:tableset  
   xmlns:vosi="http://www.ivoa.net/xml/VOSITables/v1.0"  
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
   xmlns:vod="http://www.ivoa.net/xml/VODataService/v1.1"&gt;  
   &lt;schema&gt;  
     &lt;name&gt;cfht &lt;/name&gt;  
     &lt;table type="output"&gt;  
       &lt;name&gt;cfht.deepU &lt;/name&gt;  
       &lt;column&gt;  
         &lt;name&gt;cfhtlsID &lt;/name&gt;  
         &lt;dataType xsi:type="vod:TAP" size="30"&gt;adql:VARCHAR &lt;/dataType&gt;  
       &lt;/column&gt;  
       &lt;column&gt;  
         &lt;name&gt;survey &lt;/name&gt;  
         &lt;dataType xsi:type="vod:TAP" size="6"&gt;adql:VARCHAR &lt;/dataType&gt;  
       &lt;/column&gt;  
       &lt;column&gt;  
         &lt;name&gt;field &lt;/name&gt;  
         &lt;dataType xsi:type="vod:TAP" size="2"&gt;adql:VARCHAR &lt;/dataType&gt;  
       &lt;/column&gt;  
       &lt;column&gt;  
         &lt;name&gt;pointing &lt;/name&gt;  
         &lt;dataType xsi:type="vod:TAP" size="6"&gt;adql:VARCHAR &lt;/dataType&gt;  
       &lt;/column&gt;  
       &lt;column&gt;  
         &lt;name&gt;selectionFilter &lt;/name&gt;  
         &lt;dataType xsi:type="vod:TAP" size="2"&gt;adql:VARCHAR &lt;/dataType&gt;  
       &lt;/column&gt;  
     &lt;/table&gt;  
     &lt;table type="output"&gt;  
       &lt;name&gt;TAP_SCHEMA.keys &lt;/name&gt;  
       &lt;column&gt;  
         &lt;name&gt;key_id &lt;/name&gt;  
         &lt;description&gt;unique key to join to TAP_SCHEMA.key_columns &lt;/description&gt;  
         &lt;dataType xsi:type="vod:TAP" size="64"&gt;adql:VARCHAR &lt;/dataType&gt;  
       &lt;/column&gt;  
       &lt;column&gt;  
         &lt;name&gt;from_table &lt;/name&gt;  
         &lt;description&gt;the table with the foreign key &lt;/description&gt;  
         &lt;dataType xsi:type="vod:TAP" size="64"&gt;adql:VARCHAR &lt;/dataType&gt;  
       &lt;/column&gt;  
       &lt;column&gt;  
         &lt;name&gt;target_table &lt;/name&gt;  
         &lt;description&gt;the table with the primary key &lt;/description&gt;  
         &lt;dataType xsi:type="vod:TAP" size="64"&gt;adql:VARCHAR &lt;/dataType&gt;  
       &lt;/column&gt;  
     &lt;/table&gt;  
   &lt;/schema&gt;  
 &lt;/vosi:tableset&gt;  
 </pre>  
 </div></div>  
   
   
 <br>  
 <h2><a name="appA">Appendix A: VOSI XML schemas</a></h2>  
   
 <a name="appA1">  
 <h3>A.1.  The Complete VOSICapabilities Schema</h3></a>  
   
 <pre>&lt;xsd:schema targetNamespace="http://www.ivoa.net/xml/VOSICapabilities/v1.0"  
             xmlns:tns="http://www.ivoa.net/xml/VOSICapabilities/v1.0"  
             xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"  
             xmlns:xsd="http://www.w3.org/2001/XMLSchema"  
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
             elementFormDefault="qualified"  
             attributeFormDefault="unqualified"  
             version="1.0rc1"&gt;  
   
   &lt;xsd:annotation&gt;  
      &lt;xsd:documentation&gt;  
        A schema for formatting service capabilities as returned by a  
        capabilities resource, defined by the IVOA Support Interfaces  
        specification (VOSI).  
        See http://www.ivoa.net/Documents/latest/VOSI.html.    
      &lt;/xsd:documentation&gt;  
   &lt;/xsd:annotation&gt;  
   
   &lt;xsd:import namespace="http://www.ivoa.net/xml/VOResource/v1.0"  
               schemaLocation="http://www.ivoa.net/xml/VOResource/v1.0" /&gt;  
   
   &lt;!--  
     -  the root element for a VOSI capabilities metadata (section 3.1)  
     --&gt;  
   &lt;xsd:element name="capabilities"&gt;  
      &lt;xsd:annotation&gt;  
        &lt;xsd:documentation&gt;  
          A listing of capabilities supported by a service  
        &lt;/xsd:documentation&gt;  
      &lt;/xsd:annotation&gt;  
   
      &lt;xsd:complexType&gt;  
         &lt;xsd:sequence&gt;  
   
            &lt;xsd:element name="capability" type="vr:Capability"  
                         form="unqualified" minOccurs="0" maxOccurs="unbounded"&gt;  
               &lt;xsd:annotation&gt;  
                 &lt;xsd:documentation&gt;  
                   A capability supported by the service.    
                 &lt;/xsd:documentation&gt;  
                 &lt;xsd:documentation&gt;  
                   A protocol-specific capability is included by specifying a  
                   vr:Capability sub-type via an xsi:type attribute on this  
                   element.  
                 &lt;/xsd:documentation&gt;  
               &lt;/xsd:annotation&gt;  
          &lt;/xsd:element&gt;  
   
       &lt;/xsd:sequence&gt;  
     &lt;/xsd:complexType&gt;  
   &lt;/xsd:element&gt;  
   
 &lt;/xsd:schema&gt;  
 </pre>  
   
 <a name="appA2">  
 <h3>A.2.  The Complete VOSIAvailability Schema</h3></a>  
   
 <pre>&lt;xsd:schema targetNamespace="http://www.ivoa.net/xml/VOSIAvailability/v1.0"  
             xmlns:tns="http://www.ivoa.net/xml/VOSIAvailability/v1.0"  
             xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"  
             xmlns:xsd="http://www.w3.org/2001/XMLSchema"  
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
             elementFormDefault="qualified"  
             attributeFormDefault="unqualified"  
             version="1.0rc1"&gt;  
   
   &lt;xsd:annotation&gt;  
      &lt;xsd:documentation&gt;  
        A schema for formatting availability metadata as returned by an  
        availability resource defined in the IVOA Support Interfaces  
        specification (VOSI).  
        See http://www.ivoa.net/Documents/latest/VOSI.html.    
      &lt;/xsd:documentation&gt;  
   &lt;/xsd:annotation&gt;  
   
   &lt;!--  
     -  the root element for a VOSI availability (section 3.3)  
     --&gt;  
   &lt;xsd:element name="availability" type="tns:Availability"/&gt;  
   
   &lt;xsd:complexType name="Availability"&gt;  
     &lt;xsd:sequence&gt;  
         
       &lt;xsd:element name="available" type="xsd:boolean"&gt;  
         &lt;xsd:annotation&gt;  
           &lt;xsd:documentation&gt;  
              Indicates whether the service is currently available.  
            &lt;/xsd:documentation&gt;  
         &lt;/xsd:annotation&gt;  
       &lt;/xsd:element&gt;  
   
       &lt;xsd:element name="upSince" type="xsd:dateTime" minOccurs="0"&gt;  
         &lt;xsd:annotation&gt;  
           &lt;xsd:documentation&gt;  
             The instant at which the service last became available.  
           &lt;/xsd:documentation&gt;  
         &lt;/xsd:annotation&gt;  
       &lt;/xsd:element&gt;  
   
       &lt;xsd:element name="downAt" type="xsd:dateTime" minOccurs="0"&gt;  
         &lt;xsd:annotation&gt;  
           &lt;xsd:documentation&gt;  
             The instant at which the service is next scheduled to become  
             unavailable.  
           &lt;/xsd:documentation&gt;  
         &lt;/xsd:annotation&gt;  
       &lt;/xsd:element&gt;  
   
       &lt;xsd:element name="backAt" type="xsd:dateTime" minOccurs="0"&gt;  
         &lt;xsd:annotation&gt;  
           &lt;xsd:documentation&gt;  
             The instant at which the service is scheduled to become available  
             again after a period of unavailability.  
           &lt;/xsd:documentation&gt;  
         &lt;/xsd:annotation&gt;  
       &lt;/xsd:element&gt;  
   
       &lt;xsd:element name="note" type="xsd:string"  
                    minOccurs="0" maxOccurs="unbounded"&gt;  
         &lt;xsd:annotation&gt;  
           &lt;xsd:documentation&gt;  
             A textual note concerning availability.  
           &lt;/xsd:documentation&gt;  
         &lt;/xsd:annotation&gt;  
       &lt;/xsd:element&gt;  
   
     &lt;/xsd:sequence&gt;  
   &lt;/xsd:complexType&gt;  
   
 &lt;/xsd:schema&gt;  
 </pre>  
   
 <a name="appA3">  
 <h3>A.3.  The Complete VOSITables Schema</h3></a>  
 <pre>&lt;xsd:schema targetNamespace="http://www.ivoa.net/xml/VOSICapabilities/v1.0"  
   xmlns:tns="http://www.ivoa.net/xml/VOSICapabilities/v1.0"  
   xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"  
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"  
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
   elementFormDefault="qualified"  
   attributeFormDefault="unqualified"  
   version="1.0"&gt;  
   
   &lt;xsd:annotation&gt;  
     &lt; xsd:documentation&gt;  
      A schema for formatting table metadata as returned by a  
      tables resource, defined by the IVOA Support Interfaces  
      specification (VOSI).  
      See http://www.ivoa.net/Documents/latest/VOSI.html.    
     &lt;/xsd:documentation&gt;  
   &lt;/xsd:annotation&gt;  
   
   &lt;xsd:import namespace="http://www.ivoa.net/xml/VODataService/v1.1"  
     schemaLocation="http://www.ivoa.net/xml/VODataService/v1.1" /&gt;  
   
   &lt;!--  
     -  the root element for a VOSI table metadata (section 3.4)  
     --&gt;  
   &lt;xsd:element name="tableset" type="vs:TableSet" &gt;  
     &lt;xsd:annotation&gt;  
       &lt;xsd:documentation&gt;  
         A description of the table metadata supported by the  
         service associated with a VOSI-enabled resource.  
       &lt;/xsd:documentation&gt;  
     &lt;/xsd:annotation&gt;  
   &lt;/xsd:element&gt;  
   
 &lt;/xsd:schema&gt;  
 </pre>  
 <br>  
 <h2><a name="appB">Applendix B: Changes from previous versions</a></h2>  
   
 <h4>Changes since PR-20100311</h4>  
 <ul>  
   <li>Inclusion of IVOA Architecture text </li>  
   <li>Restructuring and clarification in response to RFC comments</li>  
   <li>Inclusion of VOSITables schema in appendix</li>  
   <li>Second example added for a TAP service response</li>  
   </ul>  
   
 <h4>Changes since WD-20090825</h4>  
   
 <ul>  
   <li> Mandate the use of VOSICapabilities to return capabilities </li>  
   <li> S2.1: added non-normative note about capability sub-types;  added  
        example capabilities metadata </li>  
   <li> Recommend the inclusion of VOSI interfaces in capability metadata</li>  
   <li> S2.5:  When returning capabilities metadata, require VOSI (REST)  
        accessURLs to have use="full"; recommend this use of ParamHTTP. </li>  
   <li> Rename Availability schema to VOSIAvailability; added  
        VOSICapabilities schema. </li>  
 </ul>  
   
 <h4>Changes since WD-20081030</h4>  
   
 <p>The REST binding is made mandatory for all kinds of service. Details  
 of the SOAP binding, including its WSDL contract, are removed.</p><p>  
 The definition of the root element for the table-metadata document is corrected. Instead of requiring the <i>tableset</i> element from <i>VODataService 1.1</i> (which element does not exist in that schema), the text now requires an element of type <i>TableSet</i>.  
 </p>  
   
 <br>  
 <h2><a name="ref">References</a></h2>  
   
 <dl>  
   
   
   <dt> <a name="ref:0">[0]</a> </dt>  
   <dd> <cite>  
        <a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119</a></cite>,  
        <code>http://www.ietf.org/rfc/rfc2119.txt</code>  
        </dd>  
   
     
   <dt> <a name="ref:1">[1]</a> </dt>  
   <dd> <cite>  
        <a href="http://www.w3.org/TR/soap">Simple Object Access  
   Protocol (SOAP)</a></cite>,  
        <code>http://www.w3.org/TR/soap</code>  
        </dd>  
   
         
   <dt> <a name="ref:2">[2]</a> </dt>  
   <dd> <cite>  
        <a href="http://voservices.net/">Footprint and spectrum services</a></cite>,  
        <code>http://voservices.net</code>  
        </dd>  
   
   <dt> <a name="ref:3">[3]</a> </dt>  
   <dd> <cite>  
        <a href="http://openskyquery.net/">Skynodes and Open SkyQuery</a></cite>,  
        <code>http://openskyquery.net</code>  
        </dd>  
   
   <dt> <a name="ref:4">[4]</a></dt><dd>Benson, K., Plante, R., Auden, E.,  
   Graham, M., Greene, G., Hill, M., Linde, T., Morris, D., O'Mullane,  
   W., Rixon, G., Stébé, A., Andrews, K., 2009, <cite>  
        <a href="http://www.ivoa.net/Documents/RegistryInterface">IVOA  
   Registry Interfaces</a></cite>, v1.0, IVOA Recommendation,  
        <code>http://www.ivoa.net/Documents/RegistryInterface</code>  
        </dd>  
   
   <dt> <a name="ref:5">[5]</a> </dt>  
   <dd> <cite>  
        <a href="http://cdsweb.u-strasbg.fr/cdsws.gml">CDS web services</a></cite>,  
        <code>http://cdsweb.u-strasbg.fr/cdsws.gml</code>  
        </dd>  
   
   <dt> <a name="ref:6">[6]</a> </dt>  
   <dd> <cite>  
        <a href="http://en.wikipedia.org/wiki/Representational_State_Transfer">REpresentational State Transfer (REST)</a></cite>,  
        <code>http://en.wikipedia.org/wiki/Representational_State_Transfer</code>  
        </dd>  
   
   <dt> <a name="ref:7">[7]</a> </dt>  
   <dd> Dowler, P., Rixon, G., Tody, D., 2010, <cite>  
        <a href="http://www.ivoa.net/Documents/TAP/20100327/REC-TAP-1.0.html">Table  
   Access Protocol</a></cite>, v1.0, IVOA Recommmendation,  
        <code>http://www.ivoa.net/Documents/TAP/20100327/REC-TAP-1.0.html</code>  
        </dd>  
   
   <dt> <a name="ref:8">[8]</a> </dt>  
   <dd> Graham, M., Morris, D., Rixon, G., Dowler, P., Schaaff, A.,  
   Tody, D., 2010, <cite>  
        <a href="http://www.ivoa.net/Documents/VOSpace/20101112/WD-VOSpace-2.0-20101112.html">VOSpace  
   specification</a></cite>, v2.00, IVOA Working Draft,  
        <code>http://www.ivoa.net/Documents/VOSpace/20101112/WD-VOSpace-2.0-20101112.html</code>  
        </dd>  
   
   <dt> <a name="ref:9">[9]</a> </dt>  
   <dd> Grid and Web Services Working Group, 2010, <cite>  
        <a href="http://www.ivoa.net/Documents/VOSI/20100311/PR-VOSI-1.0-20100311.html">IVOA  
   Support Interfaces</a></cite>, v1.00, IVOA Proposed Recommendation,  
       <code>http://www.ivoa.net/Documents/VOSI/20100311/PR-VOSI-1.0-20100311.html</code>  
        </dd>  
   
   <dt> <a name="ref:10">[10]</a> </dt>  
   <dd> <cite>  
        <a href="http://www.w3.org/TR/WSDL">Web Services Description Language</a></cite>,  
        <code>http://www.w3.org/TR/WSDL</code>  
        </dd>  
   
   <dt> <a name="ref:11">[11]</a> </dt>  
   <dd> Arviset, C., Gaudet, S., IVOA Technical Coordination Group,  
   2010, <cite>  
        <a href="http://www.ivoa.net/Documents/Notes/IVOAArchitecture/20101123/IVOAArchitecture-1.0-20101123.pdf">IVOA  
   Architecture</a></cite>, v1.0, IVOA Note,  
        <code>http://www.ivoa.net/Documents/Notes/IVOAArchitecture/20101123/IVOAArchitecture-1.0-20101123.pdf</code>  
        </dd>  
   
   <dt> <a name="ref:12">[12]</a> </dt>  
   <dd> Plante, R., Benson, K., Graham, M., Greene,  
        G., Harrison, P., Lemson, G., Linde, T., Rixon,  
        G., Stébé, A., 2008, <cite>  
        <a href="http://www.ivoa.net/Documents/cover/VOResource-20080222.html">  
        VOResource: an XML Encoding Schema for Resource Metadata</a></cite>,  
        v1.03, IVOA Recommendation,  
        <code>http://www.ivoa.net/Documents/cover/VOResource-20080222.html</code>  
        </dd>  
   
   <dt> <a name="ref:13">[13]</a> </dt>  
   <dd> Hanisch, R., IVOA Registry Working Group, NVO Metadata Working  
   Group, 2007, <cite>  
        <a href="http://www.ivoa.net/Documents/REC/ResMetadata/RM-20070302.html">Resource  
   Metadata for the Virtual Observatory</a></cite>, v.1.12, IVOA Recommendation  
        <code>http://www.ivoa.net/Documents/REC/ResMetadata/RM-20070302.html</code>  
        </dd>  
   
   <dt> <a name="ref:14">[14]</a> </dt>  
   <dd>Plante, R., Stébé, A., Benson, K., Dowler, P., Graham, M., Greene,  
        G., Harrison, P., Lemson, G., Linde, T., Rixon,  
        G., IVOA Registry Working Group, 2010, <cite>  
        <a href="http://www.ivoa.net/Documents/VODataService/20100916/PR-VODataService-1.1-20100916.html">VODataService: a VOResource Schema Extension  
   for Describing Collections and Services</a></cite>, v1.1, IVOA  
   Proposed Recommendation,  
        <code>http://www.ivoa.net/Documents/VODataService/20100916/PR-VODataService-1.1-20100916.html</code>  
        </dd>  
   
 </dl>  
   
   
   
 </body></html>  
504     -->
505    
506    <div class="exampleOuter">
507    <a name="ex:caps">
508    </a><div class="exampleHeader">Example 1:</div>
509    <div class="exampleWrapper">A sample response from a capabilities
510    resource describing an SIA service.  </div>
511    <div class="exampleInner" style="background-color: rgb(213, 222, 227);">
512    <pre>&lt;?xml version="1.0" encoding="UTF-8"?&gt;
513    &lt;vosi:capabilities xmlns:vosi="http://www.ivoa.net/xml/VOSICapabilities/v1.0"
514                          xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
515                          xmlns:vs="http://www.ivoa.net/xml/VODataService/v1.0"
516                          xmlns:sia="http://www.ivoa.net/xml/SIA/v1.0"
517                          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
518                          xsi:schemaLocation="http://www.ivoa.net/xml/VOSI/v1.0
519                                              http://www.ivoa.net/xml/VOSI/v1.0
520                                              http://www.ivoa.net/xml/VOResource/v1.0
521                                              http://www.ivoa.net/xml/VOResource/v1.0
522                                              http://www.ivoa.net/xml/VODataService/v1.0
523                                              http://www.ivoa.net/xml/VODataService/v1.0
524                                              http://www.ivoa.net/xml/SIA/v1.0
525                                              http://www.ivoa.net/xml/SIA/v1.0"&gt;
526    
527      &lt;!-- a generic capability (for custom, non-standard interfaces) --&gt;
528      &lt;capability&gt;
529        &lt;interface xsi:type="vr:WebBrowser"&gt;
530          &lt;accessURL use="full"&gt; http://adil.ncsa.uiuc.edu/siaform.html &lt;/accessURL&gt;
531        &lt;/interface&gt;
532      &lt;/capability&gt;
533      
534      &lt;!-- the SIA capability --&gt;
535      &lt;capability xsi:type="sia:SimpleImageAccess" standardID="ivo://ivoa.net/std/SIA"&gt;
536        &lt;interface xsi:type="vs:ParamHTTP" role="std"&gt;
537          &lt;accessURL&gt; http://adil.ncsa.uiuc.edu/cgi-bin/voimquery?survey=f&amp;amp; &lt;/accessURL&gt;
538        &lt;/interface&gt;
539    
540        &lt;imageServiceType&gt;Pointed&lt;/imageServiceType&gt;
541        &lt;maxQueryRegionSize&gt;
542          &lt;long&gt;360.0&lt;/long&gt;
543          &lt;lat&gt;180.0&lt;/lat&gt;
544        &lt;/maxQueryRegionSize&gt;
545        &lt;maxImageExtent&gt;
546          &lt;long&gt;360.0&lt;/long&gt;
547          &lt;lat&gt;180.0&lt;/lat&gt;
548        &lt;/maxImageExtent&gt;
549        &lt;maxImageSize&gt;
550          &lt;long&gt;5000&lt;/long&gt;
551          &lt;lat&gt;5000&lt;/lat&gt;
552        &lt;/maxImageSize&gt;
553        &lt;maxFileSize&gt;100000000&lt;/maxFileSize&gt;
554        &lt;maxRecords&gt;5000&lt;/maxRecords&gt;
555      &lt;/capability&gt;
556    
557      &lt;!-- the interface that returns this document --&gt;
558      &lt;capability standardID="ivo://ivoa.net/std/VOSI#capabilities"&gt;
559        &lt;interface xsi:type="vs:ParamHTTP" role="std"&gt;
560          &lt;accessURL use="full"&gt; http://adil.ncsa.uiuc.edu/cgi-bin/voimquery/capabilities &lt;/accessURL&gt;
561        &lt;/interface&gt;
562      &lt;/capability&gt;
563    
564      &lt;!-- the interface that returns this document --&gt;
565      &lt;capability standardID="ivo://ivoa.net/std/VOSI#availability"&gt;
566        &lt;interface xsi:type="vs:ParamHTTP" role="std"&gt;
567          &lt;accessURL use="full"&gt; http://adil.ncsa.uiuc.edu/cgi-bin/voimquery/availability &lt;/accessURL&gt;
568        &lt;/interface&gt;
569      &lt;/capability&gt;
570    &lt;/vosi:capabilities&gt;
571    </pre>
572    </div></div>
573    <br/>
574    <div class="exampleOuter">
575    <a name="ex:caps">
576    </a><div class="exampleHeader">Example 2:</div>
577    <div class="exampleWrapper">A sample response from a tables
578    resource describing a TAP service.  </div>
579    <div class="exampleInner" style="background-color: rgb(213, 222, 227);">
580    <pre>
581    &lt;?xml version="1.0" encoding="UTF-8"?>
582    &lt;vosi:tableset
583      xmlns:vosi="http://www.ivoa.net/xml/VOSITables/v1.0"
584      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
585      xmlns:vod="http://www.ivoa.net/xml/VODataService/v1.1">
586      &lt;schema>
587        &lt;name>cfht &lt;/name>
588        &lt;table type="output">
589          &lt;name>cfht.deepU &lt;/name>
590          &lt;column>
591            &lt;name>cfhtlsID &lt;/name>
592            &lt;dataType xsi:type="vod:TAP" size="30">adql:VARCHAR &lt;/dataType>
593          &lt;/column>
594          &lt;column>
595            &lt;name>survey &lt;/name>
596            &lt;dataType xsi:type="vod:TAP" size="6">adql:VARCHAR &lt;/dataType>
597          &lt;/column>
598          &lt;column>
599            &lt;name>field &lt;/name>
600            &lt;dataType xsi:type="vod:TAP" size="2">adql:VARCHAR &lt;/dataType>
601          &lt;/column>
602          &lt;column>
603            &lt;name>pointing &lt;/name>
604            &lt;dataType xsi:type="vod:TAP" size="6">adql:VARCHAR &lt;/dataType>
605          &lt;/column>
606          &lt;column>
607            &lt;name>selectionFilter &lt;/name>
608            &lt;dataType xsi:type="vod:TAP" size="2">adql:VARCHAR &lt;/dataType>
609          &lt;/column>
610        &lt;/table>
611        &lt;table type="output">
612          &lt;name>TAP_SCHEMA.keys &lt;/name>
613          &lt;column>
614            &lt;name>key_id &lt;/name>
615            &lt;description>unique key to join to TAP_SCHEMA.key_columns &lt;/description>
616            &lt;dataType xsi:type="vod:TAP" size="64">adql:VARCHAR &lt;/dataType>
617          &lt;/column>
618          &lt;column>
619            &lt;name>from_table &lt;/name>
620            &lt;description>the table with the foreign key &lt;/description>
621            &lt;dataType xsi:type="vod:TAP" size="64">adql:VARCHAR &lt;/dataType>
622          &lt;/column>
623          &lt;column>
624            &lt;name>target_table &lt;/name>
625            &lt;description>the table with the primary key &lt;/description>
626            &lt;dataType xsi:type="vod:TAP" size="64">adql:VARCHAR &lt;/dataType>
627          &lt;/column>
628        &lt;/table>
629      &lt;/schema>
630    &lt;/vosi:tableset>
631    </pre>
632    </div></div>
633    
634    
635    <br/>
636    <h2><a name="appA">Appendix A: VOSI XML schemas</a></h2>
637    
638    <a name="appA1">
639    <h3>A.1.  The Complete VOSICapabilities Schema</h3></a>
640    
641    <pre>&lt;xsd:schema targetNamespace="http://www.ivoa.net/xml/VOSICapabilities/v1.0"
642                xmlns:tns="http://www.ivoa.net/xml/VOSICapabilities/v1.0"
643                xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
644                xmlns:xsd="http://www.w3.org/2001/XMLSchema"
645                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
646                elementFormDefault="qualified"
647                attributeFormDefault="unqualified"
648                version="1.0rc1"&gt;
649    
650      &lt;xsd:annotation&gt;
651         &lt;xsd:documentation&gt;
652           A schema for formatting service capabilities as returned by a
653           capabilities resource, defined by the IVOA Support Interfaces
654           specification (VOSI).
655           See http://www.ivoa.net/Documents/latest/VOSI.html.  
656         &lt;/xsd:documentation&gt;
657      &lt;/xsd:annotation&gt;
658    
659      &lt;xsd:import namespace="http://www.ivoa.net/xml/VOResource/v1.0"
660                  schemaLocation="http://www.ivoa.net/xml/VOResource/v1.0" /&gt;
661    
662      &lt;!--
663        -  the root element for a VOSI capabilities metadata (section 3.1)
664        --&gt;
665      &lt;xsd:element name="capabilities"&gt;
666         &lt;xsd:annotation&gt;
667           &lt;xsd:documentation&gt;
668             A listing of capabilities supported by a service
669           &lt;/xsd:documentation&gt;
670         &lt;/xsd:annotation&gt;
671    
672         &lt;xsd:complexType&gt;
673            &lt;xsd:sequence&gt;
674    
675               &lt;xsd:element name="capability" type="vr:Capability"
676                            form="unqualified" minOccurs="0" maxOccurs="unbounded"&gt;
677                  &lt;xsd:annotation&gt;
678                    &lt;xsd:documentation&gt;
679                      A capability supported by the service.  
680                    &lt;/xsd:documentation&gt;
681                    &lt;xsd:documentation&gt;
682                      A protocol-specific capability is included by specifying a
683                      vr:Capability sub-type via an xsi:type attribute on this
684                      element.
685                    &lt;/xsd:documentation&gt;
686                  &lt;/xsd:annotation&gt;
687             &lt;/xsd:element&gt;
688    
689          &lt;/xsd:sequence&gt;
690        &lt;/xsd:complexType&gt;
691      &lt;/xsd:element&gt;
692    
693    &lt;/xsd:schema&gt;
694    </pre>
695    
696    <a name="appA2">
697    <h3>A.2.  The Complete VOSIAvailability Schema</h3></a>
698    
699    <pre>&lt;xsd:schema targetNamespace="http://www.ivoa.net/xml/VOSIAvailability/v1.0"
700                xmlns:tns="http://www.ivoa.net/xml/VOSIAvailability/v1.0"
701                xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
702                xmlns:xsd="http://www.w3.org/2001/XMLSchema"
703                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
704                elementFormDefault="qualified"
705                attributeFormDefault="unqualified"
706                version="1.0rc1"&gt;
707    
708      &lt;xsd:annotation&gt;
709         &lt;xsd:documentation&gt;
710           A schema for formatting availability metadata as returned by an
711           availability resource defined in the IVOA Support Interfaces
712           specification (VOSI).
713           See http://www.ivoa.net/Documents/latest/VOSI.html.  
714         &lt;/xsd:documentation&gt;
715      &lt;/xsd:annotation&gt;
716    
717      &lt;!--
718        -  the root element for a VOSI availability (section 3.3)
719        --&gt;
720      &lt;xsd:element name="availability" type="tns:Availability"/&gt;
721    
722      &lt;xsd:complexType name="Availability"&gt;
723        &lt;xsd:sequence&gt;
724          
725          &lt;xsd:element name="available" type="xsd:boolean"&gt;
726            &lt;xsd:annotation&gt;
727              &lt;xsd:documentation&gt;
728                 Indicates whether the service is currently available.
729               &lt;/xsd:documentation&gt;
730            &lt;/xsd:annotation&gt;
731          &lt;/xsd:element&gt;
732    
733          &lt;xsd:element name="upSince" type="xsd:dateTime" minOccurs="0"&gt;
734            &lt;xsd:annotation&gt;
735              &lt;xsd:documentation&gt;
736                The instant at which the service last became available.
737              &lt;/xsd:documentation&gt;
738            &lt;/xsd:annotation&gt;
739          &lt;/xsd:element&gt;
740    
741          &lt;xsd:element name="downAt" type="xsd:dateTime" minOccurs="0"&gt;
742            &lt;xsd:annotation&gt;
743              &lt;xsd:documentation&gt;
744                The instant at which the service is next scheduled to become
745                unavailable.
746              &lt;/xsd:documentation&gt;
747            &lt;/xsd:annotation&gt;
748          &lt;/xsd:element&gt;
749    
750          &lt;xsd:element name="backAt" type="xsd:dateTime" minOccurs="0"&gt;
751            &lt;xsd:annotation&gt;
752              &lt;xsd:documentation&gt;
753                The instant at which the service is scheduled to become available
754                again after a period of unavailability.
755              &lt;/xsd:documentation&gt;
756            &lt;/xsd:annotation&gt;
757          &lt;/xsd:element&gt;
758    
759          &lt;xsd:element name="note" type="xsd:string"
760                       minOccurs="0" maxOccurs="unbounded"&gt;
761            &lt;xsd:annotation&gt;
762              &lt;xsd:documentation&gt;
763                A textual note concerning availability.
764              &lt;/xsd:documentation&gt;
765            &lt;/xsd:annotation&gt;
766          &lt;/xsd:element&gt;
767    
768        &lt;/xsd:sequence&gt;
769      &lt;/xsd:complexType&gt;
770    
771    &lt;/xsd:schema&gt;
772    </pre>
773    
774    <a name="appA3">
775    <h3>A.3.  The Complete VOSITables Schema</h3></a>
776    
777    <pre>
778    &lt;xsd:schema targetNamespace="http://www.ivoa.net/xml/VOSICapabilities/v1.0"
779                xmlns:tns="http://www.ivoa.net/xml/VOSICapabilities/v1.0"
780                xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
781                xmlns:xsd="http://www.w3.org/2001/XMLSchema"
782                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
783                elementFormDefault="qualified"
784                attributeFormDefault="unqualified"
785                version="1.0rc1"&gt;
786    
787      &lt;xsd:annotation&gt;
788         &lt;xsd:documentation&gt;
789           A schema for formatting table metadata as returned by a
790           tables resource, defined by the IVOA Support Interfaces
791           specification (VOSI).
792           See http://www.ivoa.net/Documents/latest/VOSI.html.  
793         &lt;/xsd:documentation&gt;
794      &lt;/xsd:annotation&gt;
795    
796      &lt;xsd:import namespace="http://www.ivoa.net/xml/VODataService/v1.1"
797                  schemaLocation="http://www.ivoa.net/xml/VODataService/v1.1" /&gt;
798    
799      &lt;!--
800        -  the root element for a VOSI table metadata (section 3.4)
801        --&gt;
802      &lt;xsd:element name="tableset" type="vs:TableSet" &gt;
803         &lt;xsd:annotation&gt;
804           &lt;xsd:documentation&gt;
805             A description of the table metadata supported by the
806             service associated with a VOSI-enabled resource.
807           &lt;/xsd:documentation&gt;
808         &lt;/xsd:annotation&gt;
809      &lt;/xsd:element&gt;
810    
811    &lt;/xsd:schema&gt;
812    </pre>
813    
814    <h2><a name="appB">Applendix B: Changes from previous versions</a></h2>
815    
816    <h4>Changes since PR-20100311</h4>
817    <ul>
818      <li>Inclusion of IVOA Architecture text </li>
819      <li>Restructuring and clarification in response to RFC comments</li>
820      <li>Inclusion of VOSITables schema in appendix</li>
821      <li>Second example added for a TAP service response</li>
822      </ul>
823    
824    <h4>Changes since WD-20090825</h4>
825    
826    <ul>
827      <li> Mandate the use of VOSICapabilities to return capabilities </li>
828      <li> S2.1: added non-normative note about capability sub-types;  added
829           example capabilities metadata </li>
830      <li> Recommend the inclusion of VOSI interfaces in capability metadata</li>
831      <li> S2.5:  When returning capabilities metadata, require VOSI (REST)
832           accessURLs to have use="full"; recommend this use of ParamHTTP. </li>
833      <li> Rename Availability schema to VOSIAvailability; added
834           VOSICapabilities schema. </li>
835    </ul>
836    
837    <h4>Changes since WD-20081030</h4>
838    
839    <p>The REST binding is made mandatory for all kinds of service. Details of the SOAP binding, including its WSDL contract, are removed.</p><p>
840    The definition of the root element for the table-metadata document is corrected. Instead of requiring the <i>tableset</i> element from <i>VODataService 1.1</i> (which element does not exist in that schema), the text now requires an element of type <i>TableSet</i>.
841    </p>
842    
843    <br/>
844    <h2><a name="ref">References</a></h2>
845    
846    <dl>
847      <dt> <a name="ref:vor">[1]</a> </dt>
848      <dd> Plante, R., Benson, K., Graham, M., Greene,
849           G., Harrison, P., Lemson, G., Linde, T., Rixon,
850           G., St&eacute;b&eacute;, A. 2008, <cite>
851           <a href="http://www.ivoa.net/Documents/cover/VOResource-20080222.html">
852           VOResource: an XML Encoding Schema for Resource Metadata</a></cite>,
853           v1.03, IVOA Recommendation,
854           <code>http://www.ivoa.net/Documents/cover/VOResource-20080222.html</code>
855           </dd>
856    
857      <dt> <a name="ref:vos">[2]</a> </dt>
858      <dd> Plante, R., St&eacute;b&eacute;, A., Benson, K., Dowler, P.,
859           Graham, M., Greene, G., Harrison, P., Lemson, G., Linde, T.,
860           Rixon, G. 2008, <cite>
861           <a href="http://www.ivoa.net/Documents/VODataService/20090903/">
862           VODataService: a VOResource Schema Extension for Describing
863           Collections and Services</a></cite>,
864           v1.1, IVOA Proposed Recommendation,
865           <code>http://www.ivoa.net/Documents/VODataService/20090903/</code>
866           </dd>
867    </dl>
868    
869    
870    
871    </body></html>

Legend:
Removed from v.1456  
changed lines
  Added in v.1457

msdemlei@ari.uni-heidelberg.de
ViewVC Help
Powered by ViewVC 1.1.26