<div dir="ltr">Hello,<br><br>Happy to go with the majority on all these, and thanks again, Markus, for raising these points and going through them in detail.<br><br>I think this all sounds reasonable, though I am still wondering if "/scs2" is the right fixed name to land on. Essentially we are including the major version in the path, which I feel goes against the argument that only one version should be around at any time. If we later introduce a SCS version 3 does the path become "/scs3"? So I'm wondering if a plain "/scs" would work? Clients can still guess the protocol from the access URL but we are then not tying the protocol version to the URL.<br><br>It's not a big deal either way; I just wanted to raise it before the WD goes out just in case.<br><br>Thanks,<br>Stelios Voutsinas</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Oct 7, 2026 at 5:16 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">On Tue, Oct 06, 2026 at 12:50:22PM +0100, Mark Taylor wrote:<br>
> be used directly.  I'm not really against fixing the "scs2" name,<br>
> but I don't see a major benefit; however I may be missing relevant<br>
> usage scenarios.<br>
<br>
We've talked about that at yesterday's running meeting; my claim was<br>
that it's wise for a standard to define what can reasonably be<br>
defined, and little details like this sometimes help (example: let<br>
clients guess with some confidence what protocol to speak when all<br>
they have is just an access URL; a fixed name would also be great if<br>
we ever do something like DALIInterface).<br>
<br>
On the other hand, the benefit is certainly not large enough to<br>
warrant major implementation pain.<br>
<br>
So, we ended up with the compromise that we'll leave the fixed name<br>
in for the next WD and if implementors actually have a hard time<br>
because of it, we'll drop it.<br>
<br>
And then:<br>
<br>
> I don't agree.  If a client wants an ID that's of string type,<br>
> it can take whatever's there and convert it to a string.<br>
> In Java that's probably just toString(), but I imagine it's<br>
> pretty straightforward in any language?<br>
<br>
It was also brought forward that string casting is painful when you<br>
later do a TAP upload and want to match the ids with the ids that are<br>
in the database table.<br>
<br>
I guess that outweighs the small load on clients that want to do<br>
interesting things with these ids that perhaps need to transform them<br>
locally.<br>
<br>
I'll drop the char requirement in SCS2, then; I think quite a few<br>
ConeSearch-1 (that has that requirement, too) services have been in<br>
violation already, and I've admittedly never seen anyone complain.<br>
<br>
Thanks,<br>
<br>
        Markus<br>
<br>
</blockquote></div>