SCS2: Stelios' last two items

[Markus Demleitner]

Dear DAL WG,

Sorry for the flood of SCS2-related messages, but I'd finally like to
push out the WD.  And from Stelios' Big Bug Issue
<https://github.com/ivoa-std/SCS2/issues/7>, there are still two
items left that I'd like to bring up here to give everyone a chance
to contradict me:

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.

As to a departure... that depends; for instance, sync and async are
fixed in TAP, and I feel that makes clients' lives a good deal
easier.

> 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.

Part of why I'm doing the exercise with SCS2 is that I think we
absolutely need to avoid any expectations that multiple major (or
otherwise) versions will live next to each other.  I am really,
really sure that we'd be doing our users a huge disservice if we
didn't make it so there is only one version of a standard at any time
except for painful times of transitions.

[Ahem: we *are* doing our users a disservice by the current mess of
SIA1 and SIA2 in parallel]

> I think we should allow any endpoint name for the query endpoint
> and instead require services to advertise the full query URL in the
> capabilities document via <accessURL use="base">.

We already do this right now.  For a while I was convinced ParamHTTP
with full query endpoint URLs are a bad pattern given we have all the
compound interfaces (e.g., with examples endpoints; tables and
capabilities, fortunately, are now resource-global again).  I'm no
longer that sure.

But that's only mildly related to having predictable last URL
segments (.../capabilities, /tables, and then /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.


And here's the last piece of Stelios' feedback:

> 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, that's why there are automatic validators.  They'll easily pick
that up.

> Perhaps worth provide guidance on whether services are expected to
> cast the identifier, or whether clients should handle integer-typed
> meta.id;meta.main fields as valid even if technically
> non-conformant?

:-).  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.

At least in DaCHS' implementation (that, full disclosure, didn't do
that in the beginning for ConeSearch-1 and then was caught by
validators) it turned out that fixing things to always return strings
in the ID column was surprisingly simple.  So, I'm against
downgrading the string requirement to a SHOULD (which basically is
what Stelios suggests here).


Disagreements?

Again: Stelios, thanks for your feedback.  The SCS2 WD is going to be
a lot better for it, I believe.

And please add your reviews to all of
<https://github.com/ivoa-std/SCS2/pulls>.

Thanks!

       Markus