SCS2: POS plus RA/DEC/SR

[Mark Taylor]

The current SCS2 draft says (sec 4.1.6):

   "SCS2 services may support a POS parameter as defined by SIAP2
    (Dowler and Bonnarel et al., 2015), except that for SCS2, this is a
    non-repeatable parameter."

so the multi-position benefit does not apply here, as the text
is currently written.

On Thu, 3 Sep 2026, Patrick Dowler via dal wrote:

> The main argument for POS (vs 3 separate params) in SIAv2 is that it
> is easier to support a list of values just by submitting multiple
> POS={value} pairs in the query. Yes, there is the OR semantics but
> that's still a lot simpler than specifying and implementing table
> upload for multi-position queries in an S-protocol. (It was easier to
> specify in TAP because we just had to be clear on how table would be
> named for use in ADQL and the rest was up to the user writing the
> correct ADQL)
> 
> So my 2c is that POS is superior to RA+DEC+SR. And this is version 2.0 ...
> --
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada
> 
> On Thu, 3 Sept 2026 at 03:02, Markus Demleitner via dal <dal at ivoa.net> wrote:
> >
> > Dear DAL,
> >
> > In the next installment of me bringing some of Stelios' points from
> > his (finally migrated) SCS2 bug
> > <https://github.com/ivoa-std/SCS2/issues/7>[1] is this:
> >
> > > Supporting both POS and RA/DEC/SR as alternatives adds meaningful
> > > complexity on both the service and client side, and I'm wondering
> > > if the benefit justifies it.
> >
> > > Clients can discover whether POS is supported by fetching
> > > /capabilities and inspecting the declared parameters, but the
> > > spec's own appendix says simple clients don't need to fetch
> > > capabilities at all.
> > >
> > > Those clients will probably always use RA/DEC/SR right, and then
> > > sophisticated clients would probably just be using TAP anyways?
> >
> > Possibly, yes, provided the table is available via TAP.
> >
> > > On the service side, supporting both creates an awkward
> > > discriminated-union input that static schema validation cannot
> > > express.
> > > RA/DEC/SR must be typed as optional to allow POS as an alternative,
> > > and the mutual-exclusivity check requires runtime logic outside the
> > > framework's validation pipeline:
> >
> > I'd count that as a minor annoyance, but yes, that is evidence
> > against supporting POS.
> >
> > > Either drop POS and keep RA/DEC/SR (simple, familiar), or make POS
> > > the canonical interface?
> > > I think either is preferable to requiring implementations to handle
> > > both indefinitely. Or perhaps worth clarifying the tradeoff in the
> > > spec?
> >
> > I've always been rather uncertain about POS; on the one hand, it is
> > nice to have the same parameter as SIAv2, on the other hand, the
> > polygon thing (and perhaps MOC later) is a pain to implement without
> > something like pgsphere in the backend.
> >
> > I remain neutral and would simply throw out POS given any amount of
> > opposition if it weren't for voices in Strasbourg that said they have
> > huge catalogues that they may not want to open up to all the
> > complexities of TAP (and perhaps don't even keep in an RDB) but for
> > which they'd like to have more expressive geometry types than just
> > the cone.
> >
> > So... opinions?
> >
> > Thanks,
> >
> >           Markus
> >
> 

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