Summary: data type for column metadata

[Markus Demleitner]

Dear TAP group,

I feel compelled to chime in on some points in yesterday's discussion:

rplante at poplar.ncsa.uiuc.edu:
> I like this list.  I think we also need to include a recommendation (at
> least) for how these should be mapped to VOTable types.  This is not only
> for consistency in TAP responses, but also for describing a table in the
> registry outside the context of TAP (e.g. describing the table
I agree a recommended mapping of ADQL to VOTable types is desirable,
but I wouldn't mention consistency in TAP responses as a rationale.
TAP clients will have to inspect the returned VOTable and be prepared
for basically anything, and coding any kind of expectation as to what
VOTable type will be returned for a given column or expression should
be discouraged.  For purposes of registry record generation, though,
a recommended mapping is a great help to implementors.

rplante at poplar.ncsa.uiuc.edu:
>    REGION         char arraysize="*", STC/s format
It's STC-S :-)

rplante at poplar.ncsa.uiuc.edu:
> I sense some consensus on these two questions so far.  I would like to
> immediately turn this around into a VODataService proposal.  May I enlist
> the respondants to Pat's summary for consultation on this proposal?  (So
With the caveat that I'm not sure either what I'm signing up for,
sure.

m.b.taylor at bristol.ac.uk:
>  - VARBINARY should use the VOTable unsignedByte type rather than char;
>    apart from signed/unsigned issues, a character zero in a VOTable
>    'string' (char array) acts as a terminator.  Is that likely to
>    be a problem for VARCHAR; i.e. can a VARCHAR contain an embedded
>    character 0?
It should definitely be unsignedByte. As to the issue of magic
characters in VARCHAR I'd say let's assume they are not allowed.
SQL92 talks about "implementation-defined null character"s, so we'd
be opening a can of worms -- which we don't need to do here.

m.b.taylor at bristol.ac.uk:
>> [Patrick Dowler:]
>>  Side note: Mark Taylor proposed a format attribute for FIELD where one could
>> specify the encoding (ISO8601, hex, STC-S, etc). That would be a nice
>> addition...
> I still think so, but my attempts to argue for it haven't met with
> much success to date.  If DAL or DAL/TAP agreed this was a Good Thing
> and made a request to the VOTable WG it might move it forward.  Might.
Count me in.  I guess the details are somewhat hairy to get right,
but I believe glancing at how MIME handles these things will help.

arots at head.cfa.harvard.edu, on leaving out STC of the TAP schema:
> Mark are suggesting, is not helpful, either. It would mean that any
> large-scale automated searching or cross-matching is ruled out from
> the start.
It's not.  If it's large-scale, people would be querying the registry
anyway, and the registry already contains full STC data (coverage),
so for them it's not necessarily a big deal to have full STC in
another place.  Even if the registry people say STC for columns is
outside of their scope, as Ray seems to suggest, having to query for
an empty VOTable in addition to a TAP schema query is not
unreasonable, I think, if people actually set out to do automated
science.

gerard.lemson at mpe.mpg.de:
> specification: POINT('ICRS GEOCENTER',25.4, -20.0) etc.
> And together with the ADQL DISTANCE and CONTAINS syntax would this not allow
> spatial queries that in theory fulfill all your requirements?
If the ADQL libraries actually implement some kind of automatic
"conforming" of coordinates, yes, to some extent.  The issue is
complicated, though, and given that (among other troubles) AFAIK
still nobody really knows what kinds of strings are supposed to be in
those first arguments to geometry functions, I'd hesitate to
advertise this mechanism as a preferred solution.

I may feel differently about proper STC-S in REGION, though.  That
could work nicely.

Cheers,

           Markus