Some confusion in cone-search
francois at vizier.u-strasbg.fr
Sat Oct 3 01:05:20 PDT 2009
VOTable1.1 recommends ucd1+, but does not explicitely forbid the
UCD1 (which is not exactly the same thing as not specifying anything)
During the RFC period of ConeSearch, this question of UCD version
was raised, and the answer was that the cone search app's can't be
>On Fri, 2 Oct 2009, lesidaner-obs wrote:
>> the compliance of the service appears to be wrong.
>> because ucd='ID_MAIN', ucd='ID_MAIN', ucd='POS_EQ_DEC_MAIN'.
>> but all these UCD are not compliant with VOTable 1.1 UCD.
>The VOTable v1.1 spec is a bit vague on this front (a fact we're
>correcting in the v1.2 spec), but in fact, VOTable v1.1 does not actually
>mandate UCD1+ ucds, which your response uses.
>While we are trying to encourage the use of the UCD1+ ucds, as your
>service nicely does, there are places where UCD v1.0 ucds are required.
>One such place is in the Cone Search protocol
>(http://www.ivoa.net/Documents/latest/ConeSearch.html): for those specific
>columns, the ucds must be set to ID_MAIN, POS_EQ_RA_MAIN,
>and POS_EQ_DEC_MAIN, repsectively. This is what clients are expecting.
>So, unfortunately, you will need to change the service to come into
>compliance. (BTW, you may already know about this, but you can test your
>service yourself at http://nvo.ncsa.uiuc.edu/dalvalidate/csvalidate.html)
Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg
11, rue de l'Universite 67000 STRASBOURG Phone: +33-(0)368 85 24 29
Email: francois at astro.u-strasbg.fr (France) Fax: +33-(0)368 85 24 17
More information about the dal