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