TWiki> IVOA Web>IvoaDAL>TableAccess>TAPRegExt (revision 18)EditAttach
Back to: DAL

Jumps: ObsDMCoreComponents :: VOResource :: VODataService
Meetings: InterOpMay2010

TAP VOResource Extension Schema


2011-11-27 Working draft

This is post-Pune; no important new features have been added, intrusive changes are limited to changed ids.

Points that may be discussed:

  • Add a feature type for supported refsystems
    • In Pune, nobody uttered strong feelings on this; I'd rather leave it out in order to discourage the use of the first argument in geometries -- MarkusDemleitner - 28 Oct 2011
  • Add an element saying whether sync and async are suppored
    • Unfortunately, there are services out there that don't support async. My take is that such services are not services conforming to ivo:// and thus shouldn't even be putting out such capability records in the first place. However, sometimes practicality beats purity, so I'd be easily swayed. -- MarkusDemleitner - 28 Oct 2011

2011-06-09 Working draft

I've put up what I think should become the next (and maybe even last?) working draft on; it's also on the way to Pat. The PDF still has quite a few formatting issues. These will be fixed in ivoapub.

This reflects what I (Markus) think was the gist of the feedback in Naples, plus a suggestion on how to generalize the userDefinedFunction element to better match other languages and an indication of geometry support.

There's a changelog at the end of the document that gives a quick idea of what changed. The only thing implementors of the last WD must change is the userDefinedFunction that now are languageFeatures; I'd consider adding ivo-ids to languages and/or output formats quite optional.

Note that the previous draft suggested some IVORNs containing an authority This, of course, doesn't exist. If you copied those IVORNs, please correct them to

TODO: I boldly claim that ADQL has a registry record ivo:// -- that's not true yet. Will anyone write one?

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? -- 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://
  • 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. vs. -- 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?)

Edit | Attach | Print version | History: r19 < r18 < r17 < r16 < r15 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r18 - 2011-10-28 - MarkusDemleitner
This site is powered by the TWiki collaboration platformCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback