Referencing tables from capabilities

[Markus Demleitner]

Dear Registry,

On the way to the RFC for VODataService 1.3, we have thought quite a
bit about somehow linking capabilities with tables within a tableset.
Use cases for that include:

* Cone searches: A resource can have multiple tables suitable for SCS
  services, and then there can be multiple SCS services to access
  them.  There currently is no machine-readable way to say which
  capability is for which table.

* HATS/HiPS-tables: similarly, there are cases when several tables
  can offer access via HATS or HiPS.  Again, there is currently no
  way to clearly say which capability matches which service.

There was PR #27 <https://github.com/ivoa-std/VODataService/pull/27>
that explained why this is non-trivial, but in the end this is a
pattern that appears fairly common and should probably be addressed
in a uniform way, not relying on the relatively haphazard method
currently envisaged for SCS2 (where you learn about the table names
by examining metadata from the TABLE parameter; this clearly is
SCS2-specific).

The relatively simple fix is to define in VODataService (which also
defines the tableset itself, which makes it the obvious place for the
definition) an extension of vr:Capability that just adds a forTable
element.  It could perhaps be vs:CapabilityForTable, and then you'd
write something like:

  <capability standardID="ivo://ivoa.net/std/scs2#query-2.0"
      xsi:type="cs:CapabilityForTable">
    <interface xsi:type="vs:ParamHTTP">
      <accessURL use="base">http://dc.g-vo.org/bla</accessURL>
      <queryType>GET</queryType>
      <resultType>application/x-votable+xml</resultType>
      <param ...>
      <param ...>
    </interface>
    <forTable>gaia.dr3lite</forTable>
  </capability>

[based on
http://dc.g-vo.org/oai.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://org.gavo.dc/gaia/q3/cone]

In SCS2, we'd still want the param[TABLE] stats to make it simple for
the clients, but on the registry side this is far more explicit, and
for HATS/HiPS and possibly VOEvent there's no param[TABLE] anyway, so
this isn't a option.

I am pretty sure that we want forTable 0..1 (or perhaps even
mandatory?) rather than 0..n; *if* we have standards that work on
multiple tables from a tableset, I'd submit they want custom
extensions.

I don't think this is terribly useful for discovery, and thus for now
I'd say this would end up in res_details in RegTAP.  The intended use
would typcially be that clients pull capabilities and tableset from
the services directly once they know they'd like to use a table and
they want to figure out which service to use.

So, what does everyone think?  Is there something wrong with this
reasoning?  Should we get this into 1.3 or rather prototype it for a
bit in the 1.4 cycle?

Thanks,

           Markus