WD-DALI-1.1-20160415

Mark Taylor M.B.Taylor at bristol.ac.uk
Tue Apr 19 13:22:34 CEST 2016


On Tue, 19 Apr 2016, Markus Demleitner wrote:

> Hi,
> 
> On Mon, Apr 18, 2016 at 10:14:24PM +0100, Mark Taylor wrote:
> > Pat,
> > 
> > On Mon, 18 Apr 2016, Patrick Dowler wrote:
> > 
> > > I appreciate that the base URL concept looks a lot simpler and we
> > > tried to us that concept within CADC and CANFAR... but eventually had
> > > to move toward the one proposed. The first sore spot is that
> > > VOResource places securityMethod under interface under capablity. That
> > > means that for one "feature" defined by a standardID you have one
> > > capability and one or more interfaces (possibly) differing by
> > > securityMethod.
> > 
> > I agree that VOResource design is not helping here.
> 
> Now that you mention it: I'm currently overhauling VOResource in
> preparation for having DOIs (and ORCIDs), fixing some minor
> annoyances on the way.
> 
> While I want to be careful not to break anything that already works,
> I'd like to mention that
> 
>   select distinct(ivoid) from rr.res_detail where detail_xpath like '%securityMethod%';
> 
> just yields
> 
>  ivo://sao.ru/community
>  ivo://sao.ru/vospace-service
> 
> -- both of which look a bit orphaned to me.
> 
> So, I'd say if you have better ideas, a point could be made that the
> securityMethod design should be changed.  The
> service/capaility/interface model, on the other hand, is probably
> sacrosant at this point.

I was being a bit imprecise - it's more the fact that the securityMethod
is attached to the interface elements for individual services
that I was complaining about.

However, thinking about it, the TAP service as a whole has a capability
as well as all its sub-services, so something like:

  <capability standardID="ivo://ivoa.net/std/TAP"
              xmlns:tr="http://www.ivoa.net/xml/TAPRegExt/v1.0"
              xsi:type="tr:TableAccess">
    <interface xsi:type="vod:ParamHTTP" role="std" version="1.0">
      <accessURL use="base">http://www.cadc.hia.nrc.gc.ca/tap</accessURL>
    </interface>
    <interface xsi:type="vod:ParamHTTP" role="std" version="1.0">
      <accessURL use="base">https://www.cadc.hia.nrc.gc.ca/tap</accessURL>
      <securityMethod standardID="ivo://ivoa.net/sso#tls-with-certificate" />
    </interface>
    <interface xsi:type="vod:ParamHTTP" role="std" version="1.0">
      <accessURL use="base">http://www.cadc.hia.nrc.gc.ca/tap-auth</accessURL>
      <securityMethod standardID="http://www.w3.org/Protocols/HTTP/1.0/spec.html#BasicAA"/>
    </interface>

could be used to indicate bundles of related endpoints that share
a securityMethod and correspond to a TAP service (set-of-endpoints).
That doesn't stop the individual endpoints being listed explicitly
as well in the capabilities document, but as a TAP client I'd probably
ignore those (a client only interested in, e.g., availabilities,
would still use them).

--
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/


More information about the dal mailing list