Can an SIA service support both V1 and V2?

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Fri Apr 13 09:40:19 CEST 2018


Hi,

On Fri, Apr 13, 2018 at 08:09:55AM +0200, Marco Molinaro wrote:
> > One thing that I am unable to wrap my mind around is how this gets put in
> > the registry.  Do we just
> > register two capabilities using the same base URL?
> 
> 
> And here is registry field.
> From my poor knowledge I would say "yes", but I leave word to registry
> experts.

It's a clear yes.  You  want different capabilities with different
standard ids so clients will locate your services, but there's
nothing wrong with having the same access URL in interfaces of two
different capabilities.

Tow brief considerations on this:

(1) I've been telling people to use

  select email
  from rr.res_role
  natural join rr.interface
  where access_url='<whatever>' and base_role='contact'

to figure out who to complain to if something is wrong with a service
at <whatever> -- but as long as contact is the same for the different
interfaces, that's still going to work, perhaps dumping several rows.
But that's already going to be the case with auxiliary capabilities.


(2) The pattern proposed by Tom might even help with a thing that's
been on my mind in that field for a while -- suppose clients start
doing all-VO searches on SIAv1 and SIAv2 at the same time -- as SIAv2
gets taken up, more and more data sets would be shown twice (or even
three times, when the client also does obscore).  

SIAv1 doesn't have publisher DIDs (and quite a few services will
botch these in SIAv2, at least if we go by the experiences with SSAP)
-- reliably weeding out dupes (at least on the level multi-protocol
access) therefore is going to be at least tricky.  *If* identical
access URLs were to become a common pattern, clients could at least
mitigate the situation by removing dupes from the access URLs
discovered.


Incidentally, at the GAVO data center (and in DaCHS in general),
we're going the other way -- there are many SIAv1 services but only
one SIAv2, which, obscore-style, serves all images available in the
data center.  The individual data collections are registered
using auxiliary capabilities
(http://ivoa.net/documents/Notes/discovercollections/20161111/).

Client support for that pattern perhaps isn't all brilliant yet, but
at least it's going to help a lot to keep all-VO queries feasible.

         -- Markus




More information about the dal mailing list