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

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1259 - (show annotations)
Thu Mar 11 17:01:37 2010 UTC (10 years, 7 months ago) by rplante@ncsa.uiuc.edu
File MIME type: text/html
File size: 29685 byte(s)
corrected date in title
1 <?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 }
15
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}
30
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>
53
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 March 11 </h2>
60
61 <dl>
62 <dt>This version:</dt>
63 <dd><a href="http://www.ivoa.net/Documents/VOSI/20100311/">
64 http://www.ivoa.net/Documents/VOSI/20100311/</a></dd>
65
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>
69
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>
76
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>
82
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>
98
99 <h2><a name="abstract" id="abstract">Abstract</a></h2>
100
101 <p>
102 This document describes the minimum required interface to participate in the IVOA as a web service.
103 </p>
104
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>
110
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 -->
132
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/.
134
135 </div><br />
136
137 <h2><a name="acknowledgments" id="acknowledgments">Acknowledgments</a></h2>
138
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>
154
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>
163
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/>
171
172
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>
183
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>
202
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>
217
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>
233
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>
251
252 <p>
253 The list of capabilities should include capabilities describing VOSI
254 endpoints as specified in section 2.5.
255 </p>
256
257 <!-- Space to push page break in PDF version
258 <br />
259 <br />
260 -->
261
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;
282
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;
289
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;
295
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;
312
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;
319
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>
329
330
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>
335
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>
343
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>
365
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>
373
374 <h3><a name="sec2_5">2.5 Registration of VOSI endpoints</a></h3>
375
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>
380
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>
391
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>
396
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>
408
409
410
411 <br/>
412 <h2><a name="appA">Appendix A: VOSI XML schemas</a></h2>
413
414 <a name="appA1">
415 <h3>A.1. The Complete VOSICapabilities Schema</h3></a>
416
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;
425
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;
434
435 &lt;xsd:import namespace="http://www.ivoa.net/xml/VOResource/v1.0"
436 schemaLocation="http://www.ivoa.net/xml/VOResource/v1.0" /&gt;
437
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;
447
448 &lt;xsd:complexType&gt;
449 &lt;xsd:sequence&gt;
450
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;
464
465 &lt;/xsd:sequence&gt;
466 &lt;/xsd:complexType&gt;
467 &lt;/xsd:element&gt;
468
469 &lt;/xsd:schema&gt;
470 </pre>
471
472 <a name="appA2">
473 <h3>A.2. The Complete VOSIAvailability Schema</h3></a>
474
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;
483
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;
492
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;
497
498 &lt;xsd:complexType name="Availability"&gt;
499 &lt;xsd:sequence&gt;
500
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;
508
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;
516
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;
525
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;
534
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;
543
544 &lt;/xsd:sequence&gt;
545 &lt;/xsd:complexType&gt;
546
547 &lt;/xsd:schema&gt;
548 </pre>
549
550
551 <br/>
552 <h2><a name="appB">Applendix B: Changes from previous versions</a></h2>
553
554 <h4>Changes since WD-20090825</h4>
555
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>
566
567 <h4>Changes since WD-20081030</h4>
568
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>
572
573 <br/>
574 <h2><a name="ref">References</a></h2>
575
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>
586
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>
598
599
600
601 </body></html>

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