Can an SIA service support both V1 and V2?

[François Bonnarel]

Hi Tom, Marco, Markus, all,

The same service can have the two flavors indeedd, but I think we have 
to be carefull about the way to do it.

For input parameters I see at least two of them with different usage or 
syntax POS and FORMAT (maybe others)

I think if it had been not removed by DALI, The VERSION parameter would 
have been a way to distinguish the meaning and behavior of other query 
parameters, and we should not allow query parameters of the two 
vesrsions in the SAME QUERY.

     So what to do ? Add two different endpoints to the root url ? Add a 
new parameter for distinguishing the versions ?

For the response, concatanation of the two versions standard FIELDS in 
the same table will give a lot of redondancy.

We can image adding missing FIELDS of version n to the whole table of 
version p (or vice versa). Replace n py 1 and p by 2.

AS Marco stated the result will be a little bit odd and not really 
consistent with whatever version of VOTABLE.

But I can imagine adding WCS-like FIELDS of SIAV1 to the SIAV2/OBscore 
response makes sense.

Yes a good discussion for protocols feedbacks in VIctoria.

Cheers

François




Le 13/04/2018 à 09:40, Markus Demleitner a écrit :
> 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
>
>