Error in the WD-STC-S-1.0-20130918 document?
Patrick Dowler
pdowler.cadc at gmail.com
Fri Dec 8 18:26:40 CET 2023
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)
> - replaces earlier IVOA-Note by Arnold Rots (20091030)
> - TAP-1.0: Section 6, “Use of STC-S in TAP *(informative)*”
> - Recommends using THEIR interpretation of STC-S based on the 1.30
> STC-S NOTE, and STC DM 1.33 REC.
> - F-X notes that this differs from the STC-S WD
> - TAP-1.1:
> - 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.
> - The document doesn't even provide a reference for the STC-S
> syntax any more.
> - ADQL-2.0:
> - 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”
> - 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”.
> - 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
> - 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)
> - 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.”
> - 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-String serialization? (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/24056ed9/attachment-0001.htm>
More information about the apps
mailing list