Discovering Data Collections Note

[Markus Demleitner]

Hi again,

On Fri, Nov 04, 2016 at 11:54:27AM -0700, Patrick Dowler wrote:
> The other idea I had for aux capabilities was to define a capability
> type whose extra metadata was the resource identifier of the real
> service, eg:
> 
> <capability standardID="ivo://ivoa.net/std/SIA#query-2.0"
>    xsi:type="aux:LinkedService">
>     <resourceIdentifier> ivo://cadc.nrc.ca/sia </resourceIdentifer>
> </capability>
> 
> That's probably not much different from the old served-by
> relationships in practice, except that it does say what type of
> service that is right here (in the DataCollection) which I think means
> questions of the form "find data collections like ... with an SIAv2
> query interface" would be straightforward queries. It would just
> result in a resource identifier for that service rather than
> interfaces and accessURLs. It does clobber xsi:type, but since my
> concern is having to duplicate metadata about service deployments in
> different places I see that as a feature rather than a drawback.

If we started from scratch, something like this might be an
interesting path to investigate, although I'd like to point out that
xsi:type-based constraints *in addition to* standardID-based ones
don't seem terribly attractive to me.

However, we already have quite a bit of infrastructure in place, and
this idea will blow that up the moment VizieR registers its 10000+
tables as TAP services with the "usual" TAP standardID; you'd
suddenly have 10000+ TAP services in non-updated clients, non-updated
validators will run stilts taplint 10000+ times against VizieR, etc.

We had a mild pretaste of that the other day when IRSA accidentally
declared their 400 or so tables as full-fledged TAP services and
TOPCAT's TAP service browser became... ah... usability-impaired.

So -- no, I'm convinced auxiliary capabilities need to have different
standardIDs for the primary capabilties to avoid major migration
pains and for robustness.  I'll mention in passing that the proposed
scheme also meshes nicely into the incremental changes we need to
make to our discovery procedures now that we actually have multiple
versions of some our protocols out there.

         -- Markus