TAPRegExt < IVOA

<small>Jumps:  ObsDMCoreComponents :: [[VOResource]] :: VODataService 
<br> Meetings:  InterOpMay2010  </small>

---+!! TAP VOResource Extension Schema

---+++!! Contents
%TOC%

---++ About creating a VOResource extension

The [[http://www.ivoa.net/Documents/REC/ReR/VOResource-20080222.html][VOResource spec]] has some specific recommendations about how to create an [[http://www.ivoa.net/Documents/REC/ReR/VOResource-20080222.html#extend][extension schema]]; however, a [[http://www.ivoa.net/internal/IVOA/InterOpMay2007VOEvent/IVOAHowto4VOEvent]["how-to" create an extension]] presentation gives an introduction to the process.  

In summary, the [[IvoaResReg][RWG]] recommends the following steps for defining a new extension:

   1. Name and define the concepts to be captured
   2. Create a prototype VOResource instance
   3. Create the Schema Extension
   4. Describe the extension in an IVOA document (preferably as a section of a protocol document).
 
---++ Step 1:  Concepts to Include

The following concepts should be captured within TAP capabilities (much of it mased on grepping the UWS and TAP specs for "may" and "should"):

   * List of data models exposed -- as URIs, e.g., the !ObsCore model: =ivo://ivoa.net/std/ObsCore=
   * List of query languages supported -- these should be well-known strings as used in LANG, e.g. ADQL, ADQL-2.0, etc.  They should contain a human-readable description (as element content?).  We should recommend a convention for SQL in the spirit of "SQL-Postgres", "SQL-MySQL", etc.
   * List of output formats -- specified with required MIME and optional shorthand.  Again, a human-readable description (as element content?) would be nice.
   * List of optional features (probably open-ended as key-value pairs; for limits and such, absence would mean "unlimited", max==default would mean "changing not supported"):
      * Support for table upload by standard (i.e., inline and http URL) -- do we want to define how to signal support for additional sources?
      * uploadFromVOSpace, deliveryToVOSpace -- maybe this needs to be trivalued: yes/no/unauthenticated?
      * default/maximum retention period (=destruction time-creation time)
      * default/maximum run time
      * default/maximum row limit
      * uploadRowLimit uploadByteLimit
      * maybe quoteMethod -- how does the service come up with a quote: never, always artificial value, based on a query plan, based on the length of an input queue,...
   * List of user defined functions -- with name, arguments (name, type, description) and a short, human-readable documentation (does plain text suffice?)


*Digression* on the issue of mime types: the registry document might not be the best place to specify this, but could we recommend that application/x-votable+xml should be binary data, text/xml tabledata, whereas the votable shorthand would leave the encoding to the server?
   * That sounds like a horrible hack to me.  If we want to be able to distinguish between flavours of VOTable encoding in the MIME type - is there a requirement for this? - it would surely be better to define an optional parameter of the application/x-votable+xml type, giving something like =application/x-votable+xml; encoding=binary= .  This has been vaguely discussed before in the context of VOTable, but I don't think anybody has come up with a persuasive reason it's needed.  -- IVOA.MarkTaylor - 22 Oct 2010

---+++ Things we'd probably not want in the capability

   * Extended capabilities -- if they exist, create another capability element
   * format of table names: name vs. schema.name vs. cat.schema.name -- since table names are delivered in qualified form, this is irrelevant for clients
   * VOSI support -- this can be inferred from elsewhere in the registry record
   * Passing on the RUNID -- do people need to know this from the registry?
   * Further tables in TAP_SCHEMA -- can be taken from elsewhere in the registry record






<br/>
<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->
This topic: IVOA > WebHome > IvoaDAL > TableAccess > TAPRegExt
Topic revision: r5 - 2010-10-22 - MarkTaylor