TAP Implementation Notes

[Mark Taylor]

On Mon, 8 Oct 2012, Markus Demleitner wrote:

> Dear DAL folks,
> 
> I've been planning to write up what's on
> http://wiki.ivoa.net/twiki/bin/view/IVOA/TAPImplementationNotes -- a
> collection of various things regarding TAP that need clarification or
> improvement -- for a while now.  I've finally tackled it, and the
> (intermediate) result is at 
> https://volute.googlecode.com/svn/trunk/projects/dal/TAPNotes/TAPNotes-fmt.html
> 
> I hope  we'll find some time to discuss the various topics in Sao
> Paulo, but it would really be nice if you could glance through it
> before.  Whether in SP, before or after, I'm be grateful for any kind
> of feedback, but particularly:
> 
> (1) For each individual proposal: Do you think it's a good idea?
> (2) For each individual proposal: Would you implement that?
> (3) For each To Be Written-thingy: Would you author it?
> (3) Are there any other quirks you'd like to fix in the next round of
>     standardization?
> (4) Are there any other features you'd like to see in the next round
>     of standardization?

Markus,

this looks like a pretty useful piece of work.
I'll comment on some of the items.

ADQL: Simple Crossmatch Function:
   Yes yes yes

ADQL: Empty Coordinate Systems:
   Getting rid of these does look like a very good idea, I presume
   the functions were defined like that by somebody who never thought
   much about their implementation [say, wouldn't it be a great idea
   if implementations were required before standards reached REC?].

   I don't know about the details though - working towards an ADQL
   where the first arguments of these functions is ignored is quite
   ugly, and likely confusing or at least irritating to future TAP
   users.  Also, what does "deprecating" the first argument mean;
   syntactically you have to put something there, does it mean that
   services will be encouraged to ignore it, in contravention of
   the standard?

   An alternative would be to deprecate these functions altogether
   and introduce a parallel set of similarly-named ones which lack
   the first argument.  I don't have a particularly good suggestion
   for the name-mangling required, but you could have SAREA, SBOX,
   SCENTROID, ... (for Simple).  [Um, unless ADQL permits function
   overloading by parameter count/type, but I have the impression
   it doesn't.]

ADQL: Case-Insensitive String Comparisons:
   Assuming your analysis is correct (can't do case-insensitive
   comparisons at the moment), then yes, it's important to add this.

ADQL: Casting to Unit:
   This sounds like it might be a useful addition, given the fallbacks
   in the text as you've written it (i.e. query fails if conversion
   can't be done).

   My worry is that the implementation would be sufficiently diffcult
   that it would be not widely implemented (it bears at least a 
   superficial resemblance to the named coordinate system idea,
   though it's not as bad as that), so people would spend more time
   trying it and it not working than getting useful value out of it.
   Would it be more appropriate as a UDF, referenced in examples,
   where required?  (or is there some syntactic reason why that wouldn't
   work?)

   However, no doubt you have a better idea of implementation difficulty
   than I do, so I'm not vetoing it.

ADQL: Column References with UCD Patterns:
   Hmmm, I can see the thinking behind it, but is there really a
   compelling use case?  Also, if this is introduced, there probably
   ought to be a UTYPECOL function as well.

UWS: Format of Quote:
   Agreed the current state is anomalous, but it's not that problematic
   and changing it in a minor TAP version can be expected to cause
   compatibility problems for clients.  I'd be inclined to let
   sleeping dogs lie.

TAP: The size column in TAP_SCHEMA:
   Alternative possibility: remove SIZE from the list of ADQL reserved
   words.  I have no idea if that would cause problems.

TAP: Inline Table Uploads Sanitized:
   I'm not sure what problem ("somewhat fragile") this is trying to solve.
   The new proposed upload format doesn't look immediately objectionable,
   but I'd hesitate to agree with the change without trying to implement
   it first.

TAP: Examples endpoint
   This is a nice idea, and I think it's fairly well worked out.

   There should be some arrangement for declaring the query language
   (ADQL, PQL, ...); probably that ought to match the declared
   TAPRegExt language/name element content.

   Would I implement consumption of such an endpoint in a TAP client?
   Yes if I had time.

TAP: Plan endpoint
   Good idea.  Thanks for backing out of the formatting.

   The requirement of text/plain output seems a bit unnecessarily
   restrictive though.  I'd make it a SHOULD rather than a MUST.
   I note that the GAVO TAP server serves text/xml from its
   plan endpoints :-).

TAP: Scaleable tables endpoint
   Given that VizieR TAP is about to come online, it's should be
   regarded as high priority to do something about this
   (Xamin is another TAP service with a lot of tables).
   I think the proposal written here provides a good solution.


Of the other proposals in the document, I either agree with them or
don't understand them (not your fault, I'm no SQL expert).

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/