<div dir="ltr">Hi Marco,<div><br></div><div>Thanks for the very clear summary.  I just have one short comment below to</div><div>keep the discussion going.</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 14, 2017 at 12:53 AM, Marco Molinaro <span dir="ltr">&lt;<a href="mailto:molinaro@oats.inaf.it" target="_blank">molinaro@oats.inaf.it</a>&gt;</span> wrote:\</div><div class="gmail_quote"><br></div><div class="gmail_quote">&lt;snip&gt;</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><br></div><div class="gmail_extra">So, while I&#39;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&#39;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&#39;ll add ops and apps in the loop when I finish a </div><div class="gmail_extra">first intelligible internal draft).</div></div></div></blockquote><div><br></div><div>I wonder if the transition to a cleaner ReST interface that supports</div><div>the VOSI endpoints would be better achieved by moving directly</div><div>to a 2.0 version of SCS?  A, B, and C are an ambitious mix of</div><div>recommendations and I think it would be challenging to write a 1.1</div><div>client.  But, perhaps there is a reason for having a backwards</div><div>compatible 1.1 version that I&#39;m not aware of.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><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><div class="h5"><div class="gmail_extra"><div class="gmail_quote"><br></div></div></div></div></div></div></blockquote><div><br></div><div>Regards,</div><div>Brian </div></div></div></div></div>