Can an SIA service support both V1 and V2?

[Marco Molinaro]

Dear Tom,
(I add CC registry, given your final question)

2018-04-12 22:34 GMT+02:00 Tom McGlynn (NASA/GSFC Code 660.1) <tom.mcglynn@
nasa.gov>:

> While the versioning of SIAv2 suggests that it is not compatible with
> SIAv1, there
> is a difference between not being compatible and being incompatible.
> I.e., you're
> required to support and return different things from the two services, but
> suppose one
> has a service which supports the union of required inputs and outputs from
> both versions?
> Is that possible?
>

In my personal opinion it's possible.
I'm not sure that I'll go that way, but I don't think there's something
preventing it.
The idea of multiple major versions, moreover, has never been really
discussed
(caveat: I may be wrong here).


> At the HEASARC we are looking at releasing our first SIAv2 services and,
> initially
> at least, our thought is that we can release these services so that they
> support both V1 and V2.
> I.e., they would support the the syntax of the inputs from both V1 and V2
> and they would
> return all required columns for both V1 and V2 responses.  The later is
> made a little
> easier since V1 used UCD's to specify the required columns, while V2 uses
> UTypes.
> So we can mark a single column for both services.
>

My concern here is that, doing so, you sort of prevent standard current UCDs
to
be attached to fields that need to have "VOX" UCDs to be identified.
In a sense you may not make a favor to those who may want to save the
response
VOTable for later use.
In short: it's true you can separate:
- v1 -- UCD
- v2 -- utype
but it doesn't sound great in terms of field annnotations.


> Of course there are lots of things that V2 requires that V1 does not in
> terms of input parameters,
> but there is nothing in the V1 standard that precludes such additional
> parameters.
>
> So I was trying to understand if there are any concrete incompatibilities
> between the two services,
> i.e., a case where one requires A and the other forbids A or somethign
> similar.  Does anyone have any thoughts
> on this?  It seems like if we can support both interfaces -- and the only
> cost is some extra columns in the output --
> that we should try to do it.
>

I'll be happy if you can bring this view in Victoria.
I think it's definitely a thing worth discussing.


> By the by, there are at least two potential ways one could envisage our
> approaching this.  We could try to recognize
> whether we are being called by a V1 or V2 service by the syntax of the
> input arguments and then return an appropriately
> formatted response.  But we've done something a little different. We've
> created a service which accepts both V1 and V2 inputs
> and returns an output that is acceptable to both standards.
>
> 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.

Cheers,
    Marco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20180413/18c65053/attachment.html>