Re: Comments on VOTable 0.94

Francois, Roy,
 I'd like to endorse Clive's recommendation that COOSYS  explicitly group column identifiers. Missing from both FITS  and VOTABLE is any explicit linking of the elements of a coordinate  pair, which causes problems when multiple coordinate systems  (e.g. two J2000 systems for different estimates of a star's position)  are present.

 To expand on the point about FITS extensions, how does one represent  a FITS table with multiple extensions? If one simply does a VOTABLE  with multiple tables, each with a FITS EXTENSION=n, we'll have to be a bit careful with implementation efficiency - avoid retrieving the  same FITS file N times (especially if the file is gzipped) - should  the FITS attribute perhaps apply to a whole resources of multiple tables?

 (answer: probably not, but maybe there is some higher level approach   we can take?)
 I'm a bit confused by the FITS example given in 6.1.2, since it  doesn't have a "FITS" element in it although the DTD does.  (but I am still very bad at reading DTD's; perhaps in Tucson we  can have someone take XML novices through the VOtable DTD?)

 I probably missed an earlier discussion on this point, but I see there is no support for unsigned integers. I tried getting away  with this in the Chandra software and ended up having to cave in  and support it. (FITS of course in practice supports it via a  clever use of the TSCAL keyword and the implementation in CFITSIO).  Although I personally am prepared to agree that unsigned integers  are evil, I nevertheless believe that we will have to support them  in some way.

 The use of the 'RESOURCE' element in the first example is a bit  confusing... I don't see the usefulness of a RESOURCE without an ID,  it's good to be able to structure things but you have to have a way  of referring to them. Should ID be mandatory? I agree with  Roy (I think it was Roy?) that the ASTRO tag should be dumped and  just made to be RESOURCE.

 The statement that 'not all VOTable will map to FITS' is a little  strong - really the truth is that 'we will have to define conventions  to map a general VOTable to FITS' (and in fact vice versa: we will  have to have conventions to handle what we understand by TSCAL, what  we do when a keyword and column have the same name, but can't have  the same VOTable ID - if I understand 3.3 correctly, and so on).

 In fact, I think the right thing to do will be to make a separate  document defining a VOTable to FITS mapping in detail, so that  we don't get 500 different conventions for doing this. Right now  there's too much reference to FITS that should really be in such a  separate document rather than in the VOTable standard itself, at least  that's my impression.

 In the document it describes INFO as a simple version of PARAM;  in the DTD they are defined separately, as indeed is each element.  I take it that there's no concept of inheritance in DTDs?  In the Data Model section I would more explicitly say that  PARAM, FIELD and INFO are special cases of a single thing.

 regards,
  Jonathan

 .-------------------------------------------------------------------.


 |  Jonathan McDowell            |  phone : (617) 495-7176           |

 |  Harvard-Smithsonian Center   |  fax   : (617) 495-7356           |

 |   for Astrophysics            |                                   |

 |  60 Garden St, MS6            |                                   |

 |  Cambridge MA 02138           | email : jcm-at-cfa.harvard.edu       |

 |  USA                          | email : jmcdowell-at-cfa.harvard.edu |

 `-------------------------------------------------------------------'