<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hi Markus,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mer 2 set 2020 alle ore 17:09 Markus Demleitner &lt;<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>&gt; ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Marco,<br>
<br>
On Wed, Sep 02, 2020 at 09:49:41AM +0200, Molinaro, Marco wrote:<br>
&gt; Still I have a small concern about MAXREC=0 reading DALI-1.1<br>
&gt; section 3.4.4, second half of it.<br>
&gt; It seems that<br>
&gt; - or we clearly state that MAXREC=0 in ConeSearch should avoid<br>
&gt; request execution (because there&#39;s a risk of failure there)<br>
&gt; - or we touch slightly DALI avoiding MAXREC=0 to fail<br>
&gt; <br>
&gt; I&#39;d say the first is simpler and safer, but, in both cases, since<br>
&gt; DALI simply says &quot;containing metadata&quot; without any further detail,<br>
&gt; there&#39;s the need to detail the metadata response solution.<br>
<br>
Well, I understand that in general it&#39;s a good idea to improve<br>
robustness by cutting down on dependencies, but in this case I&#39;d say<br>
the win is negligible: A client requesting MAXREC=0 probably does<br>
that because in the next step it wants to run an actual query.  If<br>
that later query fails, nothing is won if MAXREC=0 succeeded.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace">Agreed, I didn&#39;t think about this scenario.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The only scenario I could see where a more robust MAXREC=0 operation<br>
might improve things is for metadata harvesting.  But there I&#39;d say<br>
we shouldn&#39;t do that through SCS anywey -- we have the Registry,<br>
vs:ParamHTTP, and OAI-PMH for that kind of thing, and if there&#39;s<br>
anything missing from that combo that MAXREC=0 can do, we ought to<br>
fix the combo rather than harden MAXREC=0.<br>
<br>
So: +1 for just referencing DALI, plus regulations on how the input<br>
parameters should be represented.  For that second part, I&#39;m a bit<br>
undecided: We could copy what SIAP and SSAP do -- works, but feels a<br>
bit stuffy --, or we could borrow from Datalink and have the input<br>
parameters in a dedicated GROUP of a separate, non-result, RESOURCE<br>
(which is a bit less hacky, but of course different from S*AP).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace">I suppose the only way to go is try.</div><div class="gmail_default" style="font-family:monospace">Currently I&#39;d be more inclined towards borrowing from DataLink, </div><div class="gmail_default" style="font-family:monospace">also because IIRC SIAP there was v.1 and SSAP might need an update.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">However I haven&#39;t a clear view nor a strong opinion.</div><br></div><div><div class="gmail_default" style="font-family:monospace">Cheers</div><div class="gmail_default" style="font-family:monospace">    Marco</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Hm...<br>
<br>
          -- Markus<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><font face="monospace">Marco Molinaro</font></div><div><font face="monospace">INAF - Istituto Nazionale di AstroFisica</font></div><div><font face="monospace">Osservatorio Astronomico di Trieste</font></div><div><font face="monospace">email <a href="mailto:marco.molinaro@inaf.it" target="_blank">marco.molinaro@inaf.it</a></font></div><div><span style="font-family:monospace">tel. +39 040 3199 152</span><br></div></div></div></div></div></div></div>