<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hi all,<br>
<br>
<blockquote type="cite">ADQL-2.0 references the STC-S WD because it
predates TAP-1.0.... I think since ADQL-2.1 comes after TAP-1.1
(STC-S gone) it should have referenced TAP-1.0 to address
backwards compatibility concerns, but with a heavy preference for
DALI instead. There's no recommended use of the actual STC-S WD
syntax that I'm aware of. We could at least issue an errata for
ADQL-2.1 to change the STC-S reference to TAP-1.0 (section 6?) --
at least I think that's what we should have done +/- intended by
the backward compat statement.</blockquote>
<br>
<br>
On this point, I am quite divided. I am not sure it worth publishing
an erratum toward a non-normative appendix of an old version of a
standard (TAP-1.0) instead of a working draft released for a long
time. I don't see what we are really going to gain here.<br>
<br>
On one hand, as stated in this thread, ADQL-2.1 now recommends to
use the DALI expressions instead of STC-S. But since DALI does not
cover yet everything STC-S is able to offer, it is still possible to
provide STC-S. Hence this reference (note that if it becomes an IVOA
Note as suggested by Mark, I will certainly be in favor of an
Erratum in ADQL-2.1 in order to refer to this instead). So, when
DALI is complete, as valid STC-S replacement, ADQL will immediately
strongly recommend DALI expressions and will deprecate STC-S
expressions (in order to ensure backward compatibility).<br>
<br>
On the other hand, considering the strong relation between ADQL and
TAP, it would make sense to use the same reference to STC-S. But
then, TAP-1.1 completely removed any reference to a document
describing STC-S. Since ADQL-2.1 comes after TAP-1.1, it makes also
sense to make the same recommendations than in TAP-1.1...which is
done by recommending to use DALI expressions instead of STC-S when
possible. So, should ADQL-2.1 remove all reference to STC-S as
TAP-1.1 did? But then, it would be more confusing for anyone reading
the term STC-S in the ADQL-2.1 document.<br>
<br>
Cheers,<br>
Grégory M.<br>
<br>
<br>
<div class="moz-cite-prefix">On 08/12/2023 18:26, Patrick Dowler
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFK8nroGqGHx4xy_CKq65TXvUyGagFTQGx+HUAdOCbQ8OoRT7A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">Effectively,
TAP-1.0 "forked" STC-S in a non-normative section because we
could not get to REC with a reference to a WD. That means
current use of STC-S should be as described in TAP-1.0 (that
is what TAP-1.1 is alluding to) and use xtype="adql:REGION"
(yeah, back then we got all kinds of things in the wrong
place). That was supposed to be a "do this until we come up
with a REC".<br>
</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">ADQL-2.0
references the STC-S WD because it predates TAP-1.0.... I
think since ADQL-2.1 comes after TAP-1.1 (STC-S gone) it
should have referenced TAP-1.0 to address backwards
compatibility concerns, but with a heavy preference for DALI
instead. There's no recommended use of the actual STC-S WD
syntax that I'm aware of. We could at least issue an errata
for ADQL-2.1 to change the STC-S reference to TAP-1.0 (section
6?) -- at least I think that's what we should have done +/-
intended by the backward compat statement.<br>
</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">It is
certainly a tangled web and the work to extract common things
to DALI is mostly about pulling those things up to a base REC
that others can depend on. With WD-DALI-1.2 (plus vodml, data
models, and pivot to annotate with metadata) we should be able
to stop using STC-S entirely.<br clear="all">
</div>
<div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div>--<br>
</div>
<div>Patrick Dowler<br>
</div>
Canadian Astronomy Data Centre<br>
</div>
Victoria, BC, Canada<br>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, 8 Dec 2023 at 09:12,
CresitelloDittmar, Mark <<a
href="mailto:mdittmar@cfa.harvard.edu"
moz-do-not-send="true" class="moz-txt-link-freetext">mdittmar@cfa.harvard.edu</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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>
</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> </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
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
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
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""
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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
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"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">francois.bonnarel@astro.unistra.fr</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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"
moz-do-not-send="true"
class="moz-txt-link-freetext">francois-xavier.pineau@astro.unistra.fr</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid 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"
moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"><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>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>