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 tables in the subsequent extensions are understood to
contain the data. The point of this is that the VOTable can contain
all the rich metadata about the table(s), 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.