TAP 1.1, MAXREC and TOP

[Marco Molinaro]

Hi DAL,
at this point we may try to summarize a little to answer Markus' point

> I believe we should use the opportunity of TAP 1.1. to clarify the
> interaction of TAP's MAXREC and ADQL's TOP.

It seems to me the group wants to stay with what current standards already
state:
TOP cannot override MAXREC.
Also the two of them live on different levels of negotiation and enquiry to
the service.

This can be read from:
- §2.3.7 for TAP-1.0
- DALI-1.0 §3.2.4 for TAP-1.1

Then an help comes from TAPRegExt-1.0 §2.6 section "Limits on Data"
where the definitions for default and hard limits for tr:DataLimits is set
with respect to the unit="row" attribute.

This more or less brings the scenario to what Gregory and Mark addressed
on the help a client application can give to the user (i.e. negotiating the
MAXREC wrt TOP while preparing the service query call).

It's also what I more or less suggested using "soft" instead of "default"
(sorry if I misused terms for the elements I had in mind).

May the question now be:
Should we add some more explicit wording to help both server
and client side implementations understand this?
(Markus already proposed a "clobber" addition)
If so, I think this is an "errata/feature" for DALI more than a TAP one,
but I'm not absolute on this.

Cheers,
     Marco

2015-09-02 17:05 GMT+02:00 Mark Taylor <M.B.Taylor at bristol.ac.uk>:

> On Wed, 2 Sep 2015, Gregory Mantelet wrote:
>
> >     Mark, would it be otherwise possible in TOPCAT (and eventually
> STILTS' TAP
> > client), to automatically update the MAXREC parameter to the TOP value
> if TOP
> > > soft_limit? And in case TOP > hard_limit, set MAXREC to hard_limit?
> >
> >     This would be a convenient solution in advanced TAP client such as
> TOPCAT,
> > because it would be more natural to the users who, most of the time, do
> not
> > know what is MAXREC for in the contrary of TOP.
>
> Interesting idea, I hadn't thought of that.
>
> I currently don't do anything with the results of the ADQL parsing
> except for hightlighting syntax, but I don't see any reason that
> I shouldn't.  From a quick look at the parser API, it looks like it's
> as simple as using the hasLimit/getLimit methods on the result
> of ADQLQuery.getSelect() - is that right?
>
> (incidentally - I see that getLimit returns int, maybe one day
> someone will wish that was a long?)
>
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20150903/7e268482/attachment.html>