ViewVC logotype

Annotation of /trunk/projects/grid/VOSI/VOSI-v1.0wd.html

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1257 - (hide annotations)
Thu Mar 11 16:55:25 2010 UTC (11 years, 6 months ago) by rplante@ncsa.uiuc.edu
File MIME type: text/html
File size: 29687 byte(s)
updated document date
1 rplante@ncsa.uiuc.edu 1255 <?xml version="1.0" encoding="iso-8859-1"?>
2     <!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     .issue {background-color: yellow}
7     .postponedissue {background-color: yellow}
8     .def code
9     .future {background-color: pink}
10     .draftedit {background-color: white}
11     .draftdelete {background-color: white}
12     .note { margin-left: 4em }
13     code { font-weight: bold;
14     font-family: monospace }
16     div.exampleInner pre { margin-left: 1em;
17     margin-top: 0em; margin-bottom: 0em}
18     div.exampleOuter {border: 4px double gray;
19     margin: 0em; padding: 0em}
20     div.exampleInner { border-top-width: 4px;
21     border-top-style: double;
22     border-top-color: white;
23     border-bottom-width: 4px;
24     border-bottom-style: double;
25     border-bottom-color: white;
26     padding: 0px; margin: 0em }
27     div.exampleWrapper { margin: 4px }
28     div.exampleHeader { font-weight: bold;
29     margin: 4px}
31     div.schemaInner pre { margin-left: 1em;
32     margin-top: 0em; margin-bottom: 0em;
33     }
34     div.schemaOuter {border: 4px double gray; padding: 0em}
35     div.schemaInner { background-color: #eeeeee;
36     border-top-width: 4px;
37     border-top-style: double;
38     border-top-color: #d3d3d3;
39     border-bottom-width: 4px;
40     border-bottom-style: double;
41     border-bottom-color: #d3d3d3;
42     padding: 4px; margin: 0em }
43     div.schemaHeader { font-weight: bold;
44     margin: 4px}
45     </style>
46     <title>VOSI (Working Draft)</title>
47     <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
48     <meta name="keywords" content="IVOA, International, Virtual, Observatory, Alliance" />
49     <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
50     <meta name="maintainedBy" content="IVOA Document Coordinator, ivoadoc@ivoa.net" />
51     <link rel="stylesheet" href="http://ivoa.net/misc/ivoa_wg.css" type="text/css" />
52     </head>
54     <body>
55     <div class="head">
56     <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     <h1>IVOA Support Interfaces<br/>
58     Version 1.00-20091029</h1>
59     <h2>IVOA WG Working Draft 2009 October 29 </h2>
61     <dl>
62     <dt>This version:</dt>
63 rplante@ncsa.uiuc.edu 1257 <dd><a href="http://www.ivoa.net/Documents/VOSI/20100311/">
64     http://www.ivoa.net/Documents/VOSI/20100311/</a></dd>
65 rplante@ncsa.uiuc.edu 1255
66     <dt>Latest version:</dt>
67     <dd><a href="http://www.ivoa.net/Documents/latest/VOSI.html">
68     http://www.ivoa.net/Documents/latest/VOSI.html</a></dd>
70     <dt>Previous versions:</dt>
71     <dd>WD: <a href="http://www.ivoa.net/Documents/VOSI/20090825/">
72     http://www.ivoa.net/Documents/VOSI/20090825/</a> <br />
73     WD: <a href="http://www.ivoa.net/Documents/VOSI/20081030/">
74     http://www.ivoa.net/Documents/VOSI/20081030/</a></dd>
75     </dl>
77     <dl>
78     <dt>Working Group:</dt>
79     <dd><a
80     href="http://www.ivoa.net/twiki/bin/view/IVOA/IvoaGridAndWebServices">
81     http://www.ivoa.net/twiki/bin/view/IVOA/IvoaGridAndWebServices</a></dd>
83     <dt>Editors:</dt>
84     <dd><a
85     href="http://www.ivoa.net/twiki/bin/view/IVOA/MatthewGraham">Matthew
86     Graham</a><br/>
87     <a
88     href="http://www.ivoa.net/twiki/bin/view/IVOA/GuyRixon">Guy Rixon</a></dd>
89     <dt>Author(s):</dt>
90     <dd>
91     <a
92     href="http://www.ivoa.net/twiki/bin/view/IVOA/IvoaGridAndWebServices">Grid and Web
93     Services Working Group</a><br/>
94     <a href="http://www.ivoa.net/twiki/bin/view/IVOA/"></a>
95     </dd>
96     </dl>
97     <hr/></div>
99     <h2><a name="abstract" id="abstract">Abstract</a></h2>
101     <p>
102     This document describes the minimum required interface to participate in the IVOA as a web service.
103     </p>
105     <div class="status">
106     <h2><a name="status" id="status">Status of this Document</a></h2>
107     <p>
108     This is a Working Draft. The first release of this document was 2008 Oct 30.
109     </p>
111     <!-- Choose one of the following (and remove the rest)-->
112     <!--Note-->
113     <!--
114     <p>This is an IVOA Note expressing suggestions from and opinions of the authors.<br/>
115     It is intended to share best practices, possible approaches, or other perspectives on interoperability with the Virtual Observatory.
116     It should not be referenced or otherwise interpreted as a standard specification.</p>
117     -->
118     <p>This is an IVOA Working Draft for review by IVOA members and other interested parties.<br/>
119     It is a draft document and may be updated, replaced, or obsoleted by other documents at any time.
120     It is inappropriate to use IVOA Working Drafts as reference materials or to cite them as other than "work in progress.</p>
121     <!--Proposed Recommendation
122     <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
124     before it is accepted as a full recommendation.</p>
125     -->
126     <!--Recommendation
127     <p>This document has been produced by the IVOA "WG Name" Working Group.<br/>
128     It has been reviewed by IVOA Members and other interested parties, and has been endorsed by the IVOA Executive Committee as an IVOA Recommendation.
129     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.
130     This enhances the functionality and interoperability inside the Astronomical Community.</p>
131     -->
133     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     </div><br />
137     <h2><a name="acknowledgments" id="acknowledgments">Acknowledgments</a></h2>
139     <p>This work is based on discussions and actions from the 2003 IVOA
140     meeting in Strasbourg and further discussions on registry
141     functionality at JHU late in 2003. Later inputs came from a local
142     meeting at JHU in Sept. 2004. William O'Mullane and Ani Thakar were the editors and primary authors for these early versions.</p>
143     <p>
144     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.
145     </p>
146     <h2><a id="contents" name="contents">Contents</a></h2>
147     <div class="head">
148     <ul class="toc">
149     <li><a href="#abstract">Abstract</a></li>
150     <li><a href="#status">Status</a></li>
151     <li><a href="#acknowledgments">Acknowledgments</a></li>
152     <li><a href="#contents">Contents</a></li>
153     <li><a href="#sec1">1. Introduction</a></li>
155     <li><a href="#sec2">2. Standard VO interfaces</a></li>
156     <ul class="toc">
157     <li><a href="#sec2_1">2.1 Capability metadata</a></li>
158     <li><a href="#sec2_2">2.2 Non-service metadata (non-normative description)</a></li>
159     <li><a href="#sec2_3">2.3 Availability metadata</a></li>
160     <li><a href="#sec2_4">2.4 Table metadata</a></li>
161     <li><a href="#sec2_5">2.5 Registration of VOSI endpoints</a></li>
162     </ul>
164     <br/>
165     <li><a href="#appA">Appendix A: VOSI XML schemas</a></li>
166     <li><a href="#appB">Appendix B: Changes from previous versions</a></li>
167     <li><a href="#ref">References</a></li>
168     </ul>
169     </div>
170     <hr/>
173     <br/>
174     <h2><a name="sec1">1. Introduction</a></h2>
175     <p>Much of the Virtual Observatory (VO) is made up of web services in
176     SOAP and REST forms. It is felt there are some basic functions that
177     all these services should provide in order to support management of
178     the VO.</p>
179     <p>
180     These standard interfaces are mandated by the VO basic profile for SOAP services and hence should appear in all SOAP services, using the standard WSDL extract in this specification. For REST services, the requirement for the support interfaces is stated in the specification for each kind of service. A contract for a REST service may specify extra constraints (e.g. on the form of the URIs) for the support interfaces. </p><p>
181     In the normal requirements manner the words "should" and "shall" are used to convey the level of necessity of the interface.
182     </p>
184     <br/>
185     <h2><a name="sec2">2. Standard VO Interfaces</a></h2>
186     <p>The standard interfaces all return metadata without changing the
187     state of the service to which they apply. They could, in principle be
188     implemented in any of three ways.</p>
189     <ol type="1">
190     <li> As extra SOAP operations on an existing SOAP endpoint of the service to which they apply. This would be a 'SOAP binding' of VOSI.
191     <li> As SOAP operations on a separate SOAP endpoint. This would be an alternate form of the SOAP binding.
192     <li> As web resources with distinct URLs, without using the SOAP protocol. This is the 'REST binding' for the standard interfaces.
193     </ol><p>
194     This standard requires the REST binding of VOSI even when applied to
195     services that otherwise use SOAP. No details of the SOAP binding are
196     given in this version of the standard. </p>
197     <p>
198     In the REST binding, the support interfaces shall have distinct URLs in the HTTP scheme and shall be accessible by the GET operation in the HTTP protocol. The response to an HTTP POST, PUT or DELETE to these resources is not defined by this specification. However, if an implementation has no special action to perform for these requests, the normal response would be a 405 "Method not allowed" error. </p><p>
199     The endpoints and interface types for the support interfaces shall be defined in the service's registration using one Capability element for each interface. The standardId values for these Capabilities are given in section 2.4.</p><p>
200     When using the REST binding, any HTTP URLs may be used. The client must find the appropriate URLs from the registration 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>
201     </p>
203     <h3><a name="sec2_1">2.1 Capability metadata</a></h3>
204     <p>This interface provides the service metadata in the form of a list of Capability descriptions. Each of these descriptions is an XML element that </p>
205     <ul>
206     <li> states that the service provides a particular, IVOA-standard function;
207     <li> lists the interfaces for invoking that function;
208     <li> records any details of the implementation of the function that
209     are not fixed in the standard for that function.
210     </ul>
211     <p>
212     E.g., one capability might describe a cone-search function and another the table-access-protocol implementation; these two might well be apply to the same service.</p><p>
213     An entry for a service in the resource registry - i.e. its VOResource - contains the Dublin-core resource metadata (identifier, curation information, content description etc.) followed by the service's capability descriptions. Effectively, the resource metadata describe the service to human users and the capability list describes it to software. Therefore, the capability list alone has two uses.</p>
214     <ul><li>It may be read by a client application to find out how to drive the service. This presumes that the service has been already been selected and the VOSI endpoint located.
215     <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.
216     </ul></p>
218     <p>
219     The service metadata shall be represented as an XML document with the
220     root element
221     <i>{http://www.ivoa.net/xml/VOSICapabilities/v1.0}capabilities</i>.
222     (See <a href="#appA1">Appendix A.1</a> for the definition the
223     VOSICapabilities schema.) This element must contain one or more child
224     <i>capability</i> elements that describe the capabilities of the
225     service. Given that the capability element is defined to be of type
226     <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i>, a capability
227     element may be represented by a legal sub-type of
228     <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i>, in which
229     case, the <i>capability</i> element must use an <i>xsi:type</i>
230     attribute to identify the sub-type (see section 2.2.1 of
231     [<a href="#ref:vor">1</a>]).
232     </p>
234     <p></p
235     <blockquote>
236     <table bgcolor="#dddddd" border="2" cellpadding="5"><tbody><tr><td>
237     <dl style="margin-top: 0pt; margin-bottom: 0pt">
238     <dt> <strong>Note:</strong> </dt>
239     <dd> The value of the capability element's standardID attribute is used
240     to indicate the service's support for particular standard protocols
241     (such as Simple Image Access, Simple Cone Search, etc.). In the
242     case of some protocols, the support for the standard is further
243     characterized by additional metadata provided by a standard Capability
244     extension for that protocol. The extension metadata is enabled by
245     adding a xsi:type attribute to the capability element set to the
246     Capability sub-type for that protocol (see example below). </dd>
247     </dl>
248     </td></tr></tbody></table>
249     </blockquote>
250     <p></p>
252     <p>
253     The list of capabilities should include capabilities describing VOSI
254     endpoints as specified in section 2.5.
255     </p>
257     <!-- Space to push page break in PDF version
258     <br />
259     <br />
260     -->
262     <div class="exampleOuter">
263     <a name="ex:caps">
264     </a><div class="exampleHeader">Example</div>
265     <div class="exampleWrapper">a sample response from a capabilities
266     resource describing an SIA service. </div>
267     <div class="exampleInner" style="background-color: rgb(213, 222, 227);">
268     <pre>&lt;?xml version="1.0" encoding="UTF-8"?&gt;
269     &lt;vosi:capabilities xmlns:vosi="http://www.ivoa.net/xml/VOSICapabilities/v1.0"
270     xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
271     xmlns:vs="http://www.ivoa.net/xml/VODataService/v1.0"
272     xmlns:sia="http://www.ivoa.net/xml/SIA/v1.0"
273     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
274     xsi:schemaLocation="http://www.ivoa.net/xml/VOSI/v1.0
275     http://www.ivoa.net/xml/VOSI/v1.0
276     http://www.ivoa.net/xml/VOResource/v1.0
277     http://www.ivoa.net/xml/VOResource/v1.0
278     http://www.ivoa.net/xml/VODataService/v1.0
279     http://www.ivoa.net/xml/VODataService/v1.0
280     http://www.ivoa.net/xml/SIA/v1.0
281     http://www.ivoa.net/xml/SIA/v1.0"&gt;
283     &lt;!-- a generic capability (for custom, non-standard interfaces) --&gt;
284     &lt;capability&gt;
285     &lt;interface xsi:type="vr:WebBrowser"&gt;
286     &lt;accessURL use="full"&gt; http://adil.ncsa.uiuc.edu/siaform.html &lt;/accessURL&gt;
287     &lt;/interface&gt;
288     &lt;/capability&gt;
290     &lt;!-- the SIA capability --&gt;
291     &lt;capability xsi:type="sia:SimpleImageAccess" standardID="ivo://ivoa.net/std/SIA"&gt;
292     &lt;interface xsi:type="vs:ParamHTTP" role="std"&gt;
293     &lt;accessURL&gt; http://adil.ncsa.uiuc.edu/cgi-bin/voimquery?survey=f&amp;amp; &lt;/accessURL&gt;
294     &lt;/interface&gt;
296     &lt;imageServiceType&gt;Pointed&lt;/imageServiceType&gt;
297     &lt;maxQueryRegionSize&gt;
298     &lt;long&gt;360.0&lt;/long&gt;
299     &lt;lat&gt;180.0&lt;/lat&gt;
300     &lt;/maxQueryRegionSize&gt;
301     &lt;maxImageExtent&gt;
302     &lt;long&gt;360.0&lt;/long&gt;
303     &lt;lat&gt;180.0&lt;/lat&gt;
304     &lt;/maxImageExtent&gt;
305     &lt;maxImageSize&gt;
306     &lt;long&gt;5000&lt;/long&gt;
307     &lt;lat&gt;5000&lt;/lat&gt;
308     &lt;/maxImageSize&gt;
309     &lt;maxFileSize&gt;100000000&lt;/maxFileSize&gt;
310     &lt;maxRecords&gt;5000&lt;/maxRecords&gt;
311     &lt;/capability&gt;
313     &lt;!-- the interface that returns this document --&gt;
314     &lt;capability standardID="ivo://ivoa.net/std/VOSI#capabilities"&gt;
315     &lt;interface xsi:type="vs:ParamHTTP" role="std"&gt;
316     &lt;accessURL use="full"&gt; http://adil.ncsa.uiuc.edu/cgi-bin/voimquery/capabilities &lt;/accessURL&gt;
317     &lt;/interface&gt;
318     &lt;/capability&gt;
320     &lt;!-- the interface that returns this document --&gt;
321     &lt;capability standardID="ivo://ivoa.net/std/VOSI#availability"&gt;
322     &lt;interface xsi:type="vs:ParamHTTP" role="std"&gt;
323     &lt;accessURL use="full"&gt; http://adil.ncsa.uiuc.edu/cgi-bin/voimquery/availability &lt;/accessURL&gt;
324     &lt;/interface&gt;
325     &lt;/capability&gt;
326     &lt;/vosi:capabilities&gt;
327     </pre>
328     </div></div>
331     <p>
332     In the REST binding, the service metadata shall be a single web-resource with a registered URL. The data and time at which the metadata last changed shall be obtained the <i>Last-Modified</i> HTTP-header sent in the response to a GET or HEAD request to the registered URI.</p><p>
333     All VO services should provide this interface.
334     </p>
336     <h3><a name="sec2_2">2.2 Non-service metadata (non-normative description)</a></h3>
337     <p>There may be other metadata associated with a service than the capability metadata described above.
338     <ul><li> Every service has the Dublin-core "resource" metadata.
339     <li> Some services are associated with registered applications.
340     <li> Some services are associated with registered data collections.
341     </ul></p><p>None of these are explicitly provided for in this version of VOSI. Some might be covered in later versions of VOSI.
342     </p>
344     <h3><a name="sec2_3">2.3 Availability metadata</a></h4>
345     <p>This interface indicates whether the service is operable and the reliability of the service for extended and scheduled requests.
346     The availability shall be represented as an XML document in which the
347     root element is <i>{http://www.ivoa.net/xml/Availability/v0.4}availability</i>. This element
348     shall contain child elements providing the following information.</p>
349     <ul>
350     <li> <i>available</i> - whether the service is currently accepting requests;
351     <li> <i>upSince</i> - duration for which the service has been continuously available
352     <li> <i>downAt</i> - the instant at which the service is next scheduled to be unavailable
353     <li> <i>backAt</i> - the instant at which the service is scheduled to become available again after down time;
354     <li> <i>note</i> - textual note, e.g. explaining the reason for unavailaility.
355     </ul><p>
356     The elements <i>upSince</i>, <i>downAt</i>, <i>backAt</i> and <i>notes</i> are optional. The <i>available</i> element is mandatory. There may be more than one note element.</p><p>
357     The XML document shall conform to the schema given in appendix 1 of this specification.</p><p>
358     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 check fail, the service should set available to false in the availability output.</p><p>
359     If a service wishes to be on-line 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 available to false.</p><p>
360     There are no special elements in the availability document for the contact details of the service operator. These details may be given as a note element if they are known to the service.</p><p>
361     Ultimately some portals may track these heartbeats and compile uptime statistics. With the location we could have 3D global maps of services and availability.</p><p>
362     In the REST binding, the availability shall be a single web-resource with a registered URIL</p><p>
363     All VO services shall provide this interface.
364     </p>
366     <h3><a name="sec2_4">2.4 Table metadata</a></h3>
367     <p>
368     Some services deal with tabular data. These data may be the target of ADQL queries, as in the Table Access Protocol, 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>
369     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>
370     A service which uses tables in its interface should define a VOSI endpoint from which table metadata can be read. The table metadata shall be represented as an XML document of which the root element is of type <i>{http://www.ivoa.net/xml/VODataService/v1.1}TableSet</i>. This element may contain any mix of elements allowed by the VODataService XML-schema.</p><p>
371     In the REST binding, the table metadata shall be a single web-resource with a registered URL.
372     </p>
374     <h3><a name="sec2_5">2.5 Registration of VOSI endpoints</a></h3>
376     <p>
377     The endpoints for the service and availability metadata shall be
378     included in the registration of each service that provides them.
379     </p>
381     <p>
382     An availability endpoint shall be represented by an element named
383     <i>capability</i>, of type
384     <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i> (defined by
385     the standard VOResource XML schema [<a href="ref:vor">1</a>]). The
386     value of the <i>standardID</i> attribute of the <i>capability</i>
387     shall be <i>ivo://ivoa.net/std/VOSI#availability</i> (sic; note the
388     use of the document fragment to identify one part of the VOSI
389     standard).
390     </p>
392     <p>
393     A capabilities endpoint should be represented 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 its <i>standardID</i> attribute must be <i>ivo://ivoa.net/std/VOSI#capabilities.</i></p><p>
394     A tables endpoint should be represented 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 its <i>standardID</i> attribute must be <i>ivo://ivoa.net/std/VOSI#tables</i>.
395     </p>
397     <p>
398     With all three VOSI functions, the capability element that describes
399     the function must contain an interface element of a type semantically
400     appropriate for the binding of the function to the service; the
401     <i>accessURL</i> element within the interface element indicates the
402     endpoint for the VOSI function. For the REST binding, this
403     <i>accessURL</i> element must set the <i>use</i> attribute to "full".
404     Furthermore, for the REST binding, this document recommends using the
405     <i>{http://www.ivoa.net/xml/VODataService/v1.1}ParamHTTP</i> interface
406     type to encode VOSI endpoints (see example given in section 2.1).
407     </p>
411     <br/>
412     <h2><a name="appA">Appendix A: VOSI XML schemas</a></h2>
414     <a name="appA1">
415     <h3>A.1. The Complete VOSICapabilities Schema</h3></a>
417     <pre>&lt;xsd:schema targetNamespace="http://www.ivoa.net/xml/VOSICapabilities/v1.0"
418     xmlns:tns="http://www.ivoa.net/xml/VOSICapabilities/v1.0"
419     xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
420     xmlns:xsd="http://www.w3.org/2001/XMLSchema"
421     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
422     elementFormDefault="qualified"
423     attributeFormDefault="unqualified"
424     version="1.0rc1"&gt;
426     &lt;xsd:annotation&gt;
427     &lt;xsd:documentation&gt;
428     A schema for formatting service capabilities as returned by a
429     capabilities resource, defined by the IVOA Support Interfaces
430     specification (VOSI).
431     See http://www.ivoa.net/Documents/latest/VOSI.html.
432     &lt;/xsd:documentation&gt;
433     &lt;/xsd:annotation&gt;
435     &lt;xsd:import namespace="http://www.ivoa.net/xml/VOResource/v1.0"
436     schemaLocation="http://www.ivoa.net/xml/VOResource/v1.0" /&gt;
438     &lt;!--
439     - the root element for a VOSI capabilities metadata (section 2.1)
440     --&gt;
441     &lt;xsd:element name="capabilities"&gt;
442     &lt;xsd:annotation&gt;
443     &lt;xsd:documentation&gt;
444     A listing of capabilities supported by a service
445     &lt;/xsd:documentation&gt;
446     &lt;/xsd:annotation&gt;
448     &lt;xsd:complexType&gt;
449     &lt;xsd:sequence&gt;
451     &lt;xsd:element name="capability" type="vr:Capability"
452     form="unqualified" minOccurs="0" maxOccurs="unbounded"&gt;
453     &lt;xsd:annotation&gt;
454     &lt;xsd:documentation&gt;
455     A capability supported by the service.
456     &lt;/xsd:documentation&gt;
457     &lt;xsd:documentation&gt;
458     A protocol-specific capability is included by specifying a
459     vr:Capability sub-type via an xsi:type attribute on this
460     element.
461     &lt;/xsd:documentation&gt;
462     &lt;/xsd:annotation&gt;
463     &lt;/xsd:element&gt;
465     &lt;/xsd:sequence&gt;
466     &lt;/xsd:complexType&gt;
467     &lt;/xsd:element&gt;
469     &lt;/xsd:schema&gt;
470     </pre>
472     <a name="appA2">
473     <h3>A.2. The Complete VOSIAvailability Schema</h3></a>
475     <pre>&lt;xsd:schema targetNamespace="http://www.ivoa.net/xml/VOSIAvailability/v1.0"
476     xmlns:tns="http://www.ivoa.net/xml/VOSIAvailability/v1.0"
477     xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
478     xmlns:xsd="http://www.w3.org/2001/XMLSchema"
479     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
480     elementFormDefault="qualified"
481     attributeFormDefault="unqualified"
482     version="1.0rc1"&gt;
484     &lt;xsd:annotation&gt;
485     &lt;xsd:documentation&gt;
486     A schema for formatting availability metadata as returned by an
487     availability resource defined in the IVOA Support Interfaces
488     specification (VOSI).
489     See http://www.ivoa.net/Documents/latest/VOSI.html.
490     &lt;/xsd:documentation&gt;
491     &lt;/xsd:annotation&gt;
493     &lt;!--
494     - the root element for a VOSI availability (section 2.3)
495     --&gt;
496     &lt;xsd:element name="availability" type="tns:Availability"/&gt;
498     &lt;xsd:complexType name="Availability"&gt;
499     &lt;xsd:sequence&gt;
501     &lt;xsd:element name="available" type="xsd:boolean"&gt;
502     &lt;xsd:annotation&gt;
503     &lt;xsd:documentation&gt;
504     Indicates whether the service is currently available.
505     &lt;/xsd:documentation&gt;
506     &lt;/xsd:annotation&gt;
507     &lt;/xsd:element&gt;
509     &lt;xsd:element name="upSince" type="xsd:dateTime" minOccurs="0"&gt;
510     &lt;xsd:annotation&gt;
511     &lt;xsd:documentation&gt;
512     The instant at which the service last became available.
513     &lt;/xsd:documentation&gt;
514     &lt;/xsd:annotation&gt;
515     &lt;/xsd:element&gt;
517     &lt;xsd:element name="downAt" type="xsd:dateTime" minOccurs="0"&gt;
518     &lt;xsd:annotation&gt;
519     &lt;xsd:documentation&gt;
520     The instant at which the service is next scheduled to become
521     unavailable.
522     &lt;/xsd:documentation&gt;
523     &lt;/xsd:annotation&gt;
524     &lt;/xsd:element&gt;
526     &lt;xsd:element name="backAt" type="xsd:dateTime" minOccurs="0"&gt;
527     &lt;xsd:annotation&gt;
528     &lt;xsd:documentation&gt;
529     The instant at which the service is scheduled to become available
530     again after a period of unavailability.
531     &lt;/xsd:documentation&gt;
532     &lt;/xsd:annotation&gt;
533     &lt;/xsd:element&gt;
535     &lt;xsd:element name="note" type="xsd:string"
536     minOccurs="0" maxOccurs="unbounded"&gt;
537     &lt;xsd:annotation&gt;
538     &lt;xsd:documentation&gt;
539     A textual note concerning availability.
540     &lt;/xsd:documentation&gt;
541     &lt;/xsd:annotation&gt;
542     &lt;/xsd:element&gt;
544     &lt;/xsd:sequence&gt;
545     &lt;/xsd:complexType&gt;
547     &lt;/xsd:schema&gt;
548     </pre>
551     <br/>
552     <h2><a name="appB">Applendix B: Changes from previous versions</a></h2>
554     <h4>Changes since WD-20090825</h4>
556     <ul>
557     <li> Mandate the use of VOSICapabilities to return capabilities </li>
558     <li> S2.1: added non-normative note about capability sub-types; added
559     example capabilities metadata </li>
560     <li> Recommend the inclusion of VOSI interfaces in capability metadata</li>
561     <li> S2.5: When returning capabilities metadata, require VOSI (REST)
562     accessURLs to have use="full"; recommend this use of ParamHTTP. </li>
563     <li> Rename Availability schema to VOSIAvailability; added
564     VOSICapabilities schema. </li>
565     </ul>
567     <h4>Changes since WD-20081030</h4>
569     <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>
570     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>.
571     </p>
573     <br/>
574     <h2><a name="ref">References</a></h2>
576     <dl>
577     <dt> <a name="ref:vor">[1]</a> </dt>
578     <dd> Plante, R., Benson, K., Graham, M., Greene,
579     G., Harrison, P., Lemson, G., Linde, T., Rixon,
580     G., St&eacute;b&eacute;, A. 2008, <cite>
581     <a href="http://www.ivoa.net/Documents/cover/VOResource-20080222.html">
582     VOResource: an XML Encoding Schema for Resource Metadata</a></cite>,
583     v1.03, IVOA Recommendation,
584     <code>http://www.ivoa.net/Documents/cover/VOResource-20080222.html</code>
585     </dd>
587     <dt> <a name="ref:vos">[2]</a> </dt>
588     <dd> Plante, R., St&eacute;b&eacute;, A., Benson, K., Dowler, P.,
589     Graham, M., Greene, G., Harrison, P., Lemson, G., Linde, T.,
590     Rixon, G. 2008, <cite>
591     <a href="http://www.ivoa.net/Documents/VODataService/20090903/">
592     VODataService: a VOResource Schema Extension for Describing
593     Collections and Services</a></cite>,
594     v1.1, IVOA Proposed Recommendation,
595     <code>http://www.ivoa.net/Documents/VODataService/20090903/</code>
596     </dd>
597     </dl>
601     </body></html>

ViewVC Help
Powered by ViewVC 1.1.26