"DALI services" in VOSI and Registry

[Mark Taylor]

Markus,

On Wed, 17 Oct 2018, Markus Demleitner wrote:

> That, in turn, would mean that future DALI service discovery should be
> based on a DALI *interface* type, which I'd like to include in
> VODataService.  Such an interface, for a TAP service, would look like
> this:
> 
>   <capability standardID="ivo://ivoa.net/std/TAP">
>     <interface xsi:type="vs:DALIInterface">
>       <accessURL>http://dc.g-vo.org/tap"</accessURL>
>       <endpoint>sync</endpoint>
>       <endpoint>async</endpoint>
>       <endpoint>capabilities</endpoint>
>       <endpoint>tables</endpoint>
>       <endpoint>examples</endpoint>
>     </interface>
>   </capability>

I completely agree with your analysis and, as far as I can tell,
your proposal.

I've been bleating about the problem for a while, as has Paul
Harrison, but I didn't have a suggestion for how to fix it in
VOResource, since I never feel like I have a very good grasp
of the registry design.  But if you think this proposal works,
that sounds good to me.  At this level of detail at least,
I don't see any problems with it myself.

One advantage you don't spell out of doing it this way is that
we get back, as Paul put it, "*the* URL of a service that
I can cut and paste into an email/twitter message etc".

> Now, to build a complete service interface, a client that has just
> discovered a TAP capability has to assemble matching sync and async
> endpoints, presumably based on securityMethod/@ivoid (sketched as as
> security in the example) -- but who knows?  Which other criteria might
> occur in the future?  It will then have to get the other capabilities
> from the capabilities endpoint; it is, I think, the selling point of
> this approach that this is unique and can be found using the sibling
> rule "take away the last segment from the URL, glue on capabilities".
> 
> Now, in the other capabilities, the client will have to see if there are
> interfaces with the securityMethod/@ivoid it is currently gathering for.
> If there are none, I suppose they are to accept whatever interface is
> given without a securityMethod (what happens when there's neither the
> exact security method nor an open interface?).  And they will have to
> repeat that procedure for examples and whatever other DALI endpoints we
> will come up with.

Exactly.  I have in the last few weeks implemented clients for all this
(topcat's TAP client, taplint, sundry other stilts TAP client tasks),
and have therefore proved by construction that client-side implementation
is not impossible.  However it was fairly fiddly, and it doesn't feel
very robust against different ways that services might put together
their capabilities documents (though that latter point is somewhat
addressed by the extra text about bundles that I supplied for the TAP PR).
It is my job to write TAP clients, so a bit of fiddly code isn't
going to kill me.  But if I was a hapless astronomer trying to,
e.g., hack together some python to query an authenticated TAP service,
I think the complication you describe above could be a significant
obstacle.

>                     Savour all this -- and then imagine how much fun
> this becomes when we throw in mirrorURLs.

I actually tried to include some use of mirrorURLs in my implementation,
but I gave up, at least at this attempt, because it was too horrible.
 
> That's a lot of complexity we pile upon our client writers.  And it's a
> lot of moving parts that our registry record writers can break.

I will willingly throw away the implementation code I've just written
and re-do it following your proposal if that gets adopted.

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/