The actual table data (the cell contents, as opposed to metadata such as column names and characteristics) in a VOTable are stored in a TABLE's DATA element. The VOTable standard allows it to be stored in a number of ways; It may be present as XML elements in a TABLEDATA element, or as binary data in one of two serialization formats, BINARY or FITS; if binary the data may either be available externally from a given URL or present in a STREAM element encoded as character data using the Base64 scheme (Base64 is defined in RFC2045). For VOTable version >=1.3, BINARY is deprecated in favour of the new BINARY2 format. See the VOTable 1.3 standard for discussion of the differences.
To summarise, the possible formats are:
<!-- TABLEDATA format, inline -->
<DATA>
<TABLEDATA>
<TR> <TD>1.0</TD> <TD>first</TD> </TR>
<TR> <TD>2.0</TD> <TD>second</TD> </TR>
<TR> <TD>3.0</TD> <TD>third</TD> </TR>
</TABLEDATA>
</DATA>
<!-- BINARY format, inline -->
<DATA>
<BINARY>
<STREAM encoding='base64'>
P4AAAAAAAAVmaXJzdEAAAAAAAAAGc2Vjb25kQEAAAAAAAAV0aGlyZA==
</STREAM>
</BINARY>
</DATA>
<!-- BINARY format, to external file -->
<DATA>
<BINARY>
<STREAM href="file:/home/mbt/BINARY.data"/>
</BINARY>
</DATA>
External files may also be compressed using gzip.
The FITS ones look pretty much like the binary ones, though in the case
of an externally referenced FITS file, the file in the URL is a
fully functioning FITS file with (at least) one BINTABLE extension.
In the case of FITS data the VOTable standard leaves it up to the application how to resolve differences between metadata in the FITS stream and in the VOTable which references it. For a legal VOTable document STIL behaves as if it uses the metadata from the VOTable and ignores any in FITS headers, but if they are inconsistent to the extent that the FIELD elements and FITS headers describe different kinds of data, results may be unpredictable.
At the time of writing, most VOTables in the wild are written in TABLEDATA format. This has the advantage that it is human-readable, and it's easy to write and read using standard XML tools. However, it is not a very suitable format for large tables because of the high overheads of processing time and storage/bandwidth, especially for numerical data. For efficient transport of large tables therefore, one of the binary formats is recommended.
STIL can read and write VOTables in any of these formats. In the case of reading, you just need to point the library at a document or TABLE element and it will work out what format the table data are stored in and decode them accordingly - the user doesn't need to know whether it's TABLEDATA or external gzipped FITS or whatever. In the case of writing, you can choose which format is used.