<div dir="ltr"><div dir="ltr">All,<br></div><div dir="ltr"><div><br></div><div>> Should an erratum be issued?<br></div><div>I agree with Markus on this. The STC-S document was originally a Note, and now a WD.. in either case, there should be no expectation for stability and nothing on which to file an erratum.</div><div><br></div><div>> Do Coords and Meas offer an ASCII-String serialization? (Laurent?) <br class="gmail-Apple-interchange-newline"></div><div> STC-S is a serialization standard which was designed to map to the STC-1.33 model.<br></div><div> It can, in principle, be mapped to other models as well. So one could use the same syntax to identify elements from the "STC2" replacement models.</div><div> However, </div><div> 1) I'm not sure if the content of Meas/Coords covers everything the syntax mapped to since their scope was required to be as minimal as possible.</div><div> (e.g. Redshift, is not in the current Meas model).</div><div> 2) Meas, Coords and Transform models only cover some of the components from the original STC scope. Regions, Intervals, and Areas are not covered</div><div> and are a big part of the STC-S syntax.</div><div><br></div><div>><span class="gmail-Apple-converted-space"> </span>Let's move that WD to the "Obsolete IVOA documents"<br></div><div>Taking Francois' list another step, a quick scan of how those RECs relate to STC-S. </div><div><ul><li><span style="font-family:"Helvetica Neue";font-size:13px">STC-S: Space-Time Coordinate Metadata Linear String Implementation (DAL-WD-20130917)</span><br></li><ul><li><span style="font-family:"Helvetica Neue";font-size:13px">replaces earlier IVOA-Note by Arnold Rots (20091030)</span></li></ul><li><span style="font-family:"Helvetica Neue";font-size:13px">TAP-1.0: Section 6, “Use of STC-S in TAP <b>(informative)</b>”</span></li><ul><li><span style="font-family:"Helvetica Neue";font-size:13px">Recommends using THEIR interpretation of STC-S based on the 1.30 STC-S NOTE, and STC DM 1.33 REC.</span></li><li><span style="font-family:"Helvetica Neue";font-size:13px">F-X notes that this differs from the STC-S WD</span></li></ul><li><span style="font-size:13px;font-family:"Helvetica Neue"">TAP-1.1:</span><span class="gmail-Apple-converted-space" style="font-size:13px;font-family:"Helvetica Neue""> </span></li><ul><li><span style="font-family:"Helvetica Neue";font-size:13px">Section 2.7.2 - on upload, DALI syntax MUST be supported, previous STC-S convention MAY be supported; strongly recommends output in DALI syntax</span></li><ul><li><span style="font-family:"Helvetica Neue";font-size:13px">this moves away from the STC-S representation in favor of DALI syntax.</span></li></ul><li><font face="Helvetica Neue">The document doesn't even provide a reference for the STC-S syntax any more.</font></li></ul><li><span style="font-family:"Helvetica Neue";font-size:13px">ADQL-2.0:</span></li><ul><li><span style="font-family:"Helvetica Neue";font-size:13px">Section 2.4.1: Region function</span></li><ul><li><span style="font-family:"Helvetica Neue";font-size:13px">“The format of the string is to be specified by a service that accepts ADQL by referring to a standard format.</span><span class="gmail-Apple-converted-space" style="font-family:"Helvetica Neue";font-size:13px"> </span><span style="font-family:"Helvetica Neue";font-size:13px">Currently STC/s is the only standardized string representation a service can declare”</span></li></ul><li><span style="font-family:"Helvetica Neue";font-size:13px">Section 2.4.14: REGION</span></li><ul><li><span style="font-family:"Helvetica Neue";font-size:13px">“ The format of the string MUST be specified by a service that accepts ADQL by referring to a standard format.</span><span class="gmail-Apple-converted-space" style="font-family:"Helvetica Neue";font-size:13px"> </span><span style="font-family:"Helvetica Neue";font-size:13px">Currently STC/s is the only standardized string representation a service can declare”.</span></li></ul><li><span style="font-size:13px;color:rgb(0,0,0);font-family:"Helvetica Neue"">Reference: </span><a href="http://www.ivoa.net/Documents/latest/STC-S.html" style="font-size:13px;font-family:"Helvetica Neue"">http://www.ivoa.net/Documents/latest/STC-S.html</a> which <span style="color:rgb(0,0,0);font-family:"Helvetica Neue";font-size:13px">resolves to </span><a href="https://www.ivoa.net/documents/Notes/STC-S/" style="font-family:"Helvetica Neue";font-size:13px">https://www.ivoa.net/documents/Notes/STC-S/</a>, the IVOA-Note<span style="font-family:"Helvetica Neue";font-size:13px"> by Arnold, v1.33 20091030</span></li></ul><li><span style="font-family:"Helvetica Neue";font-size:13px">ADQL-2.1: REC 20230418</span></li><ul><li><span style="font-family:"Helvetica Neue";font-size:13px">Section 3.5: supports DALI geometry types; and STC-S based regions as defined in the STC-S specification (Rots and Demeitner et al; 2013)</span></li><li><span style="font-family:"Helvetica Neue";font-size:13px">Section 4.7.1: Geometry:</span><span class="gmail-Apple-converted-space" style="font-family:"Helvetica Neue";font-size:13px"> </span><span style="font-family:"Helvetica Neue";font-size:13px">DALI MUST be supported.. “Note that other specifications (e.g. STC/s) or any other kind of value MAY also be supported.”</span></li><li><span style="color:rgb(0,0,0);font-family:"Helvetica Neue";font-size:13px">The reference: </span><a href="http://ivoa.net/documents/STC-S/" style="font-family:"Helvetica Neue";font-size:13px">http://ivoa.net/documents/STC-S/</a> <span style="font-family:"Helvetica Neue";font-size:13px">resolves to the 20130917 WD.</span></li></ul></ul></div><div>It appears that the IVOA is moving away from STC-S in favor of the DALI syntax. </div><div>It seems like we need to preserve some stable instance of the WD since it is referenced in RECs. Can this be down-graded to an update of the Note? This would provide an end-point for the existing references, but can also stop work on that front so the focus can move to the DALI syntax.</div><div><br></div><div>Mark</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 8, 2023 at 9:48 AM BONNAREL FRANCOIS <<a href="mailto:francois.bonnarel@astro.unistra.fr">francois.bonnarel@astro.unistra.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<div>Dear all,</div>
<div>Coming back to this after a week or so.</div>
<div><br>
</div>
<div>What we have here could be an issue of
backwards compatibility.</div>
<div><br>
</div>
<div>- TAP 1.0 ( REC 2010) enhances stsc-s
for spatial geometries (but we may need a spectral frame to define
this probably)</div>
<div>So does ADQL 2.0<br>
</div>
<div>- ObsCore 1.1 (REC 2017) let open that
future versions of TAP and ADQL may support the ObsCore table and
queries in the future but still requires stc-s strings in s_region
at the time of writing. <br>
</div>
<div>I don't think we define clearly
somewhere which of the DALI xtypes we can use in s_region if we
are ported by new versions of TAP/ADQL<br>
</div>
<div>TAP 1.1 was a REC in 2019</div>
<div>ADQL 2.1 : REC last month !!</div>
<div><br>
</div>
<div>So my guess is that we have a lot of
ObsTAP services (or ObsCore tables in TAP services) which still
use stc-s extensively.</div>
<div><br>
</div>
<div>Backwards compatibility would require
that this still supported and not considered as an obsolete
document.</div>
<div><br>
</div>
<div>So to face FX issue some erratum should
be written somewhere to explain the BNF had to be fixed. I don't
know if this is to be done in TAP 1.0, in DALI or in ObsCore 1.1
itself <br>
</div>
<div><br>
</div>
<div>Cheers</div>
<div>François<br>
</div>
<div><br>
</div>
<div>Le 30/11/2023 à 21:39, Adrian Damian a
écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi F-X,
<div><br>
</div>
<div>I gave a presentation on this subject at the last IVOA
interop. We at the CADC went through the same exercise with
the parser just to discover that it has no future and we
should direct effort elsewhere. Maybe a MOC-regions parser and
encoder that could be then used for footprints?</div>
<div><br>
</div>
<div>The bottom line is that STC-S leaves a void that we as a
community need to fill in soon. So yes, I agree that STC-S
should be moved to a retired documents corner but at the same
time a replacement should be put in place. I'm not sure which
WG should drive this.</div>
<div><br>
</div>
<div>Adrian </div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Nov 30, 2023 at
8:55 AM Francois-Xavier PINEAU <<a href="mailto:francois-xavier.pineau@astro.unistra.fr" target="_blank">francois-xavier.pineau@astro.unistra.fr</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi Markus,</p>
<p>Thank you very much or your answer.<br>
<br>
I was not aware of your parser:<br>
* what do you mean by 'halfway complete'?<br>
* what about using it in astropy regions (<a href="https://github.com/astropy/regions/issues/21" target="_blank">https://github.com/astropy/regions/issues/21</a>)
?</p>
<p>> <span>Do you have a strong reason to do that?
Several users have been asking for MOC creation from a
STC-S string, and we have been
thinking to add this features to MOC Lib Rust (and
hence, to MOCPy).
And:
1 - I was not aware of the subset (for geometries)
defined in the TAP document (</span><span>again, </span><span>thank
you);
2 - STC-S could be used as an input to create ST-MOCs,
F-MOCs, ... in addition to S-MOCs.</span></p>
<p><span>There are others possibilities (STC-S based queries
in QAT2S, more general STC-S parser in Aladin Lite,
...).
</span></p>
<p>> The operationally (still) relevant subset for
specifying geometries is in section 6 of TAP 1.0<br>
Grrr... I see that:<br>
* the 'frame' is mandatory in the STC-S document and
optional in TAP,<br>
* the vocabulary is not exactly the same:<br>
CART[123] vs CARTESION[123]<br>
SPHER2 vs SPHERICAL2<br>
It 's easy to support both inputs, but an option is
needed in output (to choose between the STC note and the
TAP standard).<br>
<br>
</p>
<p>FWIW, I just published a first version of the Rust STC-S
parser:<br>
<a href="https://github.com/cds-astro/cds-stc-rust" target="_blank">https://github.com/cds-astro/cds-stc-rust</a><br>
For non-Rust users the main interest so far may be to
transform STC-S string into JSON, back and forth.<br>
</p>
<p>> <span>Let's move that WD to the "Obsolete IVOA
documents"
Since it has been asked by users, it seems that STC-S is
used, right?
Do Coords and Meas offer an </span>ASCII-String<span>
serialization? (Laurent?)
</span>(Maybe I am old school, but I kind of like
ASCII-String serializations)<br>
<span></span></p>
<p><br>
</p>
<p>fx<br>
</p>
<p><br>
</p>
<div>Le 29/11/2023 à 11:09, Markus Demleitner a écrit :<br>
</div>
<blockquote type="cite">
<pre>Hi FX,
On Tue, Nov 28, 2023 at 04:58:34PM +0100, F.-X. Pineau wrote:
</pre>
<blockquote type="cite">
<pre>I am implementing a STC-S parser (in Rust, obviously) from the
WD-STC-S-1.0-20130918 document:
</pre>
<blockquote type="cite">
<pre><a href="https://www.ivoa.net/documents/STC-S/20130917/WD-STC-S-1.0-20130917.html" target="_blank">https://www.ivoa.net/documents/STC-S/20130917/WD-STC-S-1.0-20130917.html</a>
</pre>
</blockquote>
</blockquote>
<pre>Do you have a strong reason to do that? You see, I've once written a
halfway complete one (if you're interested:
<a href="https://gitlab-p4n.aip.de/gavo/dachs/-/tree/main/gavo/stc" target="_blank">https://gitlab-p4n.aip.de/gavo/dachs/-/tree/main/gavo/stc</a>), and I've
regretted it, as there is little use for it.
The operationally (still) relevant subset for specifying geometries
is in section 6 of TAP 1.0
<a href="https://ivoa.net/documents/TAP/20100327/REC-TAP-1.0.html" target="_blank"><https://ivoa.net/documents/TAP/20100327/REC-TAP-1.0.html></a>.
Even there, there's no formal specficiation, and really, nobody wants
to touch the whole mess; in our DALI discussions, there was zero
enthusiasm for moving that material into that spec (where it could
become normative). See the current DALI 1.2 WD for the sort of types
we would like to use in the future.
But, well, the TAP 1.0 STC-S subset at least is (still) in active
use.
</pre>
<blockquote type="cite">
<pre>Is the grammar wrong?
Is there an 'official/original' STC-S parser that could be used as a
reference?
Should an erratum be issued?
</pre>
</blockquote>
<pre>The document is a (fairly rough) working draft, so there wouldn't be
an erratum but a new working draft.
But nobody has touched the WD in a decade, and I don't see that
change, in particular since the underlying data model (STC 1.03) has
been superseded by Coords and Meas in the meantime.
My take would be: Let's move that WD to the "Obsolete IVOA documents"
section in the doc repo. It keeps confusing people who are actually
looking for the TAP 1.0 geometry specification.
-- Markus
</pre>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<p><br>
</p>
</div>
</blockquote></div></div>