<div dir="ltr">Thanks Markus for raising this as well as the pointer to the Gavo record, that does resolve my question on #3.<br>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? <div>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.<br><br>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.<br>Perhaps to make it even more explicit:<br><br>"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."<br><br>Thanks,<br><br>Stelios</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jul 27, 2026 at 5:39 AM Markus Demleitner via dal <<a href="mailto:dal@ivoa.net">dal@ivoa.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear DAL folks,<br>
<br>
In my loose series of community polling on Stelios' comments on<br>
SCS2[1], I'd say the last question (Jul 9th) on POST support is<br>
settled in DALI 1.2.  So, let's move on to:<br>
<br>
  7. Migration plan<br>
<br>
  I think it's less than ideal and an unnecessary hurdle to have to<br>
  require all SCS2 services (including new service creators) to be<br>
  accompanied by ConeSearch-1.0 interfaces.<br>
  Also, I don't know if it is clear how registry records should be<br>
  structured for a service that implements both 1.1 and 2.0<br>
  simultaneously (One record or two? Should VOSI capabilities list<br>
  both capability types?)<br>
  I'd be in favor of exempting new SCS2 ConeSearch implementors of<br>
  having to write implementations for both.<br>
<br>
On the requirement of parallel implementations... well, this is a<br>
consequence of the original desideratum "No VO splits" from the<br>
College Park talk<br>
<<a href="https://wiki.ivoa.net/internal/IVOA/InterOpJune2025MVT/lecture-notes.pdf" rel="noreferrer" target="_blank">https://wiki.ivoa.net/internal/IVOA/InterOpJune2025MVT/lecture-notes.pdf</a>>.<br>
<br>
Something's got to give, sure, and perhaps it's acceptable if legacy<br>
clients don't see the most recent services.  I *would* like to say<br>
that until we offcially pull ConeSearch-1, the differences should be<br>
as small as possible.  I'd say the minimal language should be "If you<br>
already run a ConeSearch-1 service, don't pull it until the<br>
transition team tells you to."  I am very grateful for suggestions<br>
what to write.<br>
<br>
The Registry records... well, at least for legacy services they stay<br>
as they are, including their granularity, except there will be an<br>
extra capability with the SCS2 standardID.  That means that sure, as<br>
long as it's there, the VOSI capabilities will have both ConeSearch-1<br>
and SCS2 capabilities.  The PoC record:<br>
<br>
<a href="http://dc.g-vo.org/oai.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://org.gavo.dc/gaia/q3/cone" rel="noreferrer" target="_blank">http://dc.g-vo.org/oai.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://org.gavo.dc/gaia/q3/cone</a><br>
<br>
shows how it's supposed to look like (or at least I hope so:-).<br>
<br>
Thanks,<br>
<br>
           Markus<br>
<br>
<br>
[1] <a href="https://github.com/msdemlei/scs2-original-deleteme/issues/2" rel="noreferrer" target="_blank">https://github.com/msdemlei/scs2-original-deleteme/issues/2</a><br>
<br>
</blockquote></div>