Re: Support for binary encodings and MIME types

On Wed, 7 Sep 2005, Guy Rixon wrote:

> Hi,
>
> my understanding is that most VOTable libraries still only support TABLEDATA
> encoding of the table and not FITS or BINARY. Therefore, it's not robust to
> send, e.g., a VOTABLE/BINARY document to an arbitrary comsumer. Can anybody
> comment on this?

Guy,

The following VOTable parsers support all three defined VOTable encodings (TABLEDATA, BINARY, and FITS):

• STIL (see http://www.starlink.ac.uk/stil/)
• VO-India's C++ Streaming and non-streaming parsers for VOTable v2.0 (see http://vo.iucaa.ernet.in/~voi/cplusparser_stream.htm) The web page for the non-streaming one says that it only does TABLEDATA, but this appears to be in contradiction with the change log - I haven't tested either.

As far as I know, all other existing VOTable parsers support only TABLEDATA encoding. So your comment is correct.    

> If we have to be careful about which encodings we sent to which consumers,
> then it may be necessary to distinguish the encodings in the MIME type. E.g.,
> we might need application/xml+votable-tabledata and
> application/xml+votable-binary. Comments?

The general idea sounds reasonable. Detailed comments:

1. The agreed basic MIME type for VOTables is "application/x-votable+xml"
2. Rather than different MIME types for each encoding, this looks to me like a job for a subtype-specific parameter, presumably with a name such as 'encoding'. So your Content-Type would be one of

          application/x-votable+xml
          application/x-votable+xml; encoding=TABLEDATA
          application/x-votable+xml; encoding=BINARY
          application/x-votable+xml; encoding=FITS

      I would suggest that the parameter should be optional.
      The unqualified version (without an encoding parameter specified)
      would serve for the case where the software has been written
      prior to this suggestion, or the provider doesn't know the
      encoding, or the consumer doesn't care, or the document
      contains DATA elements with a mixture of different 
      encodings(!).  Alternatives are possible, e.g. to allow
      encoding=ANY which might cover some of the above cases while
      the unspecified value is permitted for backward compatibility.

      RFC2045 allows the parameter values to be case-sensitive; 
      I suggest that we say it's not in this case.
  
      The parameter mechanism is used fairly widely in MIME media
      types; for instance the charset parameter of the text type
      (as in "text/plain; charset=iso-8859-1").

      See RFC 2045 and 2046, especially section 5 of RFC 2045 for 
      discussion of media type/subtype parameters.
          

A general comment: the existing agreement on the VOTable MIME type is not very prominently available anywhere (you have to dredge through the wiki to find
http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2005VOTable#Various_points and http://www.ivoa.net/forum/votable/0311/0380.htm). It would be good if it was more prominent, along with any changes such as the above which we decide to make. The VOTable specification document would be the obvious place to put it, but it may not be worth issuing a new version just to include that. Should I write up a wiki page detailing the currently agreed status or something?

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/