SCS2 Working Draft

[Markus Demleitner]

Dear DAL WG,

About a year ago, in College Park, it was decided to use the
transition from the dated Simple Cone Search version 1 to a
DALI-compliant successor (which I now call SCS2) as a test case for
transitions between major protocol versions.

I've let it slip a bit, but now there is a Working Draft for SCS2 on
the Doc Repo, <https://ivoa.net/documents/ConeSearch/20260529/>.

Everyone is cordially invited to have a look, in particular if you
run ConeSearch-1 services or maintain ConeSearch-1 clients.
DaCHS-HEAD has an implementation of this that I think is fairly
complete, even sporting the optional POS and UPLOAD parameters.  If you
want to try that, there's an SCS2 service on my lite version of Gaia
DR3 at

http://dc.g-vo.org/gaia/q3/cone2/scs2.xml?

(which you could have discovered using the RegTAP query

select access_url from rr.resource
natural join rr.capability
natural join rr.interface
where standard_id like 'ivo://ivoa.net/std/scs2#query-2%')

Stelios has collected a wealth of valuable feedback at

https://github.com/msdemlei/scs2-original-deleteme/issues/2,

which I intend to post here or transfer into bugs against
ivoa-std/SCS2 as we go.  For a few of these points I have cheap
answers.

> TABLE parameter semantics

The spec already says you have to give whatever is the table's name
in the tableset, which again has to match the stats/options for the
TABLE input parameter (which can't be this explicit right now because
stats is still under discussion over at VODataService 1.3).

> Multi-collection capabilities
> What should we be returning in our the VOSI /capabilities endpoint
> for a multi-table service?
> One <capability> block per collection inside a single
> <vosi:capabilities> document?

"service" should be "resource" here, I guess, because if you only
have one SCS2 service (and dispatch on TABLE), there's trivially only
a single SCS2 capability.

If on the other hand, you have per-table SCS2 services (with custom
parameters), you'll have one such capability per table, and people
will know which service queries which table by inspecting the TABLE
param's stats/option.

> 6. #query-2.0 fragment in the standardID
>
> Out of curiosity why we add the query-2.0 fragment to the standard
> ID instead of just ivo://ivoa.net/std/SCS2?

We might one day have different things to reference within this
record.  The relevant standards language is
<https://ivoa.net/Documents/IVOAIdentifiers/20160523/REC-Identifiers-2.0.html#tth_sEc4.2>

I was never quite sure whether this was a wise thing to specify; but
people occasionally clamoured for being able to discover
version-sharp, and we had other cases for standard keys.  So, most
new standards now use the Identifiers2 scheme, and even if it may not
be optimal, it's still a good idea to be consistent.


All the other points, I think, deserve extra threads or at least
extra bugs, which I hope to do in the next few weeks or in
Strasbourg.

As a brief implementation feedback:

(a) DaCHS was surprisingly badly struck by "don't be
case-insensitive".  But I'm 100% confident that scuppering the bane
of case insensitivity is still a good thing.

(b) POS was simple to implement, but only because there already is
pgsphere (or q3c) behind DaCHS.  Still, given that I loathe optional
features I'd be totally open to drop it

(c) UPLOAD was surprisingly nightmarish.  You see, I had expected
this to work with my existing upload code and then doing something
like 1=EXISTS(SELECT 1 WHERE distance(uploaded-point,
catalogue-point)<sr), which would have fit nicely into who DaCHS
builds its queries.

It turns out that I just could not make the planner use any sort of
index for an EXISTS expression like that.  I sometimes thought I had
understood why; I no longer think so, but it's at least highly
non-trivial.  You can hence easily talk me out of UPLOAD, I think
(although I still think as a principle this UPLOAD rows are the way
to go if you want protocols to support multiple sets of constraints).

So... what does everyone think?  And more importantly: Who would be
in on pushing this ahead, in on forming a transition team?  Without
having a clear idea of who will contribute there, we shouldn't embark
on a major version transition.

Thanks,

          Markus