SCS2 Migration Plan

[Markus Demleitner]

Dear DAL folks,

In my loose series of community polling on Stelios' comments on
SCS2[1], I'd say the last question (Jul 9th) on POST support is
settled in DALI 1.2.  So, let's move on to:

  7. Migration plan

  I think it's less than ideal and an unnecessary hurdle to have to
  require all SCS2 services (including new service creators) to be
  accompanied by ConeSearch-1.0 interfaces.
  Also, I don't know if it is clear how registry records should be
  structured for a service that implements both 1.1 and 2.0
  simultaneously (One record or two? Should VOSI capabilities list
  both capability types?)
  I'd be in favor of exempting new SCS2 ConeSearch implementors of
  having to write implementations for both.

On the requirement of parallel implementations... well, this is a
consequence of the original desideratum "No VO splits" from the
College Park talk
<https://wiki.ivoa.net/internal/IVOA/InterOpJune2025MVT/lecture-notes.pdf>.

Something's got to give, sure, and perhaps it's acceptable if legacy
clients don't see the most recent services.  I *would* like to say
that until we offcially pull ConeSearch-1, the differences should be
as small as possible.  I'd say the minimal language should be "If you
already run a ConeSearch-1 service, don't pull it until the
transition team tells you to."  I am very grateful for suggestions
what to write.

The Registry records... well, at least for legacy services they stay
as they are, including their granularity, except there will be an
extra capability with the SCS2 standardID.  That means that sure, as
long as it's there, the VOSI capabilities will have both ConeSearch-1
and SCS2 capabilities.  The PoC record:

http://dc.g-vo.org/oai.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://org.gavo.dc/gaia/q3/cone

shows how it's supposed to look like (or at least I hope so:-).

Thanks,

           Markus


[1] https://github.com/msdemlei/scs2-original-deleteme/issues/2