TAP 1.1, RegTAP 1.1, xsi:type

[Markus Demleitner]

Hi Mark,

On Thu, Sep 27, 2018 at 12:13:13PM +0100, Mark Taylor wrote:
> Pat, Markus, anybody else who wants to weigh in:
> 
> I'm looking at the example in PR-RegTAP-1.1-20180731 section 10.1.
> It says:
> 
>    Clients only interested in [TAP] services not requiring authentication
>    should now use
> 
>       SELECT ivoid, access_url
>       FROM rr.capability
>       NATURAL JOIN rr.interface
>       WHERE standard_id like 'ivo://ivoa.net/std/tap%'
>         AND intf_type='vs:paramhttp'
>         AND security_method_id IS NULL
> 
> Comparing this with the sample capabilities document in PR-TAP-1.1-20180830
> section 2.4, it doesn't quite make sense: the interface elements
> having associated securityMethods in that example are the ones
> with xsi:types of urx:Sync or urx:Async, not vs:ParamHTTP, so the
> security_method_id check above is probably looking in the wrong place.

With the example I'm trying to set a general pattern; even if we go
forth defining new interface types to go with authenticated services,
forcing security_method to NULL when you know you'll not be able to
authenticate in the first place is a good thing to do.  If clients do
that from now on, we will have more air to breathe if and when
authenticated services enter the registry in large numbers.

If, additionally, future discovery of standard services with sync and
async protocols really has to use two different interfaces[1], the
security_method_id part of this wouldn't change (or so I hope).

          -- Markus


[1] I'll publicly out myself here as now wishing we didn't have to split
up sync and async.  Could be a case of TAP 1.0 nostalgia, though.