Late RegTAP rr.interface update [was: rr.interface+auth=ouch]

[Markus Demleitner]

Hi Pat,

On Fri, Apr 12, 2019 at 12:09:22PM -0700, Patrick Dowler wrote:
> Having said that, I agree with Theresa that losing information that people
> put into registry records seems wrong. Are there other cases where
> information in someone's publishing registry does not make it into RegTAP?

Quite a few.  Most notably of course most of the complex content in
TAPRegExt (e.g., user defined functions).  Also, some not-so-complex
content from *RegExts (like testQuery) are optional (and even where
not, they're just mapped into res_detail), because nobody
has found a discovery case for them.  Analogously, the
testQueryString from VOResource 1.1 interface isn't mapped since it
seems unlikely people will ever want to do discovery on them.

The case for securityMethod is a bit different, however: I'm sure
there are discovery cases for it, in particular "Give me all services
I have credentials for" (supposing there is some sort of federated
authentication in the VO eventually).  The problem is that with
current securityMethod modelling, there's no way to answer such a
query; it simply needs more metadata (essentially something like
"authentication authority supported" or perhaps even "group
required", I guess).

Is there a discovery case involving the security method ids (which is
all we have now)?  I don't really see any.  Will clients want to know
"all services that use authentication schemes I have code for"?
Frankly, I'd hope that will never be needed and VO service providers
will agree on two or three auth schemes so common that all
self-respecting clients will support all of them.  Any other
situation will make our users seriously unhappy.

> How bad is it to add the security_method table with just the identifiers
> now (to preserve that content)?  Then we can use that as a base to
> prototype what if anything else might go inside a securityMethod element
> and hence that table... that would probably rule out PR before Paris.

If I believed there's a useful discovery case for that, I'd have
added it.  But since I don't: It's always so much easier to add
something than to take something (that's part of a standard) away.

So, if you have something to prototype, just let me know and I'll do
a table in reg.g-vo.org.  That's quite independent of anything we
might specify in RegTAP 1.1.

> My personal bet: I don' think anything will go in there and I'd store an
> array of URI in the interface table but that's opening up a whole different
> can of worms so *waves hands* let's discuss how that sort of thing could
> work over drinks in Paris :-)

Yeah -- the fattest worm of all being the lack of a non-painful, if
possible even streamable, way to store arrays of variable-length
strings in VOTable cells.  If anyone wants to put that on their
plate, they'd have my heartfelt support.  But meanwhile: Assume you
have that array: What would you do with it?

          -- Markus