A variant form of FITS file is written by the
FitsPlusTableWriter
handler.
This is the same as the basic form,
except that the primary HDU (HDU#0)
contains a 1-d array of characters which form the text of a DATA-less
VOTable. The FITS table in the first extension (HDU#1) is understood to
contain the data. The point of this is that the VOTable can contain
all the rich metadata about the table, but the bulk data are in a form
which can be read efficiently. Crucially, the resulting FITS file
is a perfectly good FITS table on its own, so non-VOTable-aware readers
can read it in just the usual way, though of course they do not
benefit from the additional metadata stored in the VOTable header.
While the normal VOTable/FITS encoding has some of these advantages, it is inconvenient in that either (for in-line data) the FITS file is base64-encoded and so hard to read efficiently, in particular for random access or (for referenced data) the table is split across two files.