Let's get something to test...

[Doug Tody]

On Thu, 12 Feb 2009, Anita M. S. Richards wrote:

> So, my first plea is to take up Aurelian's suggesting and factorise
> TAP so that we can see what everyone has to provide which is common to
> ADQL and PARAM, and then separately specify what is required (in the
> broad sense - from 'must' to 'may') for ADQL and for PARAM, so that
> people with existing installations can see what might need to be
> changed easily, as well as for new implimentations.  At the moment,
> the document 0.31 seems a bit mixed up and it was not clear to me what
> I would need to impliment for ADQL only, for example.  There was also
> discussion of how to cope with overflows and similar in more than one
> place. This is one of the biggest weaknesses in many present services
> so we should make sure that is clear.

This was one of my main concerns with 0.31 as well.  While there were
many improvements to the presentation in this most recent version,
we lost the clear presentation of AdqlQuery and ParamQuery as separate
service operations, each with a well defined set of input parameters.
Similarly, functionality which involves the interaction of several
related parameters, such as multi-position queries and table
metadata queries, is hard to understand given only a discussion of
the individual parameters.

In our discussions last fall following the release of 0.31 we
planned to reorganize this material to more clearly specify what
is in ADQL query, what is in param query, and what is common (see
http://www.ivoa.net/forum/dal/att-0955/TAP-outline-Nov27.xls).
Basically, AQ and PQ each have a separate section, with others for
common parameters and special functionality such as multi-position
queries and table metadata queries.  If all one were going to do
is implement ADQL then the param query sections could be ignored.
Regardless of how much of AQ/PQ are defined within TAP or externally,
such minor restructuring of the document would probably do a lot to
address this problem.

> Secondly, we need to get something out there to start testing asap,
> since that is what shows up inconsistencies fastest.  Hence I am all
> for whatever preliminary version can be provided, as long as future
> versions are backward-compatible as much as possible.

This is our view here as well.  Lets have one more iteration and get
out a 0.4 working draft, and have another round of prototypes on all
our parts.

> - I assume that the requirement for case sensitivity refers to the
>   need to pass on whatever the user inputs, not to impose extra
>   demands on user syntax.

I'm not sure what specific context you are referring to, but in the
case of ADQL/SQL and the QUERY param, many DBMS are case-sensitive.
Hence if we query the DBMS for a list of tables or table fields, we
may need to pass those same table/field names back to the DBMS in a
subsequent query.  Hence, the QUERY string wants to be case sensitive
(in general case sensitivity may however need to be specified on a
per-parameter basis depending upon how the parameter is used).

> - Why is it an error to specify e.g. the coordsys explicitly but
>   positions as column references (Section 2.4.2)?

It would be better if someone else addressed this one (probably Pat
as he wrote that part).

> - It would save less skilled data providers a bit trouble if you gave
>   examples of the commonest MIME types likely to be used, in 2.4.5

Good point.  Clients will probably prefer the shorthand forms, but
data providers will need to accept the MIME types so the standard
ones should be specified.  A table could be added to fully specify
this information.

 	- Doug