WD-DALI-1.1-20160415

[Mark Taylor]

Hi Pat.

On Thu, 21 Apr 2016, Patrick Dowler wrote:

> > However, thinking about it, the TAP service as a whole has a capability
> > as well as all its sub-services, so something like:
> 
> Well, one thing that is changing between TAP-1.0 and TAP-1.1 is that
> the standardID(s) for 1.1 are for the individual capabilities, which
> are:
> 
> TAP#sync-1.1
> TAP#async-1.1
> 
> and that non-versioned one that applies to the base URL is TAP-1.0
> only. In future the service as a whole does not have a capability. The

>From my point of view (trying to work out how a client presents
this bag of services to a user), that change doesn't look like
an improvement.  I admit that I have not tried hard to understand
the motivation for that change.  However, I sense that it's not
likely to get changed back now, so I'm not necessarily volunteering
to get into an argument about it here.

> document is already a group of capabilities of a service. A service
> provider can retain the TAP-1.0 base URL capability and nothing in
> DALI-1.1 or TAP-1.1 breaks that compatibility. However, it is
> currently not possibly to correctly describe what some providers need
> to provide
> 
> One aspect that maybe hasn't been mentioned is that DALI specifies
> that all resources have to be siblings of the VOSI-capabilities
> resource so that clients can find it from any known interface url
> (started with DataLink, pulled up to DALI as a standard practice).
> Since /capabilities is one of the resources under the TAP base url,
> describing the base url is not sufficient (essentially, it was wrong
> to do that in 1.0 but we were lazy/rushed/uninformed at the time).
> 
> Trying to keep the single TAP base URL concept and the "sibling of
> VOSI-capabilities" means the only viable option is to have a complete
> duplicate service for every securityMethod.

.. and why not?

>                                             On the other hand,
> VOResource already allows service providers to describe multiple
> interfaces for a single capability and in our experience in CADC and
> CANFAR this is the correct conceptual model and it works. I'm not
> saying it isn't more complex because it is, but it is only as complex
> as it needs to be and it isn't nearly as complex as it looks at first
> glance.

I can see from a server point of view setting things up like this
makes perfect sense.  But does your "it works" experience include
building client user interfaces (that are not reliant specific knowledge
about the way a particular service is set up) to work with this
kind of service setup?  If so, I'd be interested to learn from them.

> For a standard TAP service with anonymous access, things will look
> more or less like they did before.
> 
> >   <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>
> 
> I should note that /tap-auth is *not* in our current VOSI-capabilities
> document for TAP-1.0 because we comply with DALI-1.1 "siblings"
> restriction. I did take the liberty of including the https interface
> because I think in spirit it is a sibling resource accessed via
> different wire protocol. Obviously the text has to make this more
> clear.

Yes, I know that you don't have a tap-auth tree, but that's what
I'd like it to look like.
 
> With this approach there is now a complete duplicate service because
> it now needs VOSI resources to be a TAP service:
> 
> /tap/async
> /tap/sync
> /tap/availability
> /tap/capabilities
> /tap/tables
> 
> ...
> 
> /tap-auth/async
> /tap-auth/sync
> /tap-auth/availability
> /tap-auth/capabilities
> /tap-auth/tables

I think you're saying that's bad, but it looks like a sensible solution
to me.

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/