Notes from the IVOA DAL session on ADQL revision
(DAL session II-extended, 11 Oct. 2015, Banff, Canada)

NOTE:
Topics reflect the TAPNotes Note at the time of writing.
Note on 
http://volute.googlecode.com/svn/trunk/projects/dal/TAPNotes/TAPNotes-fmt.html

Some errata identified for current version. No objections to those: names of uploaded tables, multiple uploads, SIZE in TAP_SCHEMA.columns, type system (see ADQL discussion also).

VOSI /tables endpoint in TAP: proposed change to have a scalable solution.
Could be done revisioning VOSI to version 1.1 and settings a different endpoint, with the name not fixed and ReST behaviour on a /schema/table/ like solution.
Could also be done using current /tables endpoint appending a qualified table name.
The two endpoints can live together in a 1.0&1.1 compliant implementation.
Agreed that a scalable solution is needed directly at 1.1.
No agreement on the actual solution.

VOSI /tables scalability solution also benefits from the rejection of making TAP_SCHEMA an optional and/or custom name feature of TAP.
Added an errata to specify that "TAP services should not support JOINS with TAP_SCHEMA".
Fixing TAP_SCHEMA as mandatory opened the issue whether the VOSI /tables should be made optional. Rejected as both features are important, even if they duplicate information. There are use case for both.

TAP /async and /sync endpoints for queries to be both maintained, thus rejecting the issue for making /async an optional one.

Allow services that does not support ADQL (e.g. for NO SQL solutions). The proposed solution is to setup a specific standard-id for TAP "restricted" services, to identify these services wrt the fully compliant ones. This track will not be pursued until solid use cases are provided.

Add an /examples endpoint for user documentation an help in building queries. There's agreement, it should be in xhtml to let it both be human readable and machine digestible. Take particular care in examples mainteinance, they should work.

A /plan endpoint, or other solution, to be attached to the services to allow query performance and debug. It is agreed it is a useful feature, even if may be used only by power users. Not clear whether it should work only for the /async endpoint (could be a sibling to phase, e.g.) or has to be provided for both (in this case a solution has to be found on how to call it).

Tablestes updates and general timings for datasets: dynamic metadata can be provided optionally through custom extensions to the TAP_SCHEMA. Other solution are too complicated and do not solve all the use cases.

Results pagination: to be found a way in ADQL or TAP to specify it. Manual ways, using ordering tecniques, are feasible. An OFFSET keyword can be used in ADQL, but it is not clear that all DBMS-es support it.

VOTable usage rewording has not been touched, but it doesn't seem controversial.

Probably all of the above (excluding errata, of course, and the non-ADQL case) may fit the TAP-1.1;probably as optional features not to break back compatibility. Testing in 1.1 will provide information on how to procede to TAP-2.0. VOSI tableset endpoint may require a VOSI-1.1 spec. from GWS.

[Banff, 12 Oct. 2014, Marco Molinaro]