(r14) TAPRegExt < IVOA

IVOA Web>IvoaDAL>TableAccess>TAPRegExt (revision 14) (raw view)~~EditAttach~~

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

---+!! TAP VOResource Extension Schema

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

---++ Towards a Working Draft (2011-01-11)

There's a first draft of TAPRegExt up on http://vo.ari.uni-heidelberg.de/docs/TAPRegExt-20110120.html.  Please comment.

The !StandardKeyEnumeration for the upload methods is currently available at http://svn.ari.uni-heidelberg.de/svn/gavo/tapregext/trunk/uploadmethods.xml

You can check out the source of the document at http://svn.ari.uni-heidelberg.de/svn/gavo/tapregext/.  If you want read/write access to that repository,
contact MarkusDemleitner.

---+++ Issues in the 2011-01-11 Internal Working Draft

   * Time and data limits are currently given as xs:integers.  Would it be preferable to be more specific and use int and long, respectively?  -- IVOA.MarkusDemleitner - 20 Jan 2011

---++ Concepts to Include

The following concepts should be captured within TAP capabilities (much of it based 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.

---+++ The Upload Problem and VOSpace

From Pat's summary of the Nara discussion:

Controlled vocabulary for  well know protocols - I would
suggest the protocol scheme in lower case as that is common usage, ivo URI for
protocols described in the registry - eg vos.

For vos URI support, we also need to specify if the service can perform
authentication, but that is already specified when a service specifies the
endpoint for the associated CDP service which would be required, so in my
opinion one can just say they support "vos" (via the URI) and that means
unauthenticated; if the service also has a supporting CDP then they can do
authenticated (CDP spec says explicitly how to do this - maybe we should at
least explicitly refer to the CDP spec section)


---+++ 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


---+++ Things deferred at Nara
   * List of settable parameters (probably open-ended as key-value pairs; for limits and such, absence would mean "unlimited", max==default would mean "changing not supported"):
   * Server settings
      * 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), return type, and a short, human-readable documentation (does plain text suffice?)


<br/>
<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->

Topic revision: r14 - 2011-01-20 - MarkusDemleitner

IVOA

Log in or Register

IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics

Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki

TWiki intro
TWiki tutorial
User registration
Notify me

Working Groups

Interest Groups

Committees

Stds&Procs

www.ivoa.net
Documents
Events
Members
XML Schema