<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
<div dir="ltr" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I like POS for the reason Pat described.</div>
<div dir="ltr" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="ltr" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I like RA/DEC for a different reason: it makes it *very* easy to invoke SCS via service descriptor links from a table. From a UI perspective this is a very nice feature: a data publisher can serve up a catalog table and include DataLink annotations for “search
Gaia around this point”, and so on.</div>
<div dir="ltr" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="ltr" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
This feature could be provided with the POS interface if service descriptors could do general templating, but with the current DataLink, there has to be a 1:1 match between columns and service parameters.</div>
<div dir="ltr" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="ltr" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Gregory</div>
<div id="ms-outlook-mobile-body-separator-line" data-applydefaultfontstyles="true" dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<div style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<br>
</div>
</div>
<div style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" id="ms-outlook-mobile-signature" dir="auto">
<div dir="ltr" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="font-family: -apple-system, HelveticaNeue; font-size: 13.398001px; color: rgb(33, 33, 33);">--</span><span style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span><span style="font-family: -apple-system, HelveticaNeue; font-size: 13.398001px; color: rgb(33, 33, 33);">Gregory Dubois-Felsmann, Ph.D. | Senior Staff Scientist | Caltech/IPAC</span><span style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span><span style="font-family: -apple-system, HelveticaNeue; font-size: 13.398001px; color: rgb(33, 33, 33);">Science Platform Scientist, Vera C. Rubin Observatory</span><span style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span><span style="font-family: -apple-system, HelveticaNeue; font-size: 13.398001px; color: rgb(33, 33, 33);">Pipeline System Designer, NASA SPHEREx mission</span><span style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span><span style="font-family: -apple-system, HelveticaNeue; font-size: 13.398001px; color: rgb(33, 33, 33);">Mail Code MR 100-22 | Pasadena, CA 91125-2200 | </span><span style="font-family: -apple-system, HelveticaNeue; font-size: 13.398001px; color: rgb(0, 120, 212);">gpdf@ipac.caltech.edu</span></div>
<div dir="ltr" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> dal <dal-bounces@ivoa.net> on behalf of Patrick Dowler via dal <dal@ivoa.net><br>
<b>Sent:</b> Thursday, 03 September 2026 15:11:27<br>
<b>To:</b> dal@ivoa.net <dal@ivoa.net><br>
<b>Subject:</b> Re: SCS2: POS plus RA/DEC/SR</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">The main argument for POS (vs 3 separate params) in SIAv2 is that it<br>
is easier to support a list of values just by submitting multiple<br>
POS={value} pairs in the query. Yes, there is the OR semantics but<br>
that's still a lot simpler than specifying and implementing table<br>
upload for multi-position queries in an S-protocol. (It was easier to<br>
specify in TAP because we just had to be clear on how table would be<br>
named for use in ADQL and the rest was up to the user writing the<br>
correct ADQL)<br>
<br>
So my 2c is that POS is superior to RA+DEC+SR. And this is version 2.0 ...<br>
--<br>
Patrick Dowler<br>
Canadian Astronomy Data Centre<br>
Victoria, BC, Canada<br>
<br>
On Thu, 3 Sept 2026 at 03:02, Markus Demleitner via dal <dal@ivoa.net> wrote:<br>
><br>
> Dear DAL,<br>
><br>
> In the next installment of me bringing some of Stelios' points from<br>
> his (finally migrated) SCS2 bug<br>
> <<a href="https://github.com/ivoa-std/SCS2/issues/7>[1">https://github.com/ivoa-std/SCS2/issues/7>[1</a>] is this:<br>
><br>
> > Supporting both POS and RA/DEC/SR as alternatives adds meaningful<br>
> > complexity on both the service and client side, and I'm wondering<br>
> > if the benefit justifies it.<br>
><br>
> > Clients can discover whether POS is supported by fetching<br>
> > /capabilities and inspecting the declared parameters, but the<br>
> > spec's own appendix says simple clients don't need to fetch<br>
> > capabilities at all.<br>
> ><br>
> > Those clients will probably always use RA/DEC/SR right, and then<br>
> > sophisticated clients would probably just be using TAP anyways?<br>
><br>
> Possibly, yes, provided the table is available via TAP.<br>
><br>
> > On the service side, supporting both creates an awkward<br>
> > discriminated-union input that static schema validation cannot<br>
> > express.<br>
> > RA/DEC/SR must be typed as optional to allow POS as an alternative,<br>
> > and the mutual-exclusivity check requires runtime logic outside the<br>
> > framework's validation pipeline:<br>
><br>
> I'd count that as a minor annoyance, but yes, that is evidence<br>
> against supporting POS.<br>
><br>
> > Either drop POS and keep RA/DEC/SR (simple, familiar), or make POS<br>
> > the canonical interface?<br>
> > I think either is preferable to requiring implementations to handle<br>
> > both indefinitely. Or perhaps worth clarifying the tradeoff in the<br>
> > spec?<br>
><br>
> I've always been rather uncertain about POS; on the one hand, it is<br>
> nice to have the same parameter as SIAv2, on the other hand, the<br>
> polygon thing (and perhaps MOC later) is a pain to implement without<br>
> something like pgsphere in the backend.<br>
><br>
> I remain neutral and would simply throw out POS given any amount of<br>
> opposition if it weren't for voices in Strasbourg that said they have<br>
> huge catalogues that they may not want to open up to all the<br>
> complexities of TAP (and perhaps don't even keep in an RDB) but for<br>
> which they'd like to have more expressive geometry types than just<br>
> the cone.<br>
><br>
> So... opinions?<br>
><br>
> Thanks,<br>
><br>
> Markus<br>
><br>
</div>
</span></font></div>
</body>
</html>