TAP 1.1, MAXREC and TOP

[Mark Taylor]

On Wed, 2 Sep 2015, Kristin Riebe wrote:

> Dear DAL
> 
> > And, given that, I'd wish clients would not pass in MAXREC by
> > default.  Mark... Do you think you could have the Max Row combo in
> > TOPCAT default to empty?
> 
> Are you sure this would be wise?

I *think* it's not only wise, but what topcat actually does.

The Max Rows selector visible in the GUI displays the soft limit
obtained from the TAPRegExt document at the service's /capabilities
endpoint, like this:

   Max Rows: 2000 (default)

(see http://www.starlink.ac.uk/topcat/sun253/TapTableLoadDialog_query.html
for a screenshot).

In this state (flagged to the user by the "(default)" marker)
the client does not supply the MAXREC parameter to the service
when it makes TAP queries.

However, if the user interacts with the Max Rows selector GUI
to set the value to something other than the default (i.e. different
from the declared MAXREC soft limit), then subsequent TAP queries
are sent to the service with a MAXREC parameter.

In other words the combo box doesn't default to empty, so users can
see what they can expect in terms of result truncation,
but the TAP client behaves as if it did.

Markus, if you think you're seeing different behaviour than that,
get in touch off-list and I'll check it again.

> I thought MAXREC was set by default so that people do not accidentally
> download complete large tables, especially since they may need to first
> try around a bit to get the query right, but may forget to set TOP to
> limit their results during this try-out phase.

That is the way it works, and it's a good idea for the reasons that
you mention, but the MAXREC soft (i.e. default) limit is enforced
by the service rather than (necessarily) the client.
The client software only gets to override the soft limit if it
passes MAXREC explicitly, so if it leaves that parameter out
then the server-declared soft limit applies.

In general: I think I agree with what appears to be the consensus
on this thread, which is that MAXREC trumps TOP, and only MAXREC
results in the QUERY_STATUS OVERFLOW flag.  This is what I expect
from the existing standard text.  I know that DaCHS does it
differently, and admittedly I have generally been pleasantly surprised
by that non-standard behaviour when I've noticed it, since it
does what I want; however I think it would complicate the
standard too much to legislate for that behaviour.
The fact that taplint does not report this behaviour as erroneous
may be the result of my culpably pro-DaCHS bias.

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/