<div dir="ltr">Dear DAL,<br>I&#39;ve started to modify the SCS-1.03 to prepare<br>an internal WD for revision 1.1 following what<br>has been discussed in Shanghai at DAL session 1<br>(see &quot;Refreshing SCS specification&quot; at<br><a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpMay2017-DAL">http://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpMay2017-DAL</a>)<br><br>In order to encourage discussion, I prepared a<br><a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/SCS-1_03-Next">http://wiki.ivoa.net/twiki/bin/view/IVOA/SCS-1_03-Next</a><br>wiki page to reflect the topics to discuss, so that<br>discussion can take place while I prepare the first draft.<br><br>Anyway, directly from the first steps in modifying the doc,<br>I have already a few points to highlight here for discussion,<br>for all the involved parties.<br><br>1 - single INFO element in service validation<br>==================================<br>This was raised in the plenary OPS session 2 in Shanghai.<br>(see EURO-VO registry report at<br><a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpMay2017-Ops">http://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpMay2017-Ops</a>)<br>and refers to the sentence in SCS that currently states:<br><br>&gt;&gt;In the case of error, the service MUST respond with a <br>VOTable that contains a single PARAM element or a <br>single INFO element with name=&quot;Error&quot;...&lt;&lt;<br><br>where there&#39;s ambiguity in the interpretation of single,<br>meaning -single one having the name=&quot;Error&quot;- or<br>-single INFO element- at all.<br><br>This makes most cone searches fail validation.<br>Suggestion has been made to issue an Erratum for this.<br>Even if it&#39;s not explicitly a SCS-1.1 topic, it will help in<br>the revision process.<br><br>2 - allowing POSTing to cone search services<br>===================================<br>GET or POST for synchronous resources is the same<br>for DALI, and letting POST by available to SCS seems<br>a direct thing.<br><br>However, SCS-1.03 has base URL defined as<br>http://&lt;server-address&gt;/&lt;path&gt;?[&lt;extra-GET-arg&gt;&amp;[...]]<div><br></div><div>thus, in case of POST, where do we set the &lt;extra-GET-args&gt;?</div><div><br></div><div>a - leave them as GET args and have a mixed GET/POST</div><div>b - ask, supporting POST, also the extra go to POST data<br></div><div>c - promote path-params directly in 1.1, removing the </div><div>possibility to have extra-GET-args in SCS base URL</div><div><br></div><div>a) seems straightforward, even if not so neat</div><div>b) requires extra work for clients to adapt (apart from server)</div><div>c) breaks a bit current spec, even if we leave current</div><div>base URL as allowed and only discourage it</div><div><br></div><div>3 - the capabilities endpoint</div><div>=====================</div><div>Trying to bring SCS in a more DALI shape, there are two</div><div>VOSI resources that are required: capabilities and availability.</div><div>I leave out the second one at present, and focus only on the</div><div>capabilities.</div><div>Again, without the &lt;extra-GET-args&gt; adding a should to the</div><div>specification would be easy, but how to deal without removing</div><div>the extra args (or, better, without moving them from being </div><div>attached to the base URL)?</div><div><br></div><div>Technically, attaching the &lt;extra-GET-args&gt; to /capabilities after</div><div>the server/path/ base can be done, but I don&#39;t know if it&#39;s a good</div><div>idea, even if considering a cone search (multi-)service serving </div><div>various catalogues that use the extra-GET-args to distinguish </div><div>among them.</div><div><br></div><div>Every thought, comment, suggestion is welcome on all the three</div><div>above, the wiki page topics or other things you feel are needed</div><div>for a new version of the SCS.</div><div><br></div><div>I&#39;ll get anyway back to you when the first SCS-1.1 internal draft is </div><div>ready.</div><div><br></div><div>Cheers,</div><div>    Marco</div></div>