Error in the WD-STC-S-1.0-20130918 document?

Gregory MANTELET gregory.mantelet at astro.unistra.fr
Tue Dec 12 10:28:16 CET 2023


Hi all,

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


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.

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

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.

Cheers,
Grégory M.


On 08/12/2023 18:26, Patrick Dowler wrote:
> 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".
>
> 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.
>
> 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.
> --
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada
>
>
> On Fri, 8 Dec 2023 at 09:12, CresitelloDittmar, Mark 
> <mdittmar at cfa.harvard.edu> wrote:
>
>     All,
>
>     > Should an erratum be issued?
>     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.
>
>     > Do Coords and Meas offer an ASCII-String serialization? (Laurent?)
>        STC-S is a serialization standard which was designed to map to
>     the STC-1.33 model.
>        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.
>        However,
>            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.
>                  (e.g. Redshift, is not in the current Meas model).
>            2) Meas, Coords and Transform models only cover some of the
>     components from the original STC scope.  Regions, Intervals, and
>     Areas are not covered
>                and are a big part of the STC-S syntax.
>
>     >Let's move that WD to the "Obsolete IVOA documents"
>     Taking Francois' list another step, a quick scan of how those RECs
>     relate to STC-S.
>
>       * STC-S: Space-Time Coordinate Metadata Linear String
>         Implementation (DAL-WD-20130917)
>           o replaces earlier IVOA-Note by Arnold Rots (20091030)
>       * TAP-1.0: Section 6, “Use of STC-S in TAP *(informative)*”
>           o Recommends using THEIR interpretation of STC-S based on
>             the 1.30 STC-S NOTE, and STC DM 1.33 REC.
>           o F-X notes that this differs from the STC-S WD
>       * TAP-1.1:
>           o Section 2.7.2 - on upload, DALI syntax MUST be supported,
>             previous STC-S convention MAY be supported; strongly
>             recommends output in DALI syntax
>               + this moves away from the STC-S representation in favor
>                 of DALI syntax.
>           o The document doesn't even provide a reference for the
>             STC-S syntax any more.
>       * ADQL-2.0:
>           o Section 2.4.1: Region function
>               + “The format of the string is to be specified by a
>                 service that accepts ADQL by referring to a standard
>                 format.Currently STC/s is the only standardized string
>                 representation a service can declare”
>           o Section 2.4.14: REGION
>               + “ The format of the string MUST be specified by a
>                 service that accepts ADQL by referring to a standard
>                 format.Currently STC/s is the only standardized string
>                 representation a service can declare”.
>           o Reference:
>             http://www.ivoa.net/Documents/latest/STC-S.html which
>             resolves to https://www.ivoa.net/documents/Notes/STC-S/,
>             the IVOA-Note by Arnold, v1.33 20091030
>       * ADQL-2.1: REC 20230418
>           o 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)
>           o Section 4.7.1: Geometry:DALI MUST be supported.. “Note
>             that other specifications (e.g. STC/s) or any other kind
>             of value MAY also be supported.”
>           o The reference: http://ivoa.net/documents/STC-S/ resolves
>             to the 20130917 WD.
>
>     It appears that the IVOA is moving away from STC-S in favor of the
>     DALI syntax.
>     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.
>
>     Mark
>
>
>
>
>     On Fri, Dec 8, 2023 at 9:48 AM BONNAREL FRANCOIS
>     <francois.bonnarel at astro.unistra.fr> wrote:
>
>         Dear all,
>         Coming back to this after a week or so.
>
>         What we have here could be an issue of backwards compatibility.
>
>         - TAP 1.0 ( REC 2010) enhances stsc-s for spatial geometries
>         (but we may need a spectral frame to define this probably)
>         So does ADQL 2.0
>         - 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.
>         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
>         TAP 1.1 was a  REC in 2019
>         ADQL 2.1 : REC last month !!
>
>         So my guess is that we have a lot of ObsTAP services (or
>         ObsCore tables in TAP services) which still use stc-s extensively.
>
>         Backwards compatibility would require that this still
>         supported and not considered as an obsolete document.
>
>         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
>
>         Cheers
>         François
>
>         Le 30/11/2023 à 21:39, Adrian Damian a écrit :
>>         Hi F-X,
>>
>>         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?
>>
>>         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.
>>
>>         Adrian
>>
>>         On Thu, Nov 30, 2023 at 8:55 AM Francois-Xavier PINEAU
>>         <francois-xavier.pineau at astro.unistra.fr> wrote:
>>
>>             Hi Markus,
>>
>>             Thank you very much or your answer.
>>
>>             I was not aware of your parser:
>>             * what do you mean by 'halfway complete'?
>>             * what about using it in astropy regions
>>             (https://github.com/astropy/regions/issues/21) ?
>>
>>             > 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
>>             (again, thank you); 2 - STC-S could be used as an input
>>             to create ST-MOCs, F-MOCs, ... in addition to S-MOCs.
>>
>>             There are others possibilities (STC-S based queries in
>>             QAT2S, more general STC-S parser in Aladin Lite, ...).
>>
>>             > The operationally (still) relevant subset for
>>             specifying geometries is in section 6 of TAP 1.0
>>             Grrr... I see that:
>>             * the 'frame' is mandatory in the STC-S document and
>>             optional in TAP,
>>             * the vocabulary is not exactly the same:
>>                 CART[123] vs CARTESION[123]
>>                 SPHER2 vs SPHERICAL2
>>                 It 's easy to support both inputs, but an option is
>>             needed in output (to choose between the STC note and the
>>             TAP standard).
>>
>>             FWIW, I just published a first version of the Rust STC-S
>>             parser:
>>             https://github.com/cds-astro/cds-stc-rust
>>             For non-Rust users the main interest so far may be to
>>             transform STC-S string into JSON, back and forth.
>>
>>             > 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
>>             ASCII-Stringserialization? (Laurent?) (Maybe I am old
>>             school, but I kind of like ASCII-String serializations)
>>
>>
>>             fx
>>
>>
>>             Le 29/11/2023 à 11:09, Markus Demleitner a écrit :
>>>             Hi FX,
>>>
>>>             On Tue, Nov 28, 2023 at 04:58:34PM +0100, F.-X. Pineau wrote:
>>>>             I am implementing a STC-S parser (in Rust, obviously) from the
>>>>             WD-STC-S-1.0-20130918 document:
>>>>>             https://www.ivoa.net/documents/STC-S/20130917/WD-STC-S-1.0-20130917.html
>>>             Do you have a strong reason to do that?  You see, I've once written a
>>>             halfway complete one (if you're interested:
>>>             https://gitlab-p4n.aip.de/gavo/dachs/-/tree/main/gavo/stc), 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
>>>             <https://ivoa.net/documents/TAP/20100327/REC-TAP-1.0.html>  <https://ivoa.net/documents/TAP/20100327/REC-TAP-1.0.html>.
>>>
>>>             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.
>>>
>>>>             Is the grammar wrong?
>>>>             Is there an 'official/original' STC-S parser that could be used as a
>>>>             reference?
>>>>             Should an erratum be issued?
>>>             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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20231212/b03dd3a4/attachment-0001.htm>


More information about the apps mailing list