UCD elements and other versioning issues

[Martin Hill]

How does an *old* service know how to use a translator service?

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.

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?

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?


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.
>>>>>
>>>
>>>

-- 
Martin Hill
www.mchill.net
+44 7901 55 24 66