<div dir="ltr">Hi Walter, all,<br><div class="gmail_extra"><br><div class="gmail_quote">2017-10-09 23:29 GMT+02:00 Walter Landry <span dir="ltr"><<a href="mailto:wlandry@caltech.edu" target="_blank">wlandry@caltech.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">Marco Molinaro <<a href="mailto:molinaro@oats.inaf.it">molinaro@oats.inaf.it</a>> wrote:<br>
> Dear all,<br>
> at the oncoming Interop in Santiago I will give a quick status report<br>
> on the Simple Cone Search revision task.<br>
><br>
> I just fixed a couple of sentences and typos in the internal WD built<br>
> in July and I attach it here for you.<br>
><br>
> Discussion points are still the same.<br>
> I would say that<br>
> 1 - ReST vs. query_param access_url<br>
> 2 - RESOURCE type="results" and multiple RESOURCEs<br>
> 3 - minor vs. major revision<br>
<br>
</span>Minor vs Major looks like you have already decided this. The working<br>
draft that you sent no longer mandates VOTable 1.0 or 1.1. That<br>
change alone will break existing clients. So if we are actually<br>
serious about semantic versioning, this should be SCS 2.0, not 1.1.<br></blockquote><div><br></div><div>Really, to me, this is a point for discussion.</div><div>When I started (with Markus) trying to push forward SCS, the idea</div><div>was (and maybe is) to have a minor version, to try not to force</div><div>data providers to take a too long step in updating this piece of</div><div>architecture.</div><div><br></div><div>However, as you point out, reasons for a major release are</div><div>visible, no way to deny it.</div><div><br></div><div>But it's not decided, at least for me.</div><div><br></div><div>The statement at the end of my Shanghai's talk was:<br></div><div><br></div><div>==</div><div>1.0 clients should work with 1.1 services</div><div>1.0 services must be consumable by 1.1 clients<br></div><div>==</div><div><br></div><div>That's what minor means in this case.</div><div> </div><div>And this is why the internal draft is open to DAL and Apps.</div><div>Because, as you say, we need to be sure we make changes</div><div>that make it possible.</div><div>Otherwise we have to plan a major release (or plan it alongside</div><div>the minor one), but I think that that will require even more effort,</div><div>on both server and client side.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> are the main ones, while<br>
> 4 - trying or not to use UCD1+<br>
<br>
</span>Pretty please? We allow access to our tables via a number of<br>
protocols (SIA2, SSA, SCS, TAP). I really, really, really do not want<br>
to maintain different UCD's for each protocol.<br></blockquote><div><br></div><div>I also (will) have a solution where these annotations are all into</div><div>the same place, and having protocols with different requirements</div><div>is not efficient.</div><div><br></div><div>So, point taken, (+1 for me if you want) but we need the other</div><div>stakeholders to speak up.</div><div><br></div><div>Cheers,</div><div> Marco</div></div></div></div>