Simple Cone Search 1.1 - (new) internal WD

[Marco Molinaro]

Hi Walter, all,

2017-10-09 23:29 GMT+02:00 Walter Landry <wlandry at caltech.edu>:

> Marco Molinaro <molinaro at oats.inaf.it> wrote:
> > Dear all,
> > at the oncoming Interop in Santiago I will give a quick status report
> > on the Simple Cone Search revision task.
> >
> > I just fixed a couple of sentences and typos in the internal WD built
> > in July and I attach it here for you.
> >
> > Discussion points are still the same.
> > I would say that
> > 1 - ReST vs. query_param access_url
> > 2 - RESOURCE type="results" and multiple RESOURCEs
> > 3 - minor vs. major revision
>
> Minor vs Major looks like you have already decided this.  The working
> draft that you sent no longer mandates VOTable 1.0 or 1.1.  That
> change alone will break existing clients.  So if we are actually
> serious about semantic versioning, this should be SCS 2.0, not 1.1.
>

Really, to me, this is a point for discussion.
When I started (with Markus) trying to push forward SCS, the idea
was (and maybe is) to have a minor version, to try not to force
data providers to take a too long step in updating this piece of
architecture.

However, as you point out, reasons for a major release are
visible, no way to deny it.

But it's not decided, at least for me.

The statement at the end of my Shanghai's talk was:

==
1.0 clients should work with 1.1 services
1.0 services must be consumable by 1.1 clients
==

That's what minor means in this case.

And this is why the internal draft is open to DAL and Apps.
Because, as you say, we need to be sure we make changes
that make it possible.
Otherwise we have to plan a major release (or plan it alongside
the minor one), but I think that that will require even more effort,
on both server and client side.

> are the main ones, while
> > 4 - trying or not to use UCD1+
>
> Pretty please?  We allow access to our tables via a number of
> protocols (SIA2, SSA, SCS, TAP).  I really, really, really do not want
> to maintain different UCD's for each protocol.
>

I also (will) have a solution where these annotations are all into
the same place, and having protocols with different requirements
is not efficient.

So, point taken, (+1 for me if you want) but we need the other
stakeholders to speak up.

Cheers,
    Marco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20171010/d3a1986b/attachment.html>