Simple Cone Search - starting a revision

[Marco Molinaro]

Dear Theresa, Walter, Markus, all,

definitely the <extra-GET-args> is one of the beasts in this revision
attempt.

To put it in figures, not even 1% of current cone searches comes with
a base URL without embedded query parameters.

Apart some few special cases, most of the extra query params
resolve to identifying a table within a catalogue (or a set of).

Speaking in terms of ~authorities,

cds.vizier uses the -source for this (more than 90% of the SCSs out there),
archive.stsci.edu uses CAT or sci_data_set_name,
~xcatdb uses collection,
ipac uses table

But a non negligible part (if we normalise with vizier out) uses 2 arguments
~*.uk use DSACAT + DSATAB
~*.ru use cat + tab

and vizier is using a second fixed term to serve all columns (overriding
the optional VERB).

So, while I'd vote, like Markus, for moving towards a, probably more ReST,
solution were the catalogues and tables are set as resources, i.e. path
parameters, I'm aware that this can take some time to happen.

This is also the reason why I started so early this discussion.

Thus, I wonder if, given some appropriate text to explain the decision,
we can decide that SCS-1.1 will

A) recommend the usage of plain (no query args) base URL,
B) allow for extra query parts but deprecate it
C) put a should on capabilities and availability (with strong
encouragement to implement them if adopting A)

This should also solve POSTing that will be a should with
strong encouragement to allow it if base URL is plain
path-param (A case).

All of the above goes in the direction of DALI compliance but
should allow a long-as-needed smooth transition, with all the
drawbacks on the shoulders of resource validation and, probably,
applications (I'll add ops and apps in the loop when I finish a
first intelligible internal draft).

Please, all of the readers, speak up!

Cheers,
     Marco

2017-07-13 18:47 GMT+02:00 Theresa Dower <dower at stsci.edu>:

> 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.
>
> --Theresa
> ________________________________________
> From: dal-bounces at ivoa.net [dal-bounces at ivoa.net] on behalf of Walter
> Landry [wlandry at caltech.edu]
> Sent: Thursday, July 13, 2017 12:34 PM
> To: dal at ivoa.net
> Subject: Re: Simple Cone Search - starting a revision
>
> Theresa Dower <dower at stsci.edu> wrote:
> > Hello DAL!
> >
> > Just a quick note to point 2 regarding changing:
> >
> >  http://data.center/conesearches?CAT=mycat& to  http://data.center/
> conesearches/mycat?
> >
> > Yes, this would be a significant change for two separate MAST
> > ConeSearch architectures, currently registered as ~25 different
> > services handling as many catalogs. We are recently looking into
> > overhauling this anyway, but I am unsure of the timeline.
>
> That surprises me.  In Apache, this is a pretty simple rewrite rule.
> Something like
>
>   RewriteRule ^/conesearches/mycat "https://data.center/
> conesearches?CAT=mycat" [P,QSA]
>
> Cheers,
> Walter Landry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20170714/39cfa86b/attachment-0001.html>