<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hi Markus, Theresa,</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">thank you for your input and volunteering (for the future </div><div class="gmail_default" style="font-family:monospace">registry part).</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I only have one small comment on the SSAP-like metadata </div><div class="gmail_default" style="font-family:monospace">response connected to the MAXREC=0 solution.</div><div class="gmail_default" style="font-family:monospace">I like it and will go that way in the document.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Still I have a small concern about MAXREC=0 reading DALI-1.1 </div><div class="gmail_default" style="font-family:monospace">section 3.4.4, second half of it.</div><div class="gmail_default" style="font-family:monospace">It seems that</div><div class="gmail_default" style="font-family:monospace">- or we clearly state that MAXREC=0 in ConeSearch should avoid </div><div class="gmail_default" style="font-family:monospace">request execution (because there's a risk of failure there)</div><div class="gmail_default" style="font-family:monospace">- or we touch slightly DALI avoiding MAXREC=0 to fail</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I'd say the first is simpler and safer, but, in both cases, since </div><div class="gmail_default" style="font-family:monospace">DALI simply says "containing metadata" without any further detail, </div><div class="gmail_default" style="font-family:monospace">there's the need to detail the metadata response solution.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Cheers</div><div class="gmail_default" style="font-family:monospace"> Marco</div><div class="gmail_default" style="font-family:monospace"><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mar 1 set 2020 alle ore 19:15 Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> 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 Theresa,<br>
<br>
On Tue, Sep 01, 2020 at 02:18:50PM +0000, Theresa Dower wrote:<br>
> From the Registry end: it seems it may be helpful to add<br>
> capability/interface information noting time information support,<br>
> especially in the test query. Note this change would be in<br>
> SimpleDALRegExt, and included back to the main CS document. Do we<br>
> think this section is solid enough to work on it now, or do we keep<br>
> it in mind for later in the WD process?<br>
<br>
I'm fairly convinced we should phase out SimpleDALRegExt as the<br>
standards covered there get reviewed -- discovery is an integral part<br>
of a standard and thus shouldn't be regulated somehwere else.<br>
That we did it differently for the old S-protocols was just because<br>
the Registry wasn't (really) ready when the SCS and SIAP came along<br>
(well... for SSAP and SLAP Registry would have been there, but the<br>
bad pattern had already been established).<br>
<br>
So... I'm rather fervently for retiring the SCS section in<br>
SimpleDALRegExt and having everything in SCS.<br>
<br>
[Apologies to DAL: Registry in-talk start]<br>
Now that I skim SimpleDALRegExt again I notice it doesn't say "only<br>
valid until overridden" clearly and early enough. While it's still<br>
in WD (pending a few more adoptions of SSAP productType), I think I'd<br>
just explicitly say:<br>
<br>
Regulations here are only valid until the specifications themselves<br>
define their modes of discovery.<br>
<br>
in the abstract and repeat it a few times at strategic places in the<br>
document.<br>
[Registry in-talk end]<br>
<br>
<br>
As to noting TIME support: Well, we already have param in<br>
vs:ParamHTTP (DaCHS, for instance, has declared its SCS parameters in<br>
this way forever). Sure, you need to query the Registry to figure<br>
out parameters in this way, but while doing discovery that's not a<br>
problem.<br>
<br>
When talking to a service a client has run into in another way, I'd<br>
say MAXREC=0 metadata discovery, SSAP-style, ought to do the trick.<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>