SCS2: Stelios' last two items

[Stelios Voutsinas]

Hello,

Happy to go with the majority on all these, and thanks again, Markus, for
raising these points and going through them in detail.

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.

It's not a big deal either way; I just wanted to raise it before the WD
goes out just in case.

Thanks,
Stelios Voutsinas

On Wed, Oct 7, 2026 at 5:16 AM Markus Demleitner via dal <dal at ivoa.net>
wrote:

> On Tue, Oct 06, 2026 at 12:50:22PM +0100, Mark Taylor wrote:
> > be used directly.  I'm not really against fixing the "scs2" name,
> > but I don't see a major benefit; however I may be missing relevant
> > usage scenarios.
>
> We've talked about that at yesterday's running meeting; my claim was
> that it's wise for a standard to define what can reasonably be
> defined, and little details like this sometimes help (example: let
> clients guess with some confidence what protocol to speak when all
> they have is just an access URL; a fixed name would also be great if
> we ever do something like DALIInterface).
>
> On the other hand, the benefit is certainly not large enough to
> warrant major implementation pain.
>
> So, we ended up with the compromise that we'll leave the fixed name
> in for the next WD and if implementors actually have a hard time
> because of it, we'll drop it.
>
> And then:
>
> > I don't agree.  If a client wants an ID that's of string type,
> > it can take whatever's there and convert it to a string.
> > In Java that's probably just toString(), but I imagine it's
> > pretty straightforward in any language?
>
> It was also brought forward that string casting is painful when you
> later do a TAP upload and want to match the ids with the ids that are
> in the database table.
>
> I guess that outweighs the small load on clients that want to do
> interesting things with these ids that perhaps need to transform them
> locally.
>
> I'll drop the char requirement in SCS2, then; I think quite a few
> ConeSearch-1 (that has that requirement, too) services have been in
> violation already, and I've admittedly never seen anyone complain.
>
> Thanks,
>
>         Markus
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20261007/4a1333ab/attachment.htm>