of 2018-10

See also https://volute.g-vo.org/svn/trunk/projects/registry/VODataService for the bleeding edge

Specification Problems

• In current VODataService tableset, table structure is implied to be schema.table; ADQL table references, on the other hand, have one to three elements. This should be reconciled; I propose allowing table-s as direct children of tableset and prescribing full ADQL table references in table/name. -- MarkusDemleitner - 2015-05-05
  • This is in current 1.2 drafts, except that we now use anonymous schema elements for instead of having direct children (because it's saving migration in RegTAP).
• VODataService has no provisions for how SQL delimited identifiers are to be handled where that is relevant (e.g., in TAP tables endpoints). I propose to explicitly say {schema/table/column}/name "must be in forms ready for application" and mention ADQL and the respective symbols as examples. -- MarkusDemleitner - 2015-05-05
  • This is in current 1.2 drafts.
• ParamHTTP (and perhaps others) resultType is 0..1. With DALI RESPONSEFORMAT, that should probably be made 0..n. Or perhaps we should just adapt TAPRegExt's outputFormat, which already models DALI? -- MarkusDemleitner - 2018-03-16
  • There do not seem to be terribly important use cases for resultTypes. So, we'll probably leave this alone in 1.2.
• For many reasons, we DataCollections should be allowed to have capabilities. -- MarkusDemleitner - 2018-04-18
  • This has been solved by deprecating DataCollections and using CatalogResources instead.

Suggested Extensions

• Have some markup to say what dataproduct types the service will return? This would be particularly useful with ObsTAP ("what services have time series?"). -- MarkusDemleitner - 2018-04-18
  • No satisfying solutions have been suggested so far.
• Add numerical/MOC coverage (see RegSTC note) -- MarkusDemleitner - 2018-04-18
  • This is in 1.2 drafts.