TAP Notes

[Mark Taylor]

On Fri, 6 Dec 2013, Markus Demleitner wrote:

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

But from the current text of DALI, I don't think DALI does want that.
Sec 4.2 of DALI PR 20131108 says:

   "An error document describing errors in use of the DAL service
    protocol *may* be a VOTable document as described in [11] or
    a plain text document."

It permits wrapping errors in a VOTable, but doesn't even give
it a SHOULD, so I don't see that UWS ought to.

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

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

OK I've probably misunderstood the intention of the quote - it's
to answer the question "when would this job be expected to finish
if I submitted it now", and I was interpreting it to answer
the question "what's the intrinsic expected duration of this job".
Giving it as an (ISO-8601) absolute epoch would make such 
misunderstandings less likely.

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