Re: String representations of numeric values

From: Thomas McGlynn <tam-at-lheapop.gsfc.nasa.gov>
Date: Fri, 21 Apr 2006 09:21:13 -0400


Mark Taylor wrote:

> On Thu, 20 Apr 2006, Thomas McGlynn wrote:
>
>

>>At it's clear that the USNO table is incorrect in the new version
>>(since it specifies that the column is a double).

>
>
> I've just retrieved a table from the USNO-B conesearch using the URL:
> http://www.nofs.navy.mil/cgi-bin/vo_cone.cgi?CAT=USNO-B1&RA=50.1&DEC=-37.5&SR=0.16
> It has RA and DEC FIELD components with the attributes
>
> datatype="double" arraysize="3x1"
>
> which, while you might argue it's eccentric, is not incorrect, this is
> exactly how you specify an array-valued column according to both
> versions 1.0 and 1.1 of the standard.
>

Well I guess my reading of the Cone Search spec was that the type was a double, but I suppose that doesn't explicitly preclude it being an array -- though I think it should be forbidden and that that was the original intent.

The SIA protocol also doesn't explicitly forbid arrays but given this discussion I think it should.

The language is squishy here....

   "Exactly one field MUST have ucd="POS_EQ_RA_MAIN", with datatype="double", representing the ICRS right-ascension of the center of the image."

So by a liberal interpration if I had a position with RA=123.456, any of the following are valid responses (in addition to the sexagesimal issues).

       123.456       (Yea!)
       1 2 3. 4 5 6
       6 5 4. 3 2 1 (no reason to make it easy for the reader!).
       1  2 3 -1 4  5  6
       100 23 0.45 .006 .000 1 -1  (and any other numbers that sum to 0)

They all "represent" the ICRS coordinate in the sense that I can easily define the mapping between these values and the coordinate, but if the standard is to be useful it must be more restrictive and it had never crossed my mind that providing coordinates in something other than a scalar giving decimal degrees was legal...

Sigh... There are more things in VOTable and SIAP then are dreamt of in my philosophy.

        Tom Received on 2006-04-21Z15:22:06