Simple Cone Search - starting a revision

[Brian Major]

Hi Marco,

Thanks for the very clear summary.  I just have one short comment below to
keep the discussion going.

On Fri, Jul 14, 2017 at 12:53 AM, Marco Molinaro <molinaro at oats.inaf.it>
wrote:\

<snip>


> 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).
>

I wonder if the transition to a cleaner ReST interface that supports
the VOSI endpoints would be better achieved by moving directly
to a 2.0 version of SCS?  A, B, and C are an ambitious mix of
recommendations and I think it would be challenging to write a 1.1
client.  But, perhaps there is a reason for having a backwards
compatible 1.1 version that I'm not aware of.


>
> Please, all of the readers, speak up!
>
> Cheers,
>      Marco
>
>
Regards,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20170718/1e58430c/attachment.html>