Obscore extension for radio: review, implementation point (3)

[Markus Demleitner]

Dear Mireille,

On Wed, Dec 13, 2023 at 03:28:39PM +0100, Mireille LOUYS wrote:
> Do you mean you do not want to use utypes for the extension table :
> 'ivoa.obs_radio' or also for 'ivoa.obscore'.

I don't want to make this a major point, but I cannot fail to notice
that utypes do not have any operational role in either obscore nor
obs_radio -- there is nothing any software does with them, or any
functionality that wouldn't be available if they weren't there. To
me, that mildly poses the question of why we bother with them.

> The quantities that are stored in the columns need to belong to some more
> general schema carrying the context.

We could discuss that in itself, but more pragmatically: do the
utypes really help to link to that context?  I mean, not even I know
*what* to look up *where* when I see the string

  Provenance.Observation.sky_scan_mode

-- and certainly no machine could do that; so, why not just state
whatever context link there may be in the spec rather than bothering
implementations and validators with it?

But my point was still a lot more trivial: I'm much rather drop that
string altogether than quarrel whether that ought to be SkyScanMode,
which I think would make it a bit more consistent with the other
obscore utypes.

But feel free to drop the whole thread:  While in general I much
prefer it when what we *require* is something we actually *need* in a
standard so it works (long version of that thought:
https://blog.g-vo.org/requirements-and-validators.html) -- and that
is certainly not true for the column utypes here --, I feel this
isn't a good place to re-think age-old VO practices, either.

          -- Markus