Updates/corrections desired for the Obscore DM specification

[Markus Demleitner]

Dear Mireille, dear DM,

On Sat, Oct 28, 2017 at 05:27:02PM +0200, Mireille Louys wrote:
> We will collect the requirements for changes and I can , as editor of the
> spec , propose an Errata Page for ObsCore v1.1 to be evaluated by TCG before
> next Interop .

Since the list is quite long already, perhaps we should consider
putting out a 1.2 (I'm quite sure we could do a fast track with REC
after Washington) version rather than trying to patch things up with
errata -- with the number of errata from Alberto alone things start
to get perhaps a bit confusing.  And I have two additional issues:

(1) In Table 1, for floating point-typed columns, it still says
"double".  I'd argue that we should follow the practice for the other
types and not require any specific length (and should make that
clear).  So, instead of "double" I submit it should be "floating
point" throughout.  Rationale: While for t_min and t_max, for
instance, using extended precision *may* be a good idea (though
perhaps not in a discovery context, but who knows?), there is no
scenario I could think of that would require double precision of,
say, em_res_power; it should therefore be no error to return VOTable
floats for the field.

(2) s_region.  Obscore 1.1 is in direct contradiction with TAP 1.1
and DALI 1.1 in that their geometries (circle, polygons) are now
arrays of floating point (I leave the door open to have string-valued
geometry specs since both ESO and Aladin support them).  

This results in changes at least in Table 1 (where it would probably
say "Geometry" as type) and in sect. 4.12 that should, I submit, be
re-written from scratch, basically saying only that the type of
s_region must be such that it works with INTERSECTS and CONTAINS and
that the serialisation in query responses is defined by the standards
of the response format (e.g. DALI/VOTable).

(3) Since 4.12 currently says that s_region is essentially optional,
it would be great if there was some way for clients to discover if
they can use s_region on a service.  I'd say Obscore should define a
feature type for TAPRegExt for that purpose.

For 2 and 3, I'd be happy to provide draft language if people agree
these things need to be fixed.

        -- Markus