This page collects specification issues as well as proposals for extensions for VODataService 1.1. No new version of the document is scheduled right now.
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 explitely 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
Added:
> >
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
This page collects specification issues as well as proposals for extensions for VODataService 1.1. No new version of the document is scheduled right now.
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 explitely 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