Small question/suggestion re: ObsCore

[Patrick Dowler]

A more careful writing of the "this is the UCD" part could have said "this
is the primary UCD" and implementers can add a modifier of they like...
probably ObsCore is too rigidly specified.

Of course, with added flexibility it would mean clients and validators
would have to be more careful as well.

my 2c,
--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Mon, 19 Nov 2018 at 08:09, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Hi DAL,
>
> On Fri, Nov 09, 2018 at 12:22:06PM -0800, Gregory Dubois-Felsmann wrote:
> > The ObsCore 1.1 standard, in Appendix C, Table 6, specifies the
> > UCDs to be associated with ObsCore columns.  In particular, for
> > s_ra and s_dec, it suggests pos.eq.ra and pos.eq.dec.
> >
> > [...]
> > Was it considered, or would it be appropriate, for a service
> > returning an ObsCore-compliant table (e.g., an SIAv2 or ObsTAP
> > service) to be required (or strongly recommended) to include
> > “meta.main” in the UCDs for “s_ra” and “s_dec”?
>
> I'm not sure if it was considered, but it makes perfect sense to me.
> It would, at the very least, help clients that don't know obscore or
> don't now that a certain table is obscore make sense of the thing.
>
> The trouble is: how would we get there?  Since validators check for
> the unmodified pos.eq.* UCDs, a service that adds a ;meta.main will
> become invalid.  An erratum proposing the addition would hence be
> sort of hard to justify.  For a similar reason I'm not sure even an
> Obscore 1.2 could introduce it -- although I doubt that at this point
> there's code out there that would break.
>
> So -- if someone finds a way to transition into having *;meta.main in
> obscore, you'd have my support.  But I'm afraid I lack the
> creativity...
>
>           -- Markus
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20181121/d54e6137/attachment-0001.html>