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:

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