TAPRegExt fine grained differences between tables

[Douglas Tody]

If this is something that varies on a per-table basis another
possibility might be to add custom extensions to the TAP_SCHEMA.  The
content would not be standardized, but it would be easy to query and
view from a client.  An index for example is a type of per-table
capability that is already supported.  The DBMS itself already uses
tables to store information about capabilities such as functions, albeit
in a proprietary form.   - Doug


On Thu, 11 Jun 2015, Mark Taylor wrote:

> Walter,
>
> On Wed, 10 Jun 2015, Walter Landry wrote:
>
>> Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
>>> Hi Walter,
>>>
>>> On Tue, Jun 09, 2015 at 04:53:51PM -0700, Walter Landry wrote:
>>>> We have a variety of tables with different backends all served
>>>> through a single TAP endpoint.  Because the backends are different,
>>>> they support different optional components of TAP.  Reading the
>>>> TAPRegExt standard, is it correct to say that there is no way to
>>>> express these kind of fine-grained differences between the tables?
>>>
>>> This concerns what user-defined functions are available on them?
>>> Things like upload limits/formats?  These, yes, are declared globally
>>> per capability.  I'd recommend per table examples (for now, as per
>>> the TAP Implementation Note, if I may say so myself) to document
>>> where the system behaves in ways surprising to users.
>>
>> Ok, though this feels vaguely unsatisfying.
>
> I can see how this might not fit your service very well, so I can
> sympathise with the "unsatisfying" sentiment.  But I'm inclined to think
> the alternative would be worse.  TAPRegExt is already reasonably
> complex, and if the options are (optionally) multiplied by a number
> of backends per service I can imagine this would often end up being
> write-only metadata: dutifully filled in (or not) by service
> providers but never actually used for anything by any client.
> As an author of a TAP/TAPRegExt client, I doubt I could write
> a GUI that presents per-table service capability metadata to
> users in a way that they'd really digest.  Machine clients might
> have more chance, but it would still add quite a bit of processing
> complexity for likely not much benefit.
>
> Just my 2p (which I reserve the right to change my mind about
> if somebody persuades me differently)
>
> Mark
>
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
>