TAP Notes

[Markus Demleitner]

Hi Mark,

On Fri, Dec 06, 2013 at 12:33:39PM +0000, Mark Taylor wrote:
> I have committed a small number of uncontroversial edits to TAPNotes.html
> (which I think is the source file?) for typos etc.

Thanks for that.

> I must admit I don't really understand the proposal of section 2.1.2,
[which is the table of "ADQL types" taken basically from TAP]
> or maybe I just don't get its motivation.  The text about ensuring
> that numeric operations should be possible on types that derive
> from columns which were numeric in the tables uploaded makes sense,
> but what does it mean to say that a VOTable short should become an
> ADQL SMALLINT, given that SMALLINT is not defined in ADQL?

The proposal is exactly to remedy this situation.  Not only when
implementing TAP the lack of an explicit type system in ADQL became
obvious.  To remedy it, TAP sort-of defined a type system through
this table.

However, the prefix of the TAP_SCHEMA type names as well as
specification economy strongly suggests this is stuff that should be
defined in ADQL proper.

I've declared this a clarification since for current ADQL
implementations -- which, I believe, all sit behind TAP enginges --,
this does not change anything.  However, for further work on ADQL
(e.g., the addition of booleans and a proposal I'm planning that
pulls apart adql:REGION to have CIRCLE, POLYGON, etc.) it is highly
beneficial if it is clear what actual types can exist behind the
column references.

> Sec 3.1.2:
> 
> "The payload of such an error message SHOULD be a VOTable formatted
>  as a std:DALI-compliant error message."
> 
> DALI says the error document MAY be a VOTable or it can be plain text.
> I'm not really a fan of using VOTables as error containers
> (what's it for?) so I'm -1 for recommending it here.  At least I
> wouldn't deprecate plain text error messages, maybe even recommend them.

I agree from a technical point of view (I've always wanted to use
HTTP status codes and text/plain plus maybe
empty-lines-are-paragraphs.  I put the VOTable wrapper part in
because that's what DALI wants; of course, UWS is GWS business, and
they might not feel bound to DALI's conventions...

I've added text reflecting my own doubts.

> Sec 3.2.1:
> 
> In principle a quote is for a job which could be started at any 
> point (not just now), so quoting an absolute end time doesn't 
> make sense.  From that point of view number of seconds is better
> than ISO8601.

Fair enough (except that, of course, a time estimate when a job
submitted at query time would finish does make sense, I would claim).
The rationale behind standardizing on ISO time stamps was to not have
to change the schema for such a minor thing.  I've added text saying
that if the schema needs modification anyway, standardizing on
seconds is preferable.

> Also using ISO8601 includes time zone complications, but it seems like
> it's already used for destruction time, in which case this isn't
> introducing any problem that's not already present.

I'm now referencing std:DALI, which gives a unique time format.

> Probably nobody ever provides useful quotes for TAP services anyway
> though, so I wouldn't advocate too much sweat here.

Well, if we change this, it'll change for all of UWS.  And don't
discard quote too early: I'm currently returning quotes in TAP based
on the length of the async queue.  I'd hope that by the time my
server might get overloaded, clients might be smart enough to figure
out there's a mirror (or other TAP server with the same  table) and
choose the one with the shortes queue, thus giving an el-cheapo
distributed load balancing.

> Appendix A:
> 
> Formatted HTML contains a "<" sign.  Fix is to replace
> 
>    and minEpoch<1900
> 
> with
> 
>    and minEpoch&lt;1900

Whoops; that's an ivoadoc bug.  I'll see that I fix it RSN.

Thanks,

          Markus