adql: prefixes in TAP_SCHEMA.columns

[Marco Molinaro]

2014-06-24 21:16 GMT+02:00 Patrick Dowler <patrick.dowler at nrc-cnrc.gc.ca>:

>
>
> On 24/06/14 01:21 AM, Markus Demleitner wrote:
>
>> So -- does anyone want to champion the adql: prefixes at this point?
>> In particular, Pat, do you keep up your preference in favour of them?
>> If nobody steps in, I'd remove them from the RegTAP PR before
>> submitting it (tomorrow, probably), and I'd propose a clarification
>> to the TAP specification in the Implementation Notes some time later.
>>
>
> 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:
>
> datatype: DOUBLE
> size: 2
>
> 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
?
To me it seems so, and then


> 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.


> Also, if we intend to allow non-standard datatype names, does that imply
> that we can stick them in the xtype attribute? I use and want to describe
> things like URIs, URLs, and UUIDs...


Letting changes go into TAP 1.1 can give some time to discuss this
(together with all the other TAP-Notes points already waiting us...).
I have to say that custom types are ok to me, but I wonder how many of them
can come out from data providers and how clients can deal with them. If
prefixes are in any case to be allowed (apart from standard SQL types),
then probably custom types should have some prefix like if they were coming
from a special type system.
I've just typed last sentence and I already don't like the idea that much,
data types in TAP_SCHEMA are yet a bit of a confused topic to me.

Also, letting these changes go in TAP 1.1 seems not to prevent RegTAP to
use the non-prefixed datatypes in the spec.

Cheers,
    Marco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20140630/e2e2491e/attachment.html>