<div dir="ltr">Dear Theresa, Walter, Markus, all,<div><br></div><div>definitely the <extra-GET-args> is one of the beasts in this revision attempt.</div><div><br></div><div>To put it in figures, not even 1% of current cone searches comes with</div><div>a base URL without embedded query parameters.</div><div><br></div><div>Apart some few special cases, most of the extra query params </div><div>resolve to identifying a table within a catalogue (or a set of).</div><div><br></div><div>Speaking in terms of ~authorities, </div><div><br></div><div>cds.vizier uses the -source for this (more than 90% of the SCSs out there), </div><div><a href="http://archive.stsci.edu">archive.stsci.edu</a> uses CAT or sci_data_set_name,</div><div>~xcatdb uses collection,</div><div>ipac uses table</div><div><br></div><div><div class="gmail_extra">But a non negligible part (if we normalise with vizier out) uses 2 arguments</div><div class="gmail_extra">~*.uk use DSACAT + DSATAB</div><div class="gmail_extra">~*.ru use cat + tab</div><div class="gmail_extra"><br></div><div class="gmail_extra">and vizier is using a second fixed term to serve all columns (overriding </div><div class="gmail_extra">the optional VERB).</div><div class="gmail_extra"><br></div><div class="gmail_extra">So, while I'd vote, like Markus, for moving towards a, probably more ReST,</div><div class="gmail_extra">solution were the catalogues and tables are set as resources, i.e. path</div><div class="gmail_extra">parameters, I'm aware that this can take some time to happen.</div><div class="gmail_extra"><br></div><div class="gmail_extra">This is also the reason why I started so early this discussion.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thus, I wonder if, given some appropriate text to explain the decision,</div><div class="gmail_extra">we can decide that SCS-1.1 will</div><div class="gmail_extra"><br></div><div class="gmail_extra">A) recommend the usage of plain (no query args) base URL,</div><div class="gmail_extra">B) allow for extra query parts but deprecate it</div><div class="gmail_extra">C) put a should on capabilities and availability (with strong</div><div class="gmail_extra">encouragement to implement them if adopting A)</div><div class="gmail_extra"><br></div><div class="gmail_extra">This should also solve POSTing that will be a should with</div><div class="gmail_extra">strong encouragement to allow it if base URL is plain </div><div class="gmail_extra">path-param (A case).</div><div class="gmail_extra"><br></div><div class="gmail_extra">All of the above goes in the direction of DALI compliance but</div><div class="gmail_extra">should allow a long-as-needed smooth transition, with all the</div><div class="gmail_extra">drawbacks on the shoulders of resource validation and, probably,</div><div class="gmail_extra">applications (I'll add ops and apps in the loop when I finish a </div><div class="gmail_extra">first intelligible internal draft).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Please, all of the readers, speak up!</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 class="gmail_quote">2017-07-13 18:47 GMT+02:00 Theresa Dower <span dir="ltr"><<a href="mailto:dower@stsci.edu" target="_blank">dower@stsci.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">IIS is a little weirder! (Our services are split between the two, and some have other URL rewriting under the hood.) Also we'll have to re-register everything. Nothing un-doable but Markus asked, and that's where we are right now.<br>
<br>
--Theresa<br>
______________________________<wbr>__________<br>
From: <a href="mailto:dal-bounces@ivoa.net">dal-bounces@ivoa.net</a> [<a href="mailto:dal-bounces@ivoa.net">dal-bounces@ivoa.net</a>] on behalf of Walter Landry [<a href="mailto:wlandry@caltech.edu">wlandry@caltech.edu</a>]<br>
Sent: Thursday, July 13, 2017 12:34 PM<br>
<span class="im HOEnZb">To: <a href="mailto:dal@ivoa.net">dal@ivoa.net</a><br>
Subject: Re: Simple Cone Search - starting a revision<br>
<br>
</span><div class="HOEnZb"><div class="h5">Theresa Dower <<a href="mailto:dower@stsci.edu">dower@stsci.edu</a>> wrote:<br>
> Hello DAL!<br>
><br>
> Just a quick note to point 2 regarding changing:<br>
><br>
> <a href="http://data.center/conesearches?CAT=mycat&" rel="noreferrer" target="_blank">http://data.center/<wbr>conesearches?CAT=mycat&</a> to <a href="http://data.center/conesearches/mycat" rel="noreferrer" target="_blank">http://data.center/<wbr>conesearches/mycat</a>?<br>
><br>
> Yes, this would be a significant change for two separate MAST<br>
> ConeSearch architectures, currently registered as ~25 different<br>
> services handling as many catalogs. We are recently looking into<br>
> overhauling this anyway, but I am unsure of the timeline.<br>
<br>
That surprises me. In Apache, this is a pretty simple rewrite rule.<br>
Something like<br>
<br>
RewriteRule ^/conesearches/mycat "<a href="https://data.center/conesearches?CAT=mycat" rel="noreferrer" target="_blank">https://data.center/<wbr>conesearches?CAT=mycat</a>" [P,QSA]<br>
<br>
Cheers,<br>
Walter Landry<br>
</div></div></blockquote></div><br></div></div></div>