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