SCS2 Migration Plan

[Stelios Voutsinas]

Thanks Markus for raising this as well as the pointer to the Gavo record,
that does resolve my question on #3.
One more question to iron out the details I have is whether it is valid for
a service to co-locate both dialects under the same accessURL?
If this is allowed, there might be some confusion due to the different
error conventions, but I don't know how common a use case that would be or
if the spec should take a position one way or another.

On #7 I think your minimal language works for me and fixes my objection,
that new implementors shouldn't have to stand up a legacy interface they
have no other reason to build.
Perhaps to make it even more explicit:

"Operators currently running a ConeSearch-1 service SHOULD NOT retire it
before the transition team declares the migration window closed. New
implementations of SCS2 MAY do so without also standing up a ConeSearch-1
interface."

Thanks,

Stelios

On Mon, Jul 27, 2026 at 5:39 AM Markus Demleitner via dal <dal at ivoa.net>
wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20260804/a173816c/attachment.htm>