<div dir="ltr"><div class="gmail_extra">Hi DAL,<br>at this point we may try to summarize a little to answer Markus' point<br><br>> I believe we should use the opportunity of TAP 1.1. to clarify the<br>> interaction of TAP's MAXREC and ADQL's TOP.<br><br>It seems to me the group wants to stay with what current standards already state:</div><div class="gmail_extra">TOP cannot override MAXREC. </div><div class="gmail_extra">Also the two of them live on different levels of negotiation and enquiry to the service.</div><div class="gmail_extra"><br></div><div class="gmail_extra">This can be read from:</div><div class="gmail_extra">- §2.3.7 for TAP-1.0</div><div class="gmail_extra">- DALI-1.0 §3.2.4 for TAP-1.1</div><div class="gmail_extra"><br></div><div class="gmail_extra">Then an help comes from TAPRegExt-1.0 §2.6 section "Limits on Data" </div><div class="gmail_extra">where the definitions for default and hard limits for tr:DataLimits is set </div><div class="gmail_extra">with respect to the unit="row" attribute.</div><div class="gmail_extra"><br></div><div class="gmail_extra">This more or less brings the scenario to what Gregory and Mark addressed </div><div class="gmail_extra">on the help a client application can give to the user (i.e. negotiating the</div><div class="gmail_extra">MAXREC wrt TOP while preparing the service query call).</div><div class="gmail_extra"><br></div><div class="gmail_extra">It's also what I more or less suggested using "soft" instead of "default"</div><div class="gmail_extra">(sorry if I misused terms for the elements I had in mind).</div><div class="gmail_extra"><br></div><div class="gmail_extra">May the question now be:</div><div class="gmail_extra">Should we add some more explicit wording to help both server </div><div class="gmail_extra">and client side implementations understand this?</div><div class="gmail_extra">(Markus already proposed a "clobber" addition)</div><div class="gmail_extra">If so, I think this is an "errata/feature" for DALI more than a TAP one, </div><div class="gmail_extra">but I'm not absolute on this.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra"> Marco</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">2015-09-02 17:05 GMT+02:00 Mark Taylor <span dir="ltr"><<a href="mailto:M.B.Taylor@bristol.ac.uk" target="_blank">M.B.Taylor@bristol.ac.uk</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Wed, 2 Sep 2015, Gregory Mantelet wrote:<br>
<br>
> Mark, would it be otherwise possible in TOPCAT (and eventually STILTS' TAP<br>
> client), to automatically update the MAXREC parameter to the TOP value if TOP<br>
> > soft_limit? And in case TOP > hard_limit, set MAXREC to hard_limit?<br>
><br>
> This would be a convenient solution in advanced TAP client such as TOPCAT,<br>
> because it would be more natural to the users who, most of the time, do not<br>
> know what is MAXREC for in the contrary of TOP.<br>
<br>
</span>Interesting idea, I hadn't thought of that.<br>
<br>
I currently don't do anything with the results of the ADQL parsing<br>
except for hightlighting syntax, but I don't see any reason that<br>
I shouldn't. From a quick look at the parser API, it looks like it's<br>
as simple as using the hasLimit/getLimit methods on the result<br>
of ADQLQuery.getSelect() - is that right?<br>
<br>
(incidentally - I see that getLimit returns int, maybe one day<br>
someone will wish that was a long?)<br>
<div class=""><div class="h5"><br>
Mark<br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk">m.b.taylor@bris.ac.uk</a> <a href="tel:%2B44-117-9288776" value="+441179288776">+44-117-9288776</a> <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~mbt/</a><br>
</div></div></blockquote></div><br></div></div>