WD-DALI-1.1-20160415

[Markus Demleitner]

Dear DAL,

First, Marco's proposal:

On Thu, 21 Apr 2016 11:37:13 +0200 wrote:
> Wouldn't it be cleaner to have a unique endpoint that, if secured,
> accepts "anonymous" users to serve only public content?

has a +1 from me, with the proviso that I've not had to worry about
complex auth schemes so far.

Then, as TAPRegExt 1.1's editor:

On Thu, Apr 21, 2016 at 12:01:48PM -0700, Patrick Dowler wrote:
> only. In future the service as a whole does not have a capability. The
> 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

I'm afraid I could not quite figure out what's missing and which
standard needs to be fixed -- could you try to explain once more?  Is
there anything that TAPRegExt (or VOResource, for that matter) could
do to enable/faciliate such a description?

> 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).

Again, I've not quite got what the use case is where the base URL is
not enough -- isn't the point of the sibling rule is exactly that you
can either give a base URL (in the TAP case: the parent of what's
sync or async in 1.0) or an actual access URL (as in
http://dc.g-vo.org/tap/sync), and in both cases you can find out
capabilities  and hence everything you might want to know?

Or is what you're saying just "you won't get around parsing
/capabilities anyway"? [to which my take is: in the general case,
definitely, but the larger the class of special cases which can do
without the better]

Cheers,

      Markus