VODataService, last questions before PR

[Markus Demleitner]

Dear Registry,

I would like to bring VODataService 1.2 to RFC soon-ish as part of
the program of finally enabling STC queries in the Registry [1].

Since interest in extended column metadata was not overwhelming, I'd
propose to postpone that topic to 1.3 (or so), and the fallout of
caproles ("DALIInterface") isn't quite clear yet.  So:  I've prepared
a new draft of VODataService 1.2 which I would like to upload as a PR
when I'm back from vacation (i.e., early July).  

The current state can be obtained from Volute at
https://volute.g-vo.org/svn/trunk/projects/registry/VODataService and
as a pre-built PDF from http://docs.g-vo.org/VODataService.pdf.

What's new versus the last WD?

* A brief piece on discovering data collections; it was agreed at the
  TCG in Paris to have its content represented in a REC somewhere.

* coverage/spatial now has a @frame attribute so we won't have to
  change the schema when planetary frames come in.

* There's now a SHOULD on tablesets for CatalogResources and
  CatalogServices; validators will have a license to warn you if it's
  missing.

* interface/@testQuery is now a singleton

* I'm now officially declaring footprint/@ivo-id is *not* the ivoid
  of the footprint service but rather a standardID for the type of
  footprint that's returned.  It's what everyone has done so far,
  though it has a funny smell.  Protest and I'll properly add a 
  standardID attribute (or, even better, do it yourself).

There's still a few TODOs that I'll try to iron out based on any
feedback I'll get until early July (orange boxes in the PDF):

(a) NULL schemas (as, for instance, in Simbad, where all tables are
global), right now, are expected to be marked

  <schema>
    <name>default</name>

-- using "default" as a NULL value is a bit klunky.  If I could
design VODataService again, I'd probably make name optional for
schema.  On the other hand, for RegTAP, we'd need some kind of thing
here anyway, because rr.res_schema.schema_name is used by a foreign
key in res_table, and for interoperability we don't want NULLs in
primary keys.   So, I suppose at the latest in RegTAP some bespoke
NULL-like value would return anyway.

(b) I don't think anyone ever did anything productive with
interface/resultType.  I don't see much of a purpose for it, and
somewhat conflicts with DALI RESPONSEFORMAT.  Well, it interacts not
terribly favourably.  I'd like to say *something* on the whole
matter, but I'm not sure what.  If you have suggestions, I'm all
ears.

(c) InputParams are currently restricted to use SimpleDataTypes
(essentially, real, string, integer).  In particular with standards
like SODA into which you pass arrays I think it would be preferable
to at least *allow* VOTableTypes here as well (perhaps even with a
hidden agenda to move them entirely to VOTableTypes and then just
deprecate all other type systems?).

If I don't hear from you, based on my current gut feelings I'd expect
the following to happen: (a) will stay "default", (b) I'll feel bad
about and ignore, and (c) will no longer constrain the type system of
InputParams.


So -- if you're running a non-trivial publishing registry or produce
or consume tablesets, I'd highly appreciate if you could have a look
and protest while we're still in WD.  And as usual Volute commits are
gratefully appreciated.

Thanks,

          Markus

[1] Remember the roadmap http://ivoa.net/documents/Notes/Regstc/?