This page collects specification issues as well as proposals for extensions for VODataService 1.1. Version 1.2, addressing most of the points below, is currently in pre-WD state. See https://volute.g-vo.org/svn/trunk/projects/registry/VODataService for where the review stands.

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
  • 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
  • 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
  • For many reasons, we DataCollections should be allowed to have capabilities. -- MarkusDemleitner - 2018-04-18

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
  • Add numerical/MOC coverage (see RegSTC note) -- MarkusDemleitner - 2018-04-18
Topic revision: r5 - 2018-10-02 - MarkTaylor
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback