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

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1471 - (show annotations)
Wed May 11 13:52:00 2011 UTC (9 years, 5 months ago) by rplante@ncsa.uiuc.edu
File MIME type: text/html
File size: 52016 byte(s)
added ref. to AppB from 1.1 (architecture); fixed sect. numbering
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>IVOA Proposed Recommendation - IVOA Support Interfaces</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_pr.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-20110511</h1>
59 <h2>IVOA WG Proposed Recommendation 2011 May 11 </h2>
60
61 <dl>
62 <dt>This version:</dt>
63 <dd><a href="http://www.ivoa.net/Documents/VOSI/20110511/">
64 http://www.ivoa.net/Documents/VOSI/20110511/</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>PR: <a href="http://www.ivoa.net/Documents/VOSI/20101206/">
72 http://www.ivoa.net/Documents/VOSI/20101206/</a><br />
73 PR: <a href="http://www.ivoa.net/Documents/VOSI/20100311/">
74 http://www.ivoa.net/Documents/VOSI/20100311/</a> <br />
75 WD: <a href="http://www.ivoa.net/Documents/VOSI/20090825/">
76 http://www.ivoa.net/Documents/VOSI/20090825/</a> <br />
77 WD: <a href="http://www.ivoa.net/Documents/VOSI/20081030/">
78 http://www.ivoa.net/Documents/VOSI/20081030/</a></dd>
79 </dl>
80
81 <dl>
82 <dt>Working Group:</dt>
83 <dd><a
84 href="http://www.ivoa.net/twiki/bin/view/IVOA/IvoaGridAndWebServices">
85 http://www.ivoa.net/twiki/bin/view/IVOA/IvoaGridAndWebServices</a></dd>
86
87 <dt>Editors:</dt>
88 <dd><a
89 href="http://www.ivoa.net/twiki/bin/view/IVOA/MatthewGraham">Matthew
90 Graham</a><br/>
91 <a
92 href="http://www.ivoa.net/twiki/bin/view/IVOA/GuyRixon">Guy Rixon</a></dd>
93 <dt>Author(s):</dt>
94 <dd>
95 <a
96 href="http://www.ivoa.net/twiki/bin/view/IVOA/IvoaGridAndWebServices">Grid and Web
97 Services Working Group</a><br/>
98 <a href="http://www.ivoa.net/twiki/bin/view/IVOA/"></a>
99 </dd>
100 </dl>
101 <hr/></div>
102
103 <h2><a name="abstract" id="abstract">Abstract</a></h2>
104
105 <p>
106 This document describes the minimum interface that a (SOAP- or REST-based) web service requires to participate in the IVOA.
107 </p>
108
109 <div class="status">
110 <h2><a name="status" id="status">Status of this Document</a></h2>
111
112 <!-- Choose one of the following (and remove the rest)-->
113 <!--Note-->
114 <!--
115 <p>This is an IVOA Note expressing suggestions from and opinions of the authors.<br/>
116 It is intended to share best practices, possible approaches, or other perspectives on interoperability with the Virtual Observatory.
117 It should not be referenced or otherwise interpreted as a standard specification.</p>
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 -->
121 <!--or to cite them as other than "work in progress.</p>
122 -->
123 <!--Proposed Recommendation-->
124 <p>This is an IVOA Proposed Recommendation made available for public review.<br/>
125 It is appropriate to reference this document only as a recommended standard that is under review and which may be changed
126 before it is accepted as a full recommendation.<br/>
127 The first release of this document was 2010 March 11 .
128 </p>
129 <!--Recommendation
130 <p>This document has been produced by the IVOA "WG Name" Working Group.<br/>
131 It has been reviewed by IVOA Members and other interested parties, and has been endorsed by the IVOA Executive Committee as an IVOA Recommendation.
132 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.
133 This enhances the functionality and interoperability inside the Astronomical Community.</p>
134 -->
135
136 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/.
137
138 </div><br />
139
140 <h2><a name="acknowledgments" id="acknowledgments">Acknowledgments</a></h2>
141 <p>This document has been developed with support from the
142 <a href="http://www.nsf.gov/">National Science Foundation's</a>
143 Information Technology Research Program under Cooperative Agreement
144 AST0122449 with The Johns Hopkins University, from the
145 <a href="http://www.pparc.ac.uk/">UK Particle Physics and Astronomy
146 Research Council (PPARC)</a>, from the European Commission's (EC)
147 <a href="http://cordis.europa.eu/fp6/">Sixth
148 Framework Programme</a> via the <a href="http://www.astro-opticon.org/">
149 Optical Infrared Coordination Network (OPTICON)</a>, and from EC's
150 <a href="http://cordis.europa.eu/fp7/">Seventh Framework Programme</a>
151 via its
152 <a href="http://cordis.europa.eu/fp7/ict/e-infrastructure/home_en.html">
153 eInfrastructure Science Repositories initiative</a>. </p>
154
155 <p>This work is based on discussions and actions from the 2003 IVOA
156 meeting in Strasbourg and further discussions on registry
157 functionality at JHU late in 2003. Later inputs came from a local
158 meeting at JHU in Sept. 2004. William O'Mullane and Ani Thakar were the editors and primary authors for these early versions.</p>
159 <p>
160 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.
161 </p>
162
163 <h2><a name="conformance" id="conformance">Conformance related definitions</a></h2>
164 <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 [0].</p><p>
165 The <strong>Virtual Observatory (VO)</strong> is a general term for a
166 collection of federated resources that can be used to conduct
167 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.
168 </p>
169
170 <h2><a id="contents" name="contents">Contents</a></h2>
171 <div class="head">
172 <ul class="toc">
173 <li><a href="#abstract">Abstract</a></li>
174 <li><a href="#status">Status</a></li>
175 <li><a href="#acknowledgments">Acknowledgments</a></li>
176 <li><a href="#contents">Contents</a></li>
177 <li><a href="#sec1">1. Introduction</a></li>
178 <ul class="toc"><li><a href="#sec1_1">1.1 The role in the IVOA Architecture</a></li></ul>
179 <li><a href="#sec2">2. Interface bindings</a></li>
180 <li><a href="#sec3">3. Metadata specification</a></li>
181 <ul class="toc">
182 <li><a href="#sec3_1">2.1 Capability metadata</a></li>
183 <li><a href="#sec3_2">2.2 Non-service metadata (non-normative)</a></li>
184 <li><a href="#sec3_3">2.3 Availability metadata</a></li>
185 <li><a href="#sec3_4">2.4 Table metadata</a></li>
186 </ul>
187 <li><a href="#sec4">4. Registration of VOSI endpoints</a></li>
188 <li><a href="#sec5">5. Example VOSI responses</a></li>
189 <br/>
190 <li><a href="#appA">Appendix A: VOSI XML schemas</a></li>
191 <li><a href="#appB">Appendix B: Use Case for Capability Harvesting (non-normative)</a></li>
192 <li><a href="#appC">Appendix C: Changes from previous versions</a></li>
193 <li><a href="#ref">References</a></li>
194 </ul>
195 </div>
196 <hr/>
197
198
199 <br/>
200 <h2><a name="sec1">1. Introduction</a></h2>
201 <p>The web services that comprise much of the Virtual Observatory (VO)
202 come in two forms: SOAP-based (Simple Object Access Protocol, [1])
203 ones such as footprint and spectrum services [2], SkyNodes and Open
204 SkyQuery [3], registry interfaces [4] and CDS access [5]; and RESTful
205 (REpresentational State Transfer, [6]) ones such as TAP [7] and other
206 second generation data access (DAL) services, and VOSpace 2.0
207 [8]. This document describes a set of common basic functions that all
208 these services should provide in the form of a standard support interface
209 in order to support the effective management of the VO.
210 </p>
211 <p>
212 The IVOA Web Services Basic Profile [9] mandates that a compliant
213 SOAP-based web service should have the interface defined in this
214 specification, as expressed using the standard WSDL (Web Services
215 Description Language, [10]) format. For RESTful services, the
216 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>
217
218
219 <h3><a name="sec1_1">1.1 The role in the IVOA Architecture</a></h3>
220 <p>The IVOA Architecture [11] provides a high-level view of how IVOA
221 standards work together to connect users and applications with
222 providers of data and services, as depicted in the diagram in Fig. 1.
223 </p>
224
225 <p>
226 <center>
227 <font size="-1">
228 <img src="vosi-in-arch.png" width="756"/> <br />
229 <blockquote>
230 <strong>Figure 1. VOSI in the IVOA Architecture.</strong>
231 VOSI is the standard that defines the basic functions that all VO
232 services should provide in order to support management of the VO.
233 </blockquote>
234 </font>
235 </center>
236 </p>
237
238 <p>In this architecture, users employ a variety of tools (from the
239 User Layer) to discover and access archives and services--that is,
240 resources--of interest (represented in the Resource Layer). A
241 registry plays a role in discovery by harvesting metadata that
242 describe archives and services and making them searchable from a
243 central service. The VOSI interface provides a means for a service to
244 provide some of this metadata itself; this allows a registry to pull
245 the metadata from the service rather than relying on a human to
246 provide it (e.g. by typing the data into a registration form
247 manually). This mechanism can make it easier to collect highly
248 detailed metadata (e.g. descriptions of columns in a catalog) that
249 might not be practically provided otherwise. As some of this metadata
250 describes the service interface and how it behaves, other applications
251 can use this information for controlling how they use the service.
252 Even when the service is "discovered" through some means other than a
253 registry, an application can still understand how to use the service
254 by querying for this information directly. (See
255 <a href="#appB">Appendix B</a> for a more detailed description of this
256 use case.) </p>
257
258 <p>
259 Once a user discovers data and services of interest, she will want to
260 use engage them in an analysis process. Success requires that the selected
261 services are actually up and running properly as a down service can
262 cause auotmated processing to fail completely. Registry and workflow
263 services can assist with this by tracking the availability of
264 services and alerting users about downtime. We envision that VOSI
265 will allow VO projects to better track the overall health of the VO
266 ecosystem.
267 </p>
268
269
270 <h2><a name="sec2">2. Interface bindings</a></h2>
271 <p>The standard interface returns metadata without changing the
272 state of the service with which it is associated. This could, in principle, be
273 implemented in any of three ways:</p>
274 <ol type="1">
275 <li> As extra SOAP operations on an existing SOAP endpoint of the
276 service with which it is associated. This would be a 'SOAP binding' of VOSI.
277 <li> As SOAP operations on a separate SOAP endpoint. This would be an alternate form of the SOAP binding.
278 <li> As web resources with distinct URLs, without using the SOAP protocol. This is the 'REST binding' for the standard interface.
279 </ol><p>
280 This standard requires the REST binding of VOSI even when applied to
281 services that otherwise use SOAP. No details of the SOAP binding are
282 given in this version of the standard. </p>
283 <p>
284 In the REST binding, the support interfaces shall have distinct URLs
285 in the HTTP scheme and shall be accessible by the GET operation in the
286 HTTP protocol. The response to an HTTP POST, PUT or DELETE to these
287 resources is not defined by this specification. However, if an
288 implementation has no special action to perform for these requests,
289 the normal response would be a HTTP 405 "Method not allowed" status code. </p><p>
290 The endpoints and interface types for the support interface shall be
291 defined in the service's registration using one <i>Capability</i> element for
292 each interface. The values of the <i>standardID</i> attribute for these <i>Capability</i>s are given in section 4.</p><p>
293 When using the REST binding, any HTTP URLs may be used. The client
294 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>
295 </p>
296
297
298 <h2><a name="sec3">3. Metadata specification</a></h2>
299 <p>
300 There are various classes of metadata that might be returned by a
301 service through its standard interface:</p>
302 <ul>
303 <li> those describing its functional capabilities
304 <li> those describing its operational behaviour - availability,
305 reliability, etc.
306 <li> those describing tabular data handled by the service
307 <li> those describing other aspects of the service
308 </ul>
309 <p>This section defines how each of these classes is represented. The
310 following typographic convention is used to represent a XML element defined
311 within a particular namespace:</p>
312 <pre>
313 {http://some.name.space}elementName
314 </pre>
315 <p>For example,
316 <i>{http://www.ivoa.net/xml/VOResource/v1.0}resource</i> indicates a
317 XML element named <i>resource</i> that is described in the XML schema
318 associated with the 'http://www.ivoa.net/xml/VOResource/v1.0'
319 namespace - in this case, this would be VOResource.xsd [12].
320 </p>
321
322 <h3><a name="sec3_1">3.1 Capability metadata</a></h3>
323
324 <p></p
325 <blockquote>
326 <table bgcolor="#dddddd" border="2" cellpadding="5"><tbody><tr><td>
327 <dl style="margin-top: 0pt; margin-bottom: 0pt">
328 <dt> <strong>Note:</strong> </dt>
329 <dd>'Capability' is unfortunately an overloaded term in the VO
330 referring to both a functional aspect of a service
331 and also particular pieces of metadata defined by various XML
332 schema. When referring to an XML element called 'capability', it
333 shall be be put in italics. Its parent namespace may also be
334 included (using the syntax described above) if it is ambiguous
335 which XML schema is being referred to.
336 </dd>
337 </dl>
338 </td></tr></tbody></table>
339 </blockquote>
340 <p></p>
341
342 <p>This interface provides the service metadata in the form of a list
343 of <i>Capability</i> descriptions. Each of these descriptions is an XML element that: </p>
344 <ul>
345 <li> states that the service provides a particular, IVOA-standard function;
346 <li> lists the interfaces for invoking that function;
347 <li> records any details of the implementation of the function that
348 are not defined as default or constant in the standard for that function.
349 </ul>
350 <p>
351 For example, one capability might describe a cone search function and
352 another the TAP implementation but these two might well apply to the same service.</p><p>
353 An entry for a service in the resource registry - i.e., its VOResource
354 - contains the Dublin Core resource metadata (identifier, curation
355 information, content description, etc.) followed by the service's
356 capability descriptions (expressed as a series of
357 <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>
358 <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.
359 <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.
360 </ul></p>
361
362 <p>
363 The service metadata shall be represented as an XML document with the
364 root element
365 <i>{http://www.ivoa.net/xml/VOSICapabilities/v1.0}capabilities</i>.
366 (See <a href="#appA1">Appendix A.1</a> for the definition of the
367 VOSICapabilities XML schema.) This element must contain one or more child
368 <i>capability</i> elements that describe the capabilities of the
369 service. Given that the <i>capability</i> element is defined to be of type
370 <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i>, a <i>capability</i>
371 element may be represented by a legal sub-type of
372 <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i>, in which
373 case, the <i>capability</i> element must use an <i>xsi:type</i>
374 attribute to identify the sub-type (see section 2.2.1 of
375 [<a href="#ref:vor">1</a>]).
376 </p>
377
378 <p></p
379 <blockquote>
380 <table bgcolor="#dddddd" border="2" cellpadding="5"><tbody><tr><td>
381 <dl style="margin-top: 0pt; margin-bottom: 0pt">
382 <dt> <strong>Note:</strong> </dt>
383 <dd> The value of the <i>capability</i> element's standardID attribute is used
384 to indicate the service's support for particular standard protocols
385 (such as Simple Image Access, Simple Cone Search, etc.). In the
386 case of some protocols, the support for the standard is further
387 characterized by additional metadata provided by a standard XML
388 schema extension of <i>Capability</i> for that protocol. The extension metadata is enabled by
389 adding a <i>xsi:type</i> attribute to the <i>capability</i> element set to the
390 <i>Capability</i> sub-type value defined in the extension schema for that protocol (see example below). </dd>
391 </dl>
392 </td></tr></tbody></table>
393 </blockquote>
394 <p></p>
395
396 <p>
397 The VOResource list of capabilities should include capabilities describing VOSI
398 endpoints as specified in section 4.
399 </p>
400
401
402 <p>
403 In the REST binding, the service metadata shall be a single web
404 resource with a registered URL. The date and time at which the
405 metadata last changed shall be obtained from the <i>Last-Modified</i>
406 HTTP Header keyword sent in the response to a GET or HEAD request to the registered URI.</p><p>
407 All VO services should provide this interface.
408 </p>
409
410 <h3><a name="sec3_2">3.2 Non-service metadata (non-normative)</a></h3>
411 <p>There may be other metadata associated with a service than the capability metadata described above.
412 <ul><li> Every service has the Dublin Core resource metadata [13].
413 <li> Some services are associated with registered applications.
414 <li> Some services are associated with registered data collections.
415 </ul></p><p>None of these are explicitly provided for in this version of VOSI. Some might be covered in later versions of VOSI.
416 </p>
417
418 <h3><a name="sec3_3">3.3 Availability metadata</a></h3>
419 <p>This interface indicates whether the service is operable and the reliability of the service for extended and scheduled requests.
420 The availability shall be represented as an XML document in which the
421 root element is <i>{http://www.ivoa.net/xml/Availability/v1.0}availability</i>. This element
422 shall contain child elements providing the following information.</p>
423 <ul>
424 <li> <i>available</i> - whether the service is currently accepting requests
425 <li> <i>upSince</i> - duration for which the service has been continuously available
426 <li> <i>downAt</i> - the instant at which the service is next scheduled to be unavailable
427 <li> <i>backAt</i> - the instant at which the service is scheduled to become available again after down time;
428 <li> <i>note</i> - textual note, e.g. explaining the reason for unavailaility.
429 </ul><p>
430 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>
431 The XML document shall conform to the schema given in appendix A.2 of this specification.</p><p>
432 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>
433 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>
434 There are no special elements in the availability document for the
435 contact details of the service operator. These details may be given as
436 a <i>note</i> element if they are known to the service.</p>
437 <p>
438 In the REST binding, the availability shall be a single web resource with a registered URL</p><p>
439 All VO services shall provide this interface.
440 </p>
441
442 <h3><a name="sec3_4">3.4 Table metadata</a></h3>
443 <p>
444 Some services deal with tabular data. These data may be the target of
445 ADQL queries, as in TAP [7], 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>
446 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>
447 A service which uses tables in its interface should define a VOSI
448 endpoint from which table metadata can be read. The table metadata
449 shall be represented as an XML document of which the root element is
450 of type
451 <i>{http://www.ivoa.net/xml/VODataService/v1.1}TableSet</i>. This
452 element may contain any mix of elements allowed by the VODataService
453 XML schema.</p><p>
454 In the REST binding, the table metadata shall be a single web resource with a registered URL.
455 </p>
456
457 <h2><a name="sec4">4. Registration of VOSI endpoints</a></h2>
458 <p>
459 The endpoints for the service and availability metadata shall be
460 included in the registration of each service that provides them.
461 </p>
462 <center>
463 <table>
464 <tr><th align="left">Endpoint type</th><th align="left">standardID value</th></tr>
465 <tr><td>availability</td><td>ivo://ivoa.net/std/VOSI#availability</td></tr>
466 <tr><td>capabilties</td><td>ivo://ivoa.net/std/VOSI#capabilities</td></tr>
467 <tr><td>tables</td><td>ivo://ivoa.net/std/VOSI#tables</td></tr>
468 </table>
469 </center>
470 <p>
471 An availability endpoint shall be represented by an element named
472 <i>capability</i>, of type
473 <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i> (defined by
474 the standard VOResource XML schema [<a href="ref:12">12</a>]). The
475 value of the <i>standardID</i> attribute of the <i>capability</i>
476 shall be <i>ivo://ivoa.net/std/VOSI#availability</i>.
477 </p>
478
479 <p>
480 A capabilities endpoint should be represented by an element named
481 <i>capability</i>, of type
482 <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i>. If such
483 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>
484 A tables endpoint should be represented by an element named
485 <i>capability</i>, of type
486 <i>{http://www.ivoa.net/xml/VOResource/v1.0}Capability</i>. If such
487 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>.
488 </p>
489
490 <p>
491 With all three VOSI functions, the capability element that describes
492 the function must contain an interface element of a type semantically
493 appropriate for the binding of the function to the service; the
494 <i>accessURL</i> element within the interface element indicates the
495 endpoint for the VOSI function. For the REST binding, this
496 <i>accessURL</i> element must set the <i>use</i> attribute to "full".
497 Furthermore, for the REST binding, this document recommends using the
498 <i>{http://www.ivoa.net/xml/VODataService/v1.1}ParamHTTP</i> interface
499 type to encode VOSI endpoints (see example given in section 2.1).
500 </p>
501
502
503 <h2><a name="sec5">5. Example VOSI responses</a></h2>
504
505 <!-- Space to push page break in PDF version
506 <br />
507 <br />
508 -->
509
510 <div class="exampleOuter">
511 <a name="ex:caps">
512 </a><div class="exampleHeader">Example 1:</div>
513 <div class="exampleWrapper">A sample response from a capabilities
514 resource describing an SIA service. </div>
515 <div class="exampleInner" style="background-color: rgb(213, 222, 227);">
516 <pre>&lt;?xml version="1.0" encoding="UTF-8"?&gt;
517 &lt;vosi:capabilities xmlns:vosi="http://www.ivoa.net/xml/VOSICapabilities/v1.0"
518 xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
519 xmlns:vs="http://www.ivoa.net/xml/VODataService/v1.0"
520 xmlns:sia="http://www.ivoa.net/xml/SIA/v1.0"
521 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
522 xsi:schemaLocation="http://www.ivoa.net/xml/VOSI/v1.0
523 http://www.ivoa.net/xml/VOSI/v1.0
524 http://www.ivoa.net/xml/VOResource/v1.0
525 http://www.ivoa.net/xml/VOResource/v1.0
526 http://www.ivoa.net/xml/VODataService/v1.0
527 http://www.ivoa.net/xml/VODataService/v1.0
528 http://www.ivoa.net/xml/SIA/v1.0
529 http://www.ivoa.net/xml/SIA/v1.0"&gt;
530
531 &lt;!-- a generic capability (for custom, non-standard interfaces) --&gt;
532 &lt;capability&gt;
533 &lt;interface xsi:type="vr:WebBrowser"&gt;
534 &lt;accessURL use="full"&gt; http://adil.ncsa.uiuc.edu/siaform.html &lt;/accessURL&gt;
535 &lt;/interface&gt;
536 &lt;/capability&gt;
537
538 &lt;!-- the SIA capability --&gt;
539 &lt;capability xsi:type="sia:SimpleImageAccess" standardID="ivo://ivoa.net/std/SIA"&gt;
540 &lt;interface xsi:type="vs:ParamHTTP" role="std"&gt;
541 &lt;accessURL&gt; http://adil.ncsa.uiuc.edu/cgi-bin/voimquery?survey=f&amp;amp; &lt;/accessURL&gt;
542 &lt;/interface&gt;
543
544 &lt;imageServiceType&gt;Pointed&lt;/imageServiceType&gt;
545 &lt;maxQueryRegionSize&gt;
546 &lt;long&gt;360.0&lt;/long&gt;
547 &lt;lat&gt;180.0&lt;/lat&gt;
548 &lt;/maxQueryRegionSize&gt;
549 &lt;maxImageExtent&gt;
550 &lt;long&gt;360.0&lt;/long&gt;
551 &lt;lat&gt;180.0&lt;/lat&gt;
552 &lt;/maxImageExtent&gt;
553 &lt;maxImageSize&gt;
554 &lt;long&gt;5000&lt;/long&gt;
555 &lt;lat&gt;5000&lt;/lat&gt;
556 &lt;/maxImageSize&gt;
557 &lt;maxFileSize&gt;100000000&lt;/maxFileSize&gt;
558 &lt;maxRecords&gt;5000&lt;/maxRecords&gt;
559 &lt;/capability&gt;
560
561 &lt;!-- the interface that returns this document --&gt;
562 &lt;capability standardID="ivo://ivoa.net/std/VOSI#capabilities"&gt;
563 &lt;interface xsi:type="vs:ParamHTTP" role="std"&gt;
564 &lt;accessURL use="full"&gt; http://adil.ncsa.uiuc.edu/cgi-bin/voimquery/capabilities &lt;/accessURL&gt;
565 &lt;/interface&gt;
566 &lt;/capability&gt;
567
568 &lt;!-- the interface that returns this document --&gt;
569 &lt;capability standardID="ivo://ivoa.net/std/VOSI#availability"&gt;
570 &lt;interface xsi:type="vs:ParamHTTP" role="std"&gt;
571 &lt;accessURL use="full"&gt; http://adil.ncsa.uiuc.edu/cgi-bin/voimquery/availability &lt;/accessURL&gt;
572 &lt;/interface&gt;
573 &lt;/capability&gt;
574 &lt;/vosi:capabilities&gt;
575 </pre>
576 </div></div>
577 <br/>
578 <div class="exampleOuter">
579 <a name="ex:caps">
580 </a><div class="exampleHeader">Example 2:</div>
581 <div class="exampleWrapper">A sample response from a tables
582 resource describing a TAP service. </div>
583 <div class="exampleInner" style="background-color: rgb(213, 222, 227);">
584 <pre>
585 &lt;?xml version="1.0" encoding="UTF-8"?>
586 &lt;vosi:tableset
587 xmlns:vosi="http://www.ivoa.net/xml/VOSITables/v1.0"
588 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
589 xmlns:vod="http://www.ivoa.net/xml/VODataService/v1.1">
590 &lt;schema>
591 &lt;name>cfht &lt;/name>
592 &lt;table type="output">
593 &lt;name>cfht.deepU &lt;/name>
594 &lt;column>
595 &lt;name>cfhtlsID &lt;/name>
596 &lt;dataType xsi:type="vod:TAP" size="30">adql:VARCHAR &lt;/dataType>
597 &lt;/column>
598 &lt;column>
599 &lt;name>survey &lt;/name>
600 &lt;dataType xsi:type="vod:TAP" size="6">adql:VARCHAR &lt;/dataType>
601 &lt;/column>
602 &lt;column>
603 &lt;name>field &lt;/name>
604 &lt;dataType xsi:type="vod:TAP" size="2">adql:VARCHAR &lt;/dataType>
605 &lt;/column>
606 &lt;column>
607 &lt;name>pointing &lt;/name>
608 &lt;dataType xsi:type="vod:TAP" size="6">adql:VARCHAR &lt;/dataType>
609 &lt;/column>
610 &lt;column>
611 &lt;name>selectionFilter &lt;/name>
612 &lt;dataType xsi:type="vod:TAP" size="2">adql:VARCHAR &lt;/dataType>
613 &lt;/column>
614 &lt;/table>
615 &lt;table type="output">
616 &lt;name>TAP_SCHEMA.keys &lt;/name>
617 &lt;column>
618 &lt;name>key_id &lt;/name>
619 &lt;description>unique key to join to TAP_SCHEMA.key_columns &lt;/description>
620 &lt;dataType xsi:type="vod:TAP" size="64">adql:VARCHAR &lt;/dataType>
621 &lt;/column>
622 &lt;column>
623 &lt;name>from_table &lt;/name>
624 &lt;description>the table with the foreign key &lt;/description>
625 &lt;dataType xsi:type="vod:TAP" size="64">adql:VARCHAR &lt;/dataType>
626 &lt;/column>
627 &lt;column>
628 &lt;name>target_table &lt;/name>
629 &lt;description>the table with the primary key &lt;/description>
630 &lt;dataType xsi:type="vod:TAP" size="64">adql:VARCHAR &lt;/dataType>
631 &lt;/column>
632 &lt;/table>
633 &lt;/schema>
634 &lt;/vosi:tableset>
635 </pre>
636 </div></div>
637
638
639 <br/>
640 <h2><a name="appA">Appendix A: VOSI XML schemas</a></h2>
641
642 <a name="appA1">
643 <h3>A.1. The Complete VOSICapabilities Schema</h3></a>
644
645 <pre>&lt;xsd:schema targetNamespace="http://www.ivoa.net/xml/VOSICapabilities/v1.0"
646 xmlns:tns="http://www.ivoa.net/xml/VOSICapabilities/v1.0"
647 xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
648 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
649 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
650 elementFormDefault="qualified"
651 attributeFormDefault="unqualified"
652 version="1.0rc1"&gt;
653
654 &lt;xsd:annotation&gt;
655 &lt;xsd:documentation&gt;
656 A schema for formatting service capabilities as returned by a
657 capabilities resource, defined by the IVOA Support Interfaces
658 specification (VOSI).
659 See http://www.ivoa.net/Documents/latest/VOSI.html.
660 &lt;/xsd:documentation&gt;
661 &lt;/xsd:annotation&gt;
662
663 &lt;xsd:import namespace="http://www.ivoa.net/xml/VOResource/v1.0"
664 schemaLocation="http://www.ivoa.net/xml/VOResource/v1.0" /&gt;
665
666 &lt;!--
667 - the root element for a VOSI capabilities metadata (section 3.1)
668 --&gt;
669 &lt;xsd:element name="capabilities"&gt;
670 &lt;xsd:annotation&gt;
671 &lt;xsd:documentation&gt;
672 A listing of capabilities supported by a service
673 &lt;/xsd:documentation&gt;
674 &lt;/xsd:annotation&gt;
675
676 &lt;xsd:complexType&gt;
677 &lt;xsd:sequence&gt;
678
679 &lt;xsd:element name="capability" type="vr:Capability"
680 form="unqualified" minOccurs="0" maxOccurs="unbounded"&gt;
681 &lt;xsd:annotation&gt;
682 &lt;xsd:documentation&gt;
683 A capability supported by the service.
684 &lt;/xsd:documentation&gt;
685 &lt;xsd:documentation&gt;
686 A protocol-specific capability is included by specifying a
687 vr:Capability sub-type via an xsi:type attribute on this
688 element.
689 &lt;/xsd:documentation&gt;
690 &lt;/xsd:annotation&gt;
691 &lt;/xsd:element&gt;
692
693 &lt;/xsd:sequence&gt;
694 &lt;/xsd:complexType&gt;
695 &lt;/xsd:element&gt;
696
697 &lt;/xsd:schema&gt;
698 </pre>
699
700 <a name="appA2">
701 <h3>A.2. The Complete VOSIAvailability Schema</h3></a>
702
703 <pre>&lt;xsd:schema targetNamespace="http://www.ivoa.net/xml/VOSIAvailability/v1.0"
704 xmlns:tns="http://www.ivoa.net/xml/VOSIAvailability/v1.0"
705 xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
706 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
707 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
708 elementFormDefault="qualified"
709 attributeFormDefault="unqualified"
710 version="1.0rc1"&gt;
711
712 &lt;xsd:annotation&gt;
713 &lt;xsd:documentation&gt;
714 A schema for formatting availability metadata as returned by an
715 availability resource defined in the IVOA Support Interfaces
716 specification (VOSI).
717 See http://www.ivoa.net/Documents/latest/VOSI.html.
718 &lt;/xsd:documentation&gt;
719 &lt;/xsd:annotation&gt;
720
721 &lt;!--
722 - the root element for a VOSI availability (section 3.3)
723 --&gt;
724 &lt;xsd:element name="availability" type="tns:Availability"/&gt;
725
726 &lt;xsd:complexType name="Availability"&gt;
727 &lt;xsd:sequence&gt;
728
729 &lt;xsd:element name="available" type="xsd:boolean"&gt;
730 &lt;xsd:annotation&gt;
731 &lt;xsd:documentation&gt;
732 Indicates whether the service is currently available.
733 &lt;/xsd:documentation&gt;
734 &lt;/xsd:annotation&gt;
735 &lt;/xsd:element&gt;
736
737 &lt;xsd:element name="upSince" type="xsd:dateTime" minOccurs="0"&gt;
738 &lt;xsd:annotation&gt;
739 &lt;xsd:documentation&gt;
740 The instant at which the service last became available.
741 &lt;/xsd:documentation&gt;
742 &lt;/xsd:annotation&gt;
743 &lt;/xsd:element&gt;
744
745 &lt;xsd:element name="downAt" type="xsd:dateTime" minOccurs="0"&gt;
746 &lt;xsd:annotation&gt;
747 &lt;xsd:documentation&gt;
748 The instant at which the service is next scheduled to become
749 unavailable.
750 &lt;/xsd:documentation&gt;
751 &lt;/xsd:annotation&gt;
752 &lt;/xsd:element&gt;
753
754 &lt;xsd:element name="backAt" type="xsd:dateTime" minOccurs="0"&gt;
755 &lt;xsd:annotation&gt;
756 &lt;xsd:documentation&gt;
757 The instant at which the service is scheduled to become available
758 again after a period of unavailability.
759 &lt;/xsd:documentation&gt;
760 &lt;/xsd:annotation&gt;
761 &lt;/xsd:element&gt;
762
763 &lt;xsd:element name="note" type="xsd:string"
764 minOccurs="0" maxOccurs="unbounded"&gt;
765 &lt;xsd:annotation&gt;
766 &lt;xsd:documentation&gt;
767 A textual note concerning availability.
768 &lt;/xsd:documentation&gt;
769 &lt;/xsd:annotation&gt;
770 &lt;/xsd:element&gt;
771
772 &lt;/xsd:sequence&gt;
773 &lt;/xsd:complexType&gt;
774
775 &lt;/xsd:schema&gt;
776 </pre>
777
778 <a name="appA3">
779 <h3>A.3. The Complete VOSITables Schema</h3></a>
780 <pre>
781 &lt;xsd:schema targetNamespace="http://www.ivoa.net/xml/VOSICapabilities/v1.0"
782 xmlns:tns="http://www.ivoa.net/xml/VOSICapabilities/v1.0"
783 xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
784 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
785 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
786 elementFormDefault="qualified"
787 attributeFormDefault="unqualified"
788 version="1.0">
789
790 &lt;xsd:annotation>
791 &lt; xsd:documentation>
792 A schema for formatting table metadata as returned by a
793 tables resource, defined by the IVOA Support Interfaces
794 specification (VOSI).
795 See http://www.ivoa.net/Documents/latest/VOSI.html.
796 &lt;/xsd:documentation>
797 &lt;/xsd:annotation>
798
799 &lt;xsd:import namespace="http://www.ivoa.net/xml/VODataService/v1.1"
800 schemaLocation="http://www.ivoa.net/xml/VODataService/v1.1" />
801
802 &lt;!--
803 - the root element for a VOSI table metadata (section 3.4)
804 -->
805 &lt;xsd:element name="tableset" type="vs:TableSet" >
806 &lt;xsd:annotation>
807 &lt;xsd:documentation>
808 A description of the table metadata supported by the
809 service associated with a VOSI-enabled resource.
810 &lt;/xsd:documentation>
811 &lt;/xsd:annotation>
812 &lt;/xsd:element>
813
814 &lt;/xsd:schema>
815 </pre>
816
817 <h2><a name="appB">Appendix B: Use Case for Capability Harvesting
818 (non-normative)</a></h2>
819
820 <p>
821 In the <a href="#sec1_2">section 1.2</a>, we summarized the of the role
822 the metadata retrieval functions (sections <a href="#sec3_1">3.1</a>
823 and <a href="#sec3_4">3.4</a>) play in the discovery of services. In
824 particular, it mentions that a registry can harvest this information
825 from a service's VOSI interface to save the provider from entering the
826 information explicitly into a web form. In this appendix, we describe
827 this use case in more detail, including both the publishing of the
828 metadata and its typical use by service clients.
829 </p>
830
831 <p>
832 Some publishing registries [4] provide a publically accessible
833 publishing tool: it allows any data service provider to "register" his
834 service by providing the necessary metadata adequate to describe it.
835 Such a tool typically provides a form that the provider fills out to
836 enter all the metadata; the form processor uses those inputs to format
837 a VOResource record that describes the service based on that metadata.
838 Prior to the registry's support for the VOSI metadata functions,
839 entering all of the metadata (particularly, fully describing all of
840 the table columns) would often be laborious; consequently, providers
841 are effectively discouraged from providing the mostly optional
842 information.
843 </p>
844
845 <p>
846 With support for the VOSI metadata functions, the registry's
847 publishing tool can now offer an alternative mechanism for providing
848 much of the information. After generally describing the service via
849 core metadata (e.g. it's title, identifier, general description, contact
850 information, etc.), the registry can offer the option of entering the
851 VOSI URLs that provide the capability and table metadata. In the case
852 of TAP, where these VOSI functions are mandated as part of the TAP
853 interface, it would only be necessary for the user to enter the TAP
854 service's base URL (in VOResource parlance, the "access URL"). In
855 either case, the tool would access the VOSI URLs, pull over the
856 metadata, integrate it into the core metadata, and show the provider the
857 combined results before publishing it to the registry. The tool might
858 also ask the provider if this data is expected to change over time and
859 thus whether the VOSI URLs should be polled regularly to update the
860 service description held by the registry. Alternatively, the tool may
861 may allow the provider to quickly update the service description via a
862 single button click that causes the tool to re-access the VOSI
863 endpoints and refresh service description held by the registry.
864 </p>
865
866 <p>
867 We note that pulling certain metadata from the service itself is
868 expected to save the provider time and effort because the information
869 is in large part inherently available to the service implementation.
870 This most obviously applies to the table metadata: the provider's
871 underlying database will normally have access to table schemas which
872 can be used to provide, for instance, detailed descriptions of all the
873 tables and their columns. It is less natural, perhaps, for the
874 service to have access to the capability information; however, with
875 the growing use of service toolkits that allow a provider to quickly
876 deploy compliant IVOA services, it is possible that the capability
877 information could naturally be assembled from the configuration
878 information that was used to set up the service. Of course, if the
879 provider is forced to create static XML documents manually to
880 implement the VOSI functions, it's unlikely that this has saved the
881 her any time over entering the metadata into a publishing tool.
882 </p>
883
884 <p>
885 A key goal of the VOSI metadata functions is to encourage the capture
886 of metadata that is useful for discovering and selecting services that
887 a user will want to work with. For example, a user may wish to find
888 services that access a table containing redshift values. Or, a user
889 may wish to find Simple Spectral Services (a particular capability)
890 that are fully compliant. A second goal is to make that metadata
891 available so that the user can plan its use of the service: for
892 example, the user, through some tool, might browse through the table
893 column descriptions to figure out how to form her query. In this
894 latter use, the client tool can either use the registry as the source
895 of this information or the service itself via its VOSI functions. The
896 question that arises for the client tool developer then is, which
897 source--the registry or the service--should be preferred?
898 </p>
899
900 <p>
901 This VOSI specification does not recommend the use of one source over
902 the other. The choice, in general, will depend on the context of a
903 particular client tool and what it is trying to do, and the
904 preferences of developers may indeed evolve over time as, say, VOSI
905 support becomes more ubiquitous. At least initially, client
906 tools--particularly general ones that can engage different kinds of
907 service protocols--will likely prefer to use the registry for the
908 source of capability and table metadata. The main reason would be
909 that not all services will be implemented to support VOSI. By going
910 to the registry in this case, the client gets this metadata for both
911 services where it was retrieved via VOSI <em>and</em> where it was
912 entered explicitly into a publishing tool by the provider. Under
913 certain circumstances however, say, where the client works with just
914 one kind of service protocol like TAP in which VOSI support is
915 mandated for compliance, the VOSI interface might be the preferred
916 source. In particular, if the service URL was obtained by the client
917 through some means other than the discovery in a registry, then it
918 would not be necessary for the client to go to the registry understand
919 what can be done with the service; the tool can get this information
920 from the service itself.
921 </p>
922
923 <p>
924
925 We have implied in the above discussion that the capability and table
926 metadata are the same whether they are retrieved from the registry or
927 from the service. It is possible, however, that the service could
928 change--new capabilities or table columns could be added--and the
929 registry could (at least temporarily, depending on the registry) get
930 out of sync with the service. This circumstance may occur rarely;
931 nevertheless, if being up-to-date is important, then the client may
932 need to be more sophisticated in its retrieval. That is, it could
933 retrieve the resource description from the registry; then if the
934 description indicates support for VOSI, the VOSI URLs would be
935 accessed to get the latest, up-to-date information.
936
937 </p>
938
939
940 <h2><a name="appC">Appendix C: Changes from previous versions</a></h2>
941
942 <h4>Changes since PR-20101206</h4>
943 <ul>
944 <li> Added Appendix B, use case discussion </li>
945 </ul>
946
947 <h4>Changes since PR-20100311</h4>
948 <ul>
949 <li>Inclusion of IVOA Architecture text </li>
950 <li>Restructuring and clarification in response to RFC comments</li>
951 <li>Inclusion of VOSITables schema in appendix</li>
952 <li>Second example added for a TAP service response</li>
953 </ul>
954
955 <h4>Changes since WD-20090825</h4>
956
957 <ul>
958 <li> Mandate the use of VOSICapabilities to return capabilities </li>
959 <li> S2.1: added non-normative note about capability sub-types; added
960 example capabilities metadata </li>
961 <li> Recommend the inclusion of VOSI interfaces in capability metadata</li>
962 <li> S2.5: When returning capabilities metadata, require VOSI (REST)
963 accessURLs to have use="full"; recommend this use of ParamHTTP. </li>
964 <li> Rename Availability schema to VOSIAvailability; added
965 VOSICapabilities schema. </li>
966 </ul>
967
968 <h4>Changes since WD-20081030</h4>
969
970 <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>
971 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>.
972 </p>
973
974 <br/>
975 <h2><a name="ref">References</a></h2>
976
977 <dl>
978
979
980 <dt> <a name="ref:0">[0]</a> </dt>
981 <dd> <cite>
982 <a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119</a></cite>,
983 <code>http://www.ietf.org/rfc/rfc2119.txt</code>
984 </dd>
985
986
987 <dt> <a name="ref:1">[1]</a> </dt>
988 <dd> <cite>
989 <a href="http://www.w3.org/TR/soap">Simple Object Access
990 Protocol (SOAP)</a></cite>,
991 <code>http://www.w3.org/TR/soap</code>
992 </dd>
993
994
995 <dt> <a name="ref:2">[2]</a> </dt>
996 <dd> <cite>
997 <a href="http://voservices.net">Footprint and spectrum services</a></cite>,
998 <code>http://voservices.net</code>
999 </dd>
1000
1001 <dt> <a name="ref:3">[3]</a> </dt>
1002 <dd> <cite>
1003 <a href="http://openskyquery.net">Skynodes and Open SkyQuery</a></cite>,
1004 <code>http://openskyquery.net</code>
1005 </dd>
1006
1007 <dt> <a name="ref:4">[4]</a></dt><dd>Benson, K., Plante, R., Auden, E.,
1008 Graham, M., Greene, G., Hill, M., Linde, T., Morris, D., O'Mullane,
1009 W., Rixon, G., St&eacute;b&eacute;, A., Andrews, K., 2009, <cite>
1010 <a href="http://www.ivoa.net/Documents/RegistryInterface">IVOA
1011 Registry Interfaces</a></cite>, v1.0, IVOA Recommendation,
1012 <code>http://www.ivoa.net/Documents/RegistryInterface</code>
1013 </dd>
1014
1015 <dt> <a name="ref:5">[5]</a> </dt>
1016 <dd> <cite>
1017 <a href="http://cdsweb.u-strasbg.fr/cdsws.gml">CDS web services</a></cite>,
1018 <code>http://cdsweb.u-strasbg.fr/cdsws.gml</code>
1019 </dd>
1020
1021 <dt> <a name="ref:6">[6]</a> </dt>
1022 <dd> <cite>
1023 <a href="http://en.wikipedia.org/wiki/Representational_State_Transfer">REpresentational State Transfer (REST)</a></cite>,
1024 <code>http://en.wikipedia.org/wiki/Representational_State_Transfer</code>
1025 </dd>
1026
1027 <dt> <a name="ref:7">[7]</a> </dt>
1028 <dd> Dowler, P., Rixon, G., Tody, D., 2010, <cite>
1029 <a
1030 href="http://www.ivoa.net/Documents/TAP/20100327/REC-TAP-1.0.html">Table
1031 Access Protocol</a></cite>, v1.0, IVOA Recommmendation,
1032 <code>http://www.ivoa.net/Documents/TAP/20100327/REC-TAP-1.0.html</code>
1033 </dd>
1034
1035 <dt> <a name="ref:8">[8]</a> </dt>
1036 <dd> Graham, M., Morris, D., Rixon, G., Dowler, P., Schaaff, A.,
1037 Tody, D., 2010, <cite>
1038 <a
1039 href="http://www.ivoa.net/Documents/VOSpace/20101112/WD-VOSpace-2.0-20101112.html">VOSpace
1040 specification</a></cite>, v2.00, IVOA Working Draft,
1041 <code>http://www.ivoa.net/Documents/VOSpace/20101112/WD-VOSpace-2.0-20101112.html</code>
1042 </dd>
1043
1044 <dt> <a name="ref:9">[9]</a> </dt>
1045 <dd> Grid and Web Services Working Group, 2010, <cite>
1046 <a
1047 href="http://www.ivoa.net/Documents/VOSI/20100311/PR-VOSI-1.0-20100311.html">IVOA
1048 Support Interfaces</a></cite>, v1.00, IVOA Proposed Recommendation,
1049 <code>http://www.ivoa.net/Documents/VOSI/20100311/PR-VOSI-1.0-20100311.html</code>
1050 </dd>
1051
1052 <dt> <a name="ref:10">[10]</a> </dt>
1053 <dd> <cite>
1054 <a href="http://www.w3.org/TR/WSDL">Web Services Description Language</a></cite>,
1055 <code>http://www.w3.org/TR/WSDL</code>
1056 </dd>
1057
1058 <dt> <a name="ref:11">[11]</a> </dt>
1059 <dd> Arviset, C., Gaudet, S., IVOA Technical Coordination Group,
1060 2010, <cite>
1061 <a
1062 href="http://www.ivoa.net/Documents/Notes/IVOAArchitecture/20101123/IVOAArchitecture-1.0-20101123.pdf">IVOA
1063 Architecture</a></cite>, v1.0, IVOA Note,
1064 <code>http://www.ivoa.net/Documents/Notes/IVOAArchitecture/20101123/IVOAArchitecture-1.0-20101123.pdf</code>
1065 </dd>
1066
1067 <dt> <a name="ref:12">[12]</a> </dt>
1068 <dd> Plante, R., Benson, K., Graham, M., Greene,
1069 G., Harrison, P., Lemson, G., Linde, T., Rixon,
1070 G., St&eacute;b&eacute;, A., 2008, <cite>
1071 <a href="http://www.ivoa.net/Documents/cover/VOResource-20080222.html">
1072 VOResource: an XML Encoding Schema for Resource Metadata</a></cite>,
1073 v1.03, IVOA Recommendation,
1074 <code>http://www.ivoa.net/Documents/cover/VOResource-20080222.html</code>
1075 </dd>
1076
1077 <dt> <a name="ref:13">[13]</a> </dt>
1078 <dd> Hanisch, R., IVOA Registry Working Group, NVO Metadata Working
1079 Group, 2007, <cite>
1080 <a
1081 href="http://www.ivoa.net/Documents/REC/ResMetadata/RM-20070302.html">Resource
1082 Metadata for the Virtual Observatory</a></cite>, v.1.12, IVOA Recommendation
1083 <code>http://www.ivoa.net/Documents/REC/ResMetadata/RM-20070302.html</code>
1084 </dd>
1085
1086 <dt> <a name="ref:14">[14]</a> </dt>
1087 <dd>Plante, R., St&eacute;b&eacute;, A., Benson, K., Dowler, P., Graham, M., Greene,
1088 G., Harrison, P., Lemson, G., Linde, T., Rixon,
1089 G., IVOA Registry Working Group, 2010, <cite>
1090 <a href="http://www.ivoa.net/Documents/VODataService/20100916/PR-VODataService-1.1-20100916.html">VODataService: a VOResource Schema Extension
1091 for Describing Collections and Services</a></cite>, v1.1, IVOA
1092 Proposed Recommendation,
1093 <code>http://www.ivoa.net/Documents/VODataService/20100916/PR-VODataService-1.1-20100916.html</code>
1094 </dd>
1095
1096 </dl>
1097
1098
1099
1100 </body></html>

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