SCS2: Stelios' last two items

[Mark Taylor]

On Thu, 1 Oct 2026, Markus Demleitner via dal wrote:

> Stelios wrote:
> 
> > 9. The query endpoint path /scs2
> >
> > The current document mandates that the sync query endpoint must be
> > at the path <base-url>/scs2.
> >
> > This feels like a move from what is done with other IVOA standards,
> > which leave the internal path structure to the implementer.
> > ...
> > Should we not be allowing a service to call its query endpoint
> > whatever they want, like /query, /search?
> > This constraint makes deployment under URL hierarchies with
> > versioning awkward (e.g., /v2/query) as we'd have to use /v2/scs2.
> > ...
> > Can clients just discover the query URL from capabilities without
> > relying on path naming conventions?
> 
> They can, but as long as we don't see a major downside to fixing the
> names, the fewer freedoms service implementors have the better for
> the client writers, which is what I'm concerned about first and
> foremost.

Agreed clients should be able to submit a query without having to go
first to capabilities and parse that to locate the correct endpoint.
That's especially true where somebody is just hacking together a
DIY cone search client in bash or python.

However, that doesn't necessarily mean you have to have a fixed
name component ("/scs2"), it depends on what the client knows about
the service.  As long as the capabilities and tables endpoints are
siblings of the service URL, as described in Section 3,
then humans or machines can pass round the service URL and it can
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.

> > 10. The meta.id;meta.main char array requirement
> >
> > For providers that have Integer ID columns they'll have to convert
> > to VARCHAR at query time which I suspect will be easy to miss and a
> > potential source of compatibility issues.
> ...
> 
> :-).  Well, my take is that it helps clients a great deal if they
> know that the id (that they'll want to do all kinds of operations
> with) is always a string.  If that's true, we'll have to go after
> services that return something else.

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?

I think it would make more sense to let the service use whatever
ID type is most suitable.  This might also be more compact
(e.g. a long is 8 bytes or <=20 characters) and provide something
that's more useful to the end user, for instance if they want to
take the ID and upload-match it against a TAP service that uses
the same ID values.

Mark

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/