SCS2: Stelios' last two items

[Markus Demleitner]

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