adql: prefixes in TAP_SCHEMA.columns

[Markus Demleitner]

Hi,

On Mon, Jun 30, 2014 at 03:39:54PM +0200, Marco Molinaro wrote:
> 2014-06-24 21:16 GMT+02:00 Patrick Dowler <patrick.dowler at nrc-cnrc.gc.ca>:
> 
> > The scenario I used a different prefix was when I had a column with an
> > array (long[] or double[]). Without the prefix, this is still correctly
> > described in the tap_schema with the size column, eg:

Oh, arrays and ADQL -- another joyful topic as, of course, ADQL
doesn't let you do anything at all with these arrays...

> >
> > As long as clients are careful to look at the size in the tap_schema for
> > datatype other than char or varchar, there is no ambiguity. Given the
> > suggestion to allow non-standard types I think it is safe to say that
> > non-standard size as we are using is also acceptable.
> >
> > Given that, the prefix does not provide anything useful and I agree that
> > we should probably drop them.
> >
> 
> Is this then a consensus on
> a - dropping adql prefixes for SQL/DB-like datatypes
> b - asking clients (and providers) to check for data size on all types

Ha... so, there's still the things we have xtypes for, which are
prefixed with adql: and, as xtypes will remain so.
This, as far as I can see, concerns:

* TIMESTAMP 
* BLOB
* CLOB 
* REGION
* POINT 

My vote: no prefixes on any of them.  And a strong vote against
prefixing TIMESTAMP.

There is yet another problem.  I've been putting things like

VARCHAR(*)

into my columns forever.  Given there's the size I suddenly realised
that that's probably wrong.  So, what's the official TAP_SCHEMA
mapping for VARCHAR(*)?  Frankly, I'd be all for datatype=VARCHAR(*),
size=NULL, but what what's size for, then? (nb size is an integer in
TAP_SCHEMA)

> > Obviously, clients already see both of these uses in the wild.. Should TAP
> > services work to stop using the prefix now or with TAP-1.1?
> >
> 
> I'd prefer this changes go into TAP 1.1, since they shouldn't disrupt
> existing services and let back-compatibility work. Otherwise letting this
> be in TAP 1.0 (i.e. some errata?) can generate more confusion. But that's
> my opinion.

I think we must declare this undefined by TAP 1.0.  It doesn't hurt,
as far as I can see, as no client so far appears to use the
information (of anything else than displaying it to humans).

In whatever proposed standard text we come up with, we should advise
clients to only rely on concrete strings (as in: do something else
than display to humans) for TAP > 1.0.

Cheers,

         Markus