UCD elements and other versioning issues
Marco C. Leoni
mleoni at eso.org
Fri Jul 2 07:41:32 PDT 2004
Martin Hill wrote:
> How does an *old* service know how to use a translator service?
Given the actual "rhythm of change" I don't think an old service will
survive in a few months without some restyling. :-)
>
> Consider a distributed system of services across the world (eg the VO
> :-). The services all talk to each other using a reasonably common
> set of service interfaces. Then one day we add a new one; it has a
> very similar interface, except that the metadata now contains UCD2s.
>
> If our old service tries to read that new metadata, what will happen?
> I wont' know what to do with the returned document. Should we include
> in the request for the metadata the version of UCD? In which case
> this might apply to many other elements (Units for example is likely
> to change). This makes the request rather awkward.
Having an attribute that specifies the UCD version doesn't seem so bad.
>
>
> Of course our new service should be backwards compatible, so maybe it
> has a 'getNewMetadata()' and a backwards-compatible 'getMetadata()'
> method (which I would prefer
> http://wiki.astrogrid.org/bin/view/Astrogrid/VersioningWebServices).
> So this is fine - our old service calls the 'getMetadata()' that it
> knows about and gets back the old UCDs, because the new service knows
> it has to call a translation service.
>
> If our old service submits a document with its old UCD1+s in it, to
> the new service, the new one can call a translation service and off it
> goes. But how does it return the results? Does it keep tabs of the
> UCD version used in the incoming document in order to know what to put
> in the results?
The new service will use the translator service again to convert the
answer back to the format used by the requestor.
>
> And a translator service will *only* work while there really is
> one-one/many mapping between old UCD versions and newer ones. In
> other words, we can do that as long as ERROR converts to
> phys.temp.error and phys.ra.error etc, and all the latter convert to
> ERROR. Can we assume that this will always be the case in the future?
>
I don't see any problem in the translat as long as the conversion is:
1 (UCD1) ---> n (UCD1+)
>
> Marco C. Leoni wrote:
>
>> Unless they use a "translator" service (or include such a thing
>> within themselves).
>>
>> Since a conversion has to be made anyway, including all the possible
>> UCD-translations of the metadata seems superfluous and also overload
>> ing the transmitted xml.
>>
>>
>> Marco
>>
>>
>> Martin Hill wrote:
>>
>>> This means then that new services that support, say UCD2s, cannot be
>>> used by older services or clients that have no knowledge of UCD2s...
>>>
>>> Marco C. Leoni wrote:
>>>
>>>> Hi Tony,
>>>> I think the services should say the UCDs version they are using
>>>> or can understand/support: the registry - as a service itself -
>>>> will specify the UCD version used to create the metadata describing
>>>> itself.
>>>>
>>>>
>>>> Cheers,
>>>> Marco
>>>>
>>>>
>>>>
>>>> Tony Linde wrote:
>>>>
>>>>> I agree with Clive. We need some way of saying that version X of
>>>>> registry
>>>>> uses UCD1 and version X+1 will use UCD2 or whatever. Or each
>>>>> registry says
>>>>> which versions of individual standards it supports (UCDs,
>>>>> Identifiers, etc).
>>>>> We certainly shouldn't stuff every variant of every standard into the
>>>>> metadata.
>>>>>
>>>>> Tony.
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Clive Page
>>>>>> Sent: 02 July 2004 09:11
>>>>>> To: registry at ivoa.net
>>>>>> Cc: VOTable mailing list
>>>>>> Subject: Re: UCD elements
>>>>>>
>>>>>> On Thu, 1 Jul 2004, Martin Hill wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> We will need (at latest when we introduce UCD2 over UCD1+)
>>>>>>> simultaneous UCDs of different versions in single metadata
>>>>>>
>>>>>>
>>>>>>
>>>>>> documents
>>>>>>
>>>>>>> (so both older and newer tools can use them).
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Is that really necessary? As I understand it there is a unique
>>>>>> one-to-one mapping from UCD1 to UCD1+, which should be easily
>>>>>> encapsulatable in software, or even a Web Service. I'm not sure
>>>>>> if that's true too of UCD2, but if it isn't doing conversions is
>>>>>> going to be labour-intensive.
>>>>>> Putting duplicated UCDs of different versions in each data file
>>>>>> seems a bit of overkill if that's true.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Clive Page
>>>>>> Dept of Physics & Astronomy,
>>>>>> University of Leicester,
>>>>>> Leicester, LE1 7RH, U.K.
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/registry/attachments/20040702/d0df3541/attachment-0001.html>
More information about the registry
mailing list