<div dir="ltr">Dear all,<div>I try to summarise here what we have from the previous</div><div>2 threads.</div><div><br></div><div>I sort-of updated the </div><div><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></div><div>page accordingly.</div><div><br></div><div>1 - Minor vs. Major revision -</div><div>The idea was to start a minor revision to see if we can</div><div>solve most DAL landscape inconsistencies without</div><div>trying a major release, this is mostly related, I think,</div><div>to the actual take up we can have for a minor WRT a</div><div>major version.</div><div><br></div><div>2 - RESOURCEs(@type) and TABLES -</div><div>Most services don&#39;t have a type=&quot;results&quot; attribute</div><div>and value. Adding it would allow multiple RESOURCES</div><div>and allow for tables to use Datalink.</div><div>Anyway, here the main thing is that 1.03 said</div><div>1 Resource with 1 table. That&#39;s the main think to change.</div><div>As for having multiple tables in the @type=results TABLE,</div><div>that was just an idea.</div><div><br></div><div>3 - ReST versus query-param base URL -</div><div>I think we should put ReST in SCS-1.1, allowing but</div><div>deprecating GET params in the base URL.</div><div>This would be just for a transition phase, since</div><div>changing most services would require time.</div><div>Also ReST would solve the POST and VOSI</div><div>issue.</div><div>Nonetheless I think this is the most critical</div><div>point, because the mixup in behaviour can</div><div>really vary a lot, we should try to constrain</div><div>the various possibilities.</div><div><br></div><div>4 - &quot;single&quot; INFO in Error - </div><div>We still have to decide if we want an erratum to this</div><div>for SCS-1.03. The problem will be solved anyway in</div><div>1.1 since errors should follow DALI and old-style ones</div><div>will be deprecated.</div><div><br></div><div>5 - UCD 1.0 or 1+</div><div>Unless clients can do some magic understanding both</div><div>ID_MAIN and <a href="http://meta.id">meta.id</a>;meta.main (and the same per ra and dec)</div><div>we cannot probably change this behaviour in the</div><div>minor revision.</div><div><br></div><div>All of that said, before end of summer I&#39;ll issue a new internal draft.</div><div>I suppose I&#39;ll circulate it also to apps.</div><div>Thanks to those who already contributed to the current one, that I&#39;ll</div><div>try to change accordingly to discussion (present and future).</div><div>But, as I said, this is more likely to happen in the second half of August.</div><div><br></div><div>Goal is to have a good basis for a report and discussion in Santiago.</div><div>Thank you all for the inputs and discussion, sorry if I didn&#39;t reply</div><div>to single emails.</div><div><br></div><div>ciao</div><div>    Marco</div></div>