| |
| 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
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?
|
>
> |
- 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), return type, and a short, human-readable documentation (does plain text suffice?)
|
| | |
|
>
> | The Upload Problem and VOSpace |
| | |
|
<
< | 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? |
>
> | From Pat's summary of the Nara discussion: |
|
<
< |
- 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. -- MarkTaylor - 22 Oct 2010
|
| | |
|
>
> | 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 |
|
>
> |
-
- 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?)
|
| |
<--
--> |
