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

[BONNAREL FRANCOIS]

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/20231208/e3406b31/attachment.htm>