| |
| META TOPICPARENT |
name="TableAccess" |
Jumps: ObsDMCoreComponents :: VOResource :: VODataService
Meetings: InterOpMay2010
TAP VOResource Extension Schema
Contents
About creating a VOResource extension
The VOResource spec has some specific recommendations about how to create an extension schema; however, a "how-to" create an extension presentation gives an introduction to the process.
In summary, the RWG recommends the following steps for defining a new extension:
- Name and define the concepts to be captured
- Create a prototype VOResource instance
- Create the Schema Extension
- Describe the extension in an IVOA document (preferably as a section of a protocol document).
Step 1: Concepts to Include |
|
<
< | This is just a prototype list of concepts to try to capture in the TAP extension. |
>
> | The following concepts should be captured within TAP capabilities (much of it mased on grepping the UWS and TAP specs for "may" and "should"): |
| | |
|
<
< |
- dataModel
- a URI identifying a data model supported by this TAP service
- the ObsCore model:
ivo://ivoa.net/std/ObsCore
- multiple entries should be allowed.
|
>
> |
- 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? |
| | |
|
>
> | 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
|
| |
<--
--> |
