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