%++++++++
%.IDENTIFICATION VOTable.tex
%.PURPOSE        Specifications of VOTABLE.
%.AUTHOR         Roy Williams, Francois Ochsenbein
%.VERSION  0.96  25-Mar-2002
%.VERSION  0.97  29-Mar-2002
%.VERSION  0.99  09-Apr-2002
%.VERSION  1.0   15-Apr-2002
%--------
\def\ifhtx{\iffalse}    % Lines used only for the HTML version
\def\Version{1.0}	% 09-Apr-2002 RW FO
\def\Vdate{15 Apr 2002}
\ifhtx			% Declarations for HTX (HTML)
\begin{head}
  \tag{META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1"}
  \begin{title}VOTable \Version\ Proposal\end{title}
  \tag{META NAME="robots" content="index"}
  \tag{META NAME="description" content="VOTable Proposal"}
  \tag{META REV="made" HREF="mailto:VOTable@us-vo.org"}
  \tag{META NAME="GENERATOR" CONTENT="StarOffice/5.2 (Linux)"}
  \tag{META NAME="AUTHOR" CONTENT="Roy Williams, Francois Ochsenbein"}
  \tag{META NAME="CREATED" CONTENT="20020315;23390000"}
  \tag{META NAME="CHANGEDBY" CONTENT="Francois Ochsenbein"}
  \tag{META NAME="CHANGED" CONTENT="20020315"}
\end{head}
\Beg{body}{\bg{white}}
\else			% Declarations for LaTeX
\documentclass{article}
\usepackage[pdftex]{graphicx}	% Accept Images
\usepackage{color}		% Accept Colors
\usepackage{verbatim}		% Accept Colors
\let\fg=\color			% fg = foreground color
\let\Beg=\begin
\topmargin=-1cm
\raggedbottom
\oddsidemargin=0cm
\textwidth=17.5cm		% The default width is too small...
\textheight=23.5cm		% The default width is too small...
\arrayrulewidth=0.75pt\renewcommand{\arraystretch}{1.2}
\definecolor{DarkRed}{rgb}{0.5,0,0}
\definecolor{DarkBlue}{rgb}{0,0,0.5}
\definecolor{DarkGreen}{rgb}{0,0.5,0}
\definecolor{DarkMagenta}{rgb}{0.5,0,0.5}
\definecolor{DarkGoldenrod}{rgb}{0.72,0.5,0.05}
\def\slash {{\fg{blue}/}}
\def\attr#1{{\tt{\fg{DarkRed}#1}}}
\def\elem#1{{\tt{\fg{DarkRed}#1}}}
\def\attrval#1#2{{\tt{\fg{DarkRed}#1}="{\fg{DarkMagenta}#2}"}}
\def\elemdef#1#2{{\fg{blue}$<$}{\tt{\fg{DarkRed}#1}#2}{\fg{blue}$>$}}
\def\Aref#1#2{section~\ref{#1}}
\def\value#1{{\tt"}{\fg{DarkMagenta}#1}{\tt"}}
%\def\inputverbatim#1{%
%\begingroup \catcode``=13 \@noligs \tt \let\do\@makeother \dospecials
%\obeylines \obeyspaces \frenchspacing \input #1 \endgroup }
\def\thickrule{\noindent\rule{\textwidth}{1pt}}
\def\Plain#1{{\sf #1}}
\begin{document}
\newenvironment{TABULAR}[2]{\begin{tabular}{#2}}{\end{tabular}}
\newenvironment{plain}{\begin{quote}}{\end{quote}}
\fi

\begin{center}
{{\Large\bf VOTable: A Proposed XML Format for Astronomical Tables }}
\bigskip

\begin{tabular}{l}
Roy {\bf Williams}, California Institute of Technology, USA \\
Fran\c cois {\bf Ochsenbein}, Observatoire Astronomique de Strasbourg, France \\
Clive {\bf Davenhall}, University of Edinburgh, UK \\
Daniel {\bf Durand}, Canadian Astronomy Data Centre, Canada \\
Pierre {\bf Fernique}, Observatoire Astronomique de Strasbourg, France \\
David {\bf Giaretta}, Rutherford Appleton Laboratory, UK \\
Robert {\bf Hanisch},  Space Telescope Science Institute, USA \\
Tom {\bf McGlynn}, NASA Goddard Space Flight Center, USA \\
Alex {\bf Szalay}, Johns Hopkins University, USA \\
Andreas {\bf Wicenec}, European Southern Observatory, Germany \\
\end{tabular}

\bigskip
{\bf\fg{DarkGoldenrod}Version \Version{ }(\Vdate)}
\par
\begin{tabular}{rl}
{\em Document repository:}& http://cdsweb.u-strasbg.fr/doc/VOTable/\\
{\em Comments:} & VOTable@us-vo.org\\
\end{tabular}
\end{center}

\ifhtx
\par\thickrule\par
\tableofcontents
\fi
\par\thickrule\par


\section{Introduction}

The VOTable format is a proposed XML standard for representing a
table. In this context, a table is an unordered set of rows, each of
a uniform format, as specified in the table metadata. Each row is a
sequence of table cells, and each of these is either primitive data
types, or an array of such primitives. The format is derived from the
Astrores format [1], itself modeled on the FITS Table format [2];
VOTable was designed to be closer to the FITS Binary Table format.

\subsection{Example}

A simple example of a VOTable document is:
%
\label{example1}
\ifhtx\Beg{TABULAR}{\bg{LightCyan} CELLPADDING=5}{||l||}\fi
%
\begin{verbatim}
<?xml version="1.0"?>
<!DOCTYPE VOTABLE SYSTEM "http://us-vo.org/xml/VOTable.dtd">
<VOTABLE version="1.0">
  <DEFINITIONS>
  <COOSYS ID="myJ2000" equinox="2000." epoch="2000." system="eq_FK5"/>
  </DEFINITIONS>
  <RESOURCE>
    <PARAM name="Observer" datatype="char" arraysize="*" value="William Herschel">
      <DESCRIPTION>This parameter is designed to store the observer's name
      </DESCRIPTION> 
    </PARAM>
    <TABLE name="Stars">
      <DESCRIPTION>Some bright stars</DESCRIPTION>
      <FIELD name="Star-Name" ucd="ID_MAIN" datatype="char" arraysize="10"/>
      <FIELD name="RA" ucd="POS_EQ_RA" ref="myJ2000" unit="deg" 
             datatype="float" precision="F3" width="7"/>
      <FIELD name="Dec" ucd="POS_EQ_DEC" ref="myJ2000" unit="deg" 
             datatype="float" precision="F3" width="7"/>
      <FIELD name="Counts" ucd="NUMBER" datatype="int" arraysize="2x3x*"/>
      <DATA>
        <TABLEDATA>
        <TR>
          <TD>Procyon</TD><TD>114.827</TD><TD> 5.227</TD>
          <TD>4 5 3 4 3 2 1 2 3 3 5 6</TD>
        </TR>
        <TR>
          <TD>Vega</TD><TD>279.234</TD>
          <TD>38.782</TD><TD>8 7 8 6 8 6</TD>
        </TR>
        </TABLEDATA>
      </DATA>
    </TABLE>
  </RESOURCE>
</VOTABLE>
\end{verbatim}
\ifhtx\End{TABULAR}\fi

\par This table shows the positions of two stars, each with a name and
two floating point numbers as coordinates, together with a
variable-length, multidimensional array called \value{Counts}.
The star names have a fixed length of 10 characters (padded by
trailing blanks). The floating-point numbers (RA and Dec) are in
degrees, and assumed to {\fg{black}have three decimal}
digits ({\attrval{precision}{3}}),
irrespective of the number of digits presented in the data. The frame
of the coordinate system is specified explicitly with the {\elem{COOSYS}}
element. Associated with the table is a parameter ({\elem{PARAM}}),
which is to be interpreted as a string, which in this example is the
name of the observer (William Herschel).

\subsection{Why VOTable?}

Astronomers have always been at the forefront of developments in
information technology, and funding agencies across the world have
recognized this by supporting the Virtual Observatory movement, in
the hopes that other sciences and business can follow their lead in
making online data both {\it interoperable} and {\it scalable}.

VOTable is designed as a flexible storage and exchange format for
tabular data, with particular emphasis on astronomical tables.

Interoperability is encouraged through the use of standards (XML);
because physical quantities are tagged not only with units, but also
through a Uniform Content Descriptor (UCD) that expresses the nature
of the quantity (eg. Gunn J magnitude, declination). The XML fabric
allows applications to easily validate an input document, as well as
facilitating transformations through XSLT (eXtensible Style Language
Transformation) engines.

\subsubsection*{Grid Computing}

VOTable has built-in features for big-data and Grid computing. It
allows metadata and data to be stored separately, with the remote
data linked according to the Xlink model. Processes can then use
metadata to 'get ready' for their input data, or to organize
third-party or parallel transfers of the data. Remote data allow the
metadata to be sent in email and referenced in documents without
pulling the whole dataset with it: just as we are used to the idea of
sending a pointer to a document (URL) in place of the document, so we
can now send metadata-rich pointers to data tables in place of the
data itself. The remote data is referenced with the URL syntax
{{\sf protocol://location}},
meaning that arbitrarily complex protocols are allowed.

When we are working with very large tables in a
distributed-computing environment (``the Grid"), the data
streams between processors, with flows being filtered, joined, and
cached in different geographic locations. It would be very difficult
if the number of rows of the table were required in the header --
we would need to stream in the whole table into a cache, compute the
number of rows, then stream it again for the computation. In the
Grid-data environment, the component in short supply is not the
computers, but rather these very large caches! Furthermore, these
remote data streams may be created dynamically by another process or
cached in temporary storage: for this reason VOTable can express that
remote data may not be available after a certain time (\attr{expires}).
Data on the net may require authentication for access, so VOTable
allows expression of password or other identity information (the
'{\attr{rights}}'
attribute).

\subsubsection*{Data Storage: Flexible and Efficient}

The data part in a  VOTable may be represented using one of three 
different formats: TABLEDATA, FITS and BINARY. TABLEDATA is a
pure XML format so that small tables can be easily handled in their
entirety by XML tools. The FITS binary table format is well-known to
astronomers, and VOTable can be used either to encapsulate such a
file, or to re-encode the metadata; unfortunately it is difficult to
stream FITS, since the dataset size is required in the header 
(NAXIS2 keyword), and FITS requires a specification up front of the maximum
size of its variable-length arrays. The BINARY format
is supported for efficiency and ease of programming: no FITS
library is required, and the streaming paradigm is supported.

We hope that VOTable can be used in different ways, as a data
storage and transport format, and also as a way to store metadata
alone (table structure only).  In the latter case, we can imagine a
VOTable structure being sent to a server, which can then open a
high-bandwidth connection to receive the actual data, using the
previously-digested structure as a way to interpret the stream of
bytes from the data socket. Alternatively, the metadata can be sent
alone as an implicit query to a server, which will respond with the
data part of the table filled in.

VOTable can be used for small numbers of small records (pure XML
tables), or for large numbers of simple records (streaming data), or
it can be used for small numbers of larger objects. In the latter
case, there will be software to spread large data blocks among
multiple processors on the Grid. Currently the most complex structure
that can be in a VOTable Cell is a multidimensional array. 

\subsubsection*{Future}

In future versions of the VOTable format, we expect to benefit
from both experience  and tool-building. Such tools include presentation
and transformations of the metadata (and data too, when it is in
XML), using XML transformation language and software: XSL and XSLT.
We would like to migrate to the more powerful document validation
provided by XSchema [8] rather than DTD -- a draft version of the
VOTable format in XSchema is included as \Aref{xsd}{Appendix}.

We also expect XSchema to allow better modularization of the
document schema, so that, for example, users might put whatever
serialized objects they wish into the table cells. In this way, we
expect to use VOTable for handling the flow of large data objects
through Grid resources, objects such as FITS files or XDF [7]
documents. Also, it would also mean, for example, that the description of a
table could contain arbitrary HTML instead of the current version --
plain text with paragraph markers; or that an XML definition of
non-standard astronomical coordinate systems could be seamlessly
integrated.

VOTable is derived from Astrores, which is specified not only as a way to
write a data table, but also as a way to specify how to address a
{\it request}  to data tables. We
expect to sharpen and formalize this dichotomy with the benefit of
experience, building into VOTable the ways of making
sophisticated querying mechanisms and protocols.

We expect to add features for efficiency in the future also: to
specify that the data stream has a particular sort order, to specify
that a column in one table is a key in to another table; to specify
that one table is an index into another. The binary format will be 
extended to facilitate large-scale streaming.

\section{Data Model}

In this section we define the data model of a VOTable, and in the
next sections its syntax when expressed as XML. The data model of
VOTable can be expressed as:    

\begin{tabular}{ll}
\hspace{3em}&{\bf VOTable} = hierarchy of {\bf Metadata} + {\bf Tables}\\
&{\bf Metadata} = {\bf Parameters} + {\bf Infos} + {\bf Descriptions}
                + {\bf {\fg{black}Links + Fields}}\\
&{\bf Table} = list of {\bf Fields + Data}\\
&{\bf Data} = stream of {\bf Rows}\\
&{\bf Row} = list of {\bf Cells}\\
&{\bf Cell} = {\bf Primitive} \\
&       \begin{tabular}{ll}
        \hspace*{2em}&or variable-length list of {\bf Primitives} \\
        \hspace*{2em}&or multidimensional array of {\bf Primitives}\\
        \end{tabular}\\
&{\bf Primitive} = integer, character, float, floatComplex, etc
(see table below).
\end{tabular}

Metadata is divided into that which concerns the table itself 
(parameters), and the definitions of the fields (or column
attributes) of the table. Each Field represents the metadata at the
top of the column, for example, in the table above, a Field has {\tt name}
set to \value{RA}. The Field can be thought of as a class definition,
and the table cells below it are the instances of that class.

A parameter ({\elem{PARAM}})
is similar to a {\elem{FIELD}},
except that it has a \attr{value} attribute.
Parameters can be used for storing FITS keywords or any other
information pertaining to the table itself or its environment.

An informative parameter ({\elem{INFO}})
is a restricted form of the {\elem{PARAM}} --  it has only the
\attr{name} / \attr{value} pair of attributes.

\label{primitives}
\ifhtx\begin{center}\Beg{tabular}{CELLSPACING=4 CELLPADDING=4}{|rlrl|}
\else
\begin{table}[hbt]
 \begin{center}\begin{tabular}{|r|l|c|r|}
\fi\hline
  {\attr{datatype}} & Meaning & \attr{FITS} &
      { Bytes} \\
 \hline
 \value{boolean}      & Logical 	&\value{L}& 1  \\
 \value{bit}          & Bit  		&\value{X}& *  \\
 \value{unsignedByte} & Byte (0 to 255)	&\value{B}& 1  \\
 \value{short}        & Short Integer 	&\value{I}& 2  \\
 \value{int}          & Integer 	&\value{J}& 4  \\
 \value{long}         & Long integer 	&\value{K}& 8  \\
 \value{char}         & ASCII Character &\value{A}& 1  \\
 \value{unicodeChar}  & Unicode Character&        & 2 \\
 \value{float}        & Floating point 	&\value{E}& 4  \\
 \value{double}       & Double 		&\value{D}& 8  \\
 \value{floatComplex} & Float Complex 	&\value{C}& 8  \\
 \value{doubleComplex}& Double Complex  &\value{M}& 16 \\
 %logical & 1 \\
 %bit & * \\
 %byte & 1\\
 %short & 2 \\
 %int & 4 \\
 %long & 8 \\
 %char & 1 \\
 %unicodeChar & 2 \\
 %float & 4 \\
 %double & 8 \\
 %floatComplex & 8 \\
 %doubleComplex & 16 \\
\hline\end{tabular}\end{center}
\ifhtx\par\else\caption{Definition of Primitives}\end{table}\fi


The ordered list of Fields at the top of the table thus provides a
template for a Row object, (also called a {\it record}). The
template allows interpretation of the data in the Row. In VOTable,
there is no advance specification of the number of rows in the table:
this is to allow streaming of large tables, as discussed above. The
record is a set of Cells, with the number of Cells the same for each
Row, and the same as the number of Fields defined in the Metadata.

\subsection{Primitives}

Each Cell is composed from Primitives, each of which is a datatype
of fixed-length binary representation, as enumerated in the
accompanying table. Cells may consist of a single Primitive (this is
the default); or a multidimensional array of Primitives (see next
section).

Except for the Bit type, each primitive has the fixed length in
bytes given in the table. Bit scalars and arrays are stored in
the minimum number of bytes feasible (so that $b$ bits take the integer
part of $(b+7)/8$ bytes). It is this fixed size that allows efficiency
in storage, so that the memory used is minimized. These primitives
are described in more detail in \Aref{sec:datatypes}{section 7}.

In VOTable, characters are Primitives, either one byte for an
ASCII character or two bytes for a Unicode character. Strings can be
represented as a fixed or variable length array of characters. We can
represent a 1D array of strings as a 2D array of characters, but
given the logic above, the Cell can contain a variable-length array
of fixed-length strings (but not a fixed-length array of
variable-length strings).

\subsection{Multidimensional Arrays}

A table cell can contain an array of a given primitive type. The
array is specified by a sequence of dimensions, with the first
dimension changing fastest, and the last dimension that may be variable
in length. For example, a table cell may contain a set of up to 10 images,
each 64x64 bytes:

\elemdef{FIELD}{ \attrval{ID}{thumbs} \attrval{datatype}{unsignedByte} 
  \attrval{arraysize}{64x64x10*}\slash}

The string in the \attr{arraysize} attribute expressed these
dimensions, each integer separated by the {\tt x} character,
except the last. The last (slowest-varying) subscript of a
multidimensional array may have variable length, meaning that the
dimensionality of the final subscript may be different for different
rows of the table. In this case, there may be just an asterisk, in
which case the array may be arbitarily large; or a number followed by
an asterisk, meaning that this subscript is guaranteed not to exceed
this value.

Variable-length arrays are more efficient in storage and data
transfer, but less efficient computationally, because extra pointer
dereferencing is required to access the data. The reason that only
the slowest-varying subscript can be variable is effectively a demand
that the data provider pack the data into a small number of
fixed-size containers as much as is possible, rather than a large
number of small containers.

\subsection{FITS Binary Tables}

VOTable is closely compatible with the FITS Binary Table format.
Henceforth, we shall abbreviate ``FITS Binary Table  and its
Conventions" simply by the word ``FITS". Given a FITS
file that represents a binary table, the header may be converted to
VOTable, with a pointer to the original file, or with the original
file included directly in VOTable. Since the original file is still
present, it is clear that no data has been lost. The {\elem{PARAM}}
element can be used to hold the FITS keyword, value,
and comment string.

We might ask two more significant questions, about how much of
the FITS header and data can be represented in VOTable. The answer is
that there is considerable overlap. 

\subsubsection*{What can FITS do but not VOTable?}

{\fg{black}FITS has semantics for how data is to be
represented when printed, as the non-mandatory TDISP keyword: for
example F12.4 means 12 characters are to be used, and 4 decimal
places. This has been converted in VOTable as the attributes {\attr{width}}
and {\attr{precision}}
which, connected with {\bf {\attr{datatype}}},
are semantically identical. Note that error estimation and the number
of digits to print are rather different semantically.}

{\fg{black}FITS has a complex semantics (the ``Substring
Array" convention) for structuring a single string as a
collection of substrings, and VOTable does not support this. VOTable
allows fixed and variable-length strings, as well as variable-length
arrays of fixed length strings. }

\subsubsection*{What can VOTable do but not FITS?}

VOTable supports separating of data from metadata and the
streaming of tables, and other ideas from modern distributed
computing. It bridges two ways to express structured data: XML and
FITS. It tries (through UCD) to express formally what is the semantic
content of a parameter or field. It has the hierarchy and flexibility
of XML. FITS does not handle Unicode (extended alphabet) characters.

{\fg{black}It should be noticed that the transformation
of FITS to VOTable is meant to be reversible: the conversion of a
FITS file into VOTable does not lose any information, and a
transformation back into FITS is possible. It will however not be
possible to transform any VOTable into a FITS file without losing
some information.}

\section{Document Structure}

The VOTable document consists of a single all-containing element
called {\elem{VOTABLE}},
which may contain a {\elem{DESCRIPTION}},
a {\elem{DEFINITIONS}} element, 
a number of {\elem{INFO}} elements,
and one or more {\elem{RESOURCE}} elements.
Resource elements can contain child Resources, and they can also contain 
Tables (\elem{TABLE}) and Parameters (\elem{PARAM}).


\subsection{DEFINITIONS element}

This element may contain a definition of a coordinate system,
stored in a {\elem{COOSYS}}
element: there are attributes for equinox and epoch, as well as a
specification of  the coordinate system. We expect that future
versions of VOTable may have a more formal structuring of the
coordinate system definition which is currently extracted from
Astrores. There may also be one or more {\elem{PARAM}}
elements that may contain user-specific data. Each of these may have
an \attr{ID} attribute, that can be referenced with the \attr{ref} attribute 
of a \elem{FIELD}. Thus we can achieve grouping of fields (by having members of
the group reference the same {\elem{PARAM}} or {\elem{COOSYS}} element). We
can also extend the definition of a field by adding user-specific
data.

\subsection{RESOURCE element}

There may be multiple {\elem{RESOURCE}}
elements, and each of these may contain a {\elem{DESCRIPTION}}, 
{\elem{INFO}}, {\elem{COOSYS}} and {\elem{PARAM}} elements.
There may be {\elem{LINK}}
elements to provide URL-type pointers that give further information.

%\section{5 Parameters and Hierarchy}


%The VOTable document is a hierarchy of {\elem{RESOURCE}}
%elements, each of which can contain other {\elem{RESOURCE}}s.
%The root of the tree is the single {\elem{VOTABLE}}
%element that constitutes the entire XML document, and the leaves of
%the tree are {\elem{TABLE}}s.
%The resource elements may also contain parameters ({\elem{PARAM}}).

The {\elem{RESOURCE}} may also contain contain other {\elem{RESOURCE}}s:
the following is a complete VOTable which contains no tables, only
a hierarchy of parameters.

\begin{verbatim}
<?xml version="1.0"?>
<!DOCTYPE VOTABLE SYSTEM "http://us-vo.org/xml/VOTable.dtd">
<VOTABLE version="1.0">
  <RESOURCE ID="Stars">
    <PARAM ID="Mass" datatype="float" unit="solMass" value="1"/>
    <RESOURCE ID="BigStars">
      <PARAM ID="Mass-big" datatype="float" unit="solMass" value="10"/>
    </RESOURCE>
    <RESOURCE ID="SmallStars">
      <PARAM ID="Mass-small" datatype="float" unit="solMass" value="0.2"/>
      <RESOURCE ID="VerySmallStars">
        <PARAM ID="Mass-tiny" datatype="float" unit="solMass" value="0.05"/>
      </RESOURCE>
    </RESOURCE>
  </RESOURCE>
</VOTABLE>
\end{verbatim}

The main ingredient of the {\elem{RESOURCE}}
element is one or more {\elem{TABLE}}s.
These are described in \Aref{sec:table}{section 5} of this document.

\section{XML}

VOTable is constructed with XML (extensible Markup Language), a
powerful standard for structured data throughout the Internet
industries. It derives %through simplification 
from SGML, %which has been 
a standard used in the publishing industry and for 
technical documentation for many years. XML
consists of {\it elements} and payload, where an element consists of
a {\it start tag} (the part in angle brackets), the payload, and an
{\it end tag} (with angle brackets and a slash). Elements can
contain other elements. Elements can also bear
{\attr{attributes}}
(keyword-value combinations), such as the {\elem{PARAM}}
elements above. 


The payload may be in two forms: parsed or unparsed character
data. Examples are:

\begin{verbatim}
<text>Fran&#231;ois</text>
<text><![CDATA[ a <= (b & c) ]]></text>
\end{verbatim}

In the first example, the sequence {\tt \&\#231;} is interpreted as
part of the ISO/IEC 10646 character set, and translates to an
accented character, so that the text is ``Fran\c{c}ois".
The second example uses the special {\tt CDATA} sequence so that the
characters {\tt <}, {\tt >}, and {\tt\&} can be used without interpretation;
in this case, any ASCII characters are allowed except the terminating
sequence {\tt]]>} For more information, see any book on
XML.

\subsection{Lists}

Within a table cell, multiple Primitives can be formatted by
separating them by whitespace, to express
compound primitives (complex numbers) and multidimensional arrays.
Text tokens are separated by contiguous whitespace (ASCII space {\tt{0x20}},
tab {\tt{0x9}}, carriage-return {\tt{0xD}}, newline {\tt{0xA}},
vertical tab {\tt{0xB}}).
There are no null tokens, comments, quote characters, or separators.
However, it is possible to include special characters through an
escape mechanism as in HTML: for example the string {\tt New York}
would be encoded as {\tt New\&nbsp;York}. 

Thus a table cell that contains an array of three complex numbers
could be represented as:

\begin{verbatim}
<TD>1.0 0.0   -0.5 0.866   -0.5 -0.866</TD>
\end{verbatim}

However, it should be noted that in a character array (a string) no
space is needed to separate each element (a character).

\subsection{Syntax policy}

Following the general XML rule, element and attribute names are
case-sensitive and have to be used with the specified 
capitalisation. For VOTable, we have adopted the convention that
element names should be in uppercase
and attribute names in lowercase (with an
exception for the {\attr{ID}}
attribute). Element and attribute names are further distinguished in
this paper by being in {{\tt fixed-width}} font.

\subsection{ID and name}

The {\elem{FIELD}} and {\elem{PARAM}} elements provide both {\attr{ID}}
and {\attr{name}}
attributes: the ID is meant as a formal naming of the objects in the
VOTable document, while the name is meant for presentation purposes, and 
defaults to the same as the \elem{ID} value if not present.
The ID's of the fields and parameters must be unique throughout the
document -- this is part of the XML specification, and we intend that
eventually ID's can be used to tie together data sources and
applications that read and write them. The name of an object, when
not present, defaults to the ID value, and when it is present is
intended for presentation to humans.

Currently, however, the {\attr{ID}} attribute (as defined by Xpointer
standard) is used in order to refer to other elements in the
document. According to the XML standard, the attribute {\attr{ID}}
is a string beginning with a letter or underscore ({\tt{\_}}),
followed by a sequence of letters, digits, or any of {\tt{.-\_:}},
and each ID {\it must be unique} in the XML document. For example
{\attrval{ref}{apple}}
refers to the element that contains {\attrval{ID}{apple}}
in the current XML document. The {\attr{ID}} attribute is required
for the elements which have to be referenced, but in principle any element 
may have an {\attr{ID}} attribute.
Elements that support the {\attr{ref}}
attribute (and can point to those with ID) are: {\elem{FIELD}},
{\elem{PARAM}}, and {\elem{TABLE}}.

The {\attr{ID}} is different from the {\attr{name}}
attribute in that (a) the ID attribute is made from a restricted character
set, and must be unique (or else the
document is considered invalid in the XML sense), whereas names are
standard XML attributes and need not be unique; 
and (b) there should be support in the parsing
software to look up references and extract the relevant element with
matching ID. 


\subsection{Xlink and STREAM}

The \elem{STREAM} element is used to point to remote table data, and as
such it closely follows the W3C specification called ``Xlink".
The {\elem{STREAM}}
implements the interface defined by Xlink; in particular it is an
Xlink with {\attrval{type}{locator}}.
However, {\elem{STREAM}}
has more attributes than Xlink allows for: a {\attr{rights}}
attribute for authentication information; and {\attr{expires}}
attribute for when the link may cease to be valid; and an {\attr{encoding}}
attribute if the data is filtered, (for example compression or
binary-to-ascii filtering). Therefore we will wait until a future
release to formalize the relationship between Xlink and {\elem{STREAM}}.


\subsection{Location of the DTD}

A VOTable document, like all XML documents, should be {\it well-formed}, meaning
that it obeys the syntax rules of XML: for example, elements should start and
end properly and be properly nested. The document may be further constrained to
be {\it valid}, meaning that it follows the VOTable syntax rules, as defined in
the DTD of \Aref{dtd}: for example the data type ``float" is valid, but not the
datatype ``real". Access to the DTD is necessary to check validity. Valid XML
documents may employ certain advanced features of XML, features that can
significantly improve the usability of a document, including: linking
mechanisms, entities and attributes. Valid XML documents offer much more to the
document process than those that may be simply well-formed. Document authoring,
processing, storage and display are made easier because documents exist in a
structured environment. Authors create documents against a pre-defined structure
and benefit from a clear document model.

There are three ways to give the document access to its DTD structure: by
embedding the DTD directly into the XML file, or by referencing a local file, or
by referencing a remote file. We should point out that many parsers will simply
stop if the DTD reference cannot be resolved, rather than falling back to a
non-validated document. Any XML book will explain the syntax of these options.

\begin {itemize}

\item Embedding the DTD means that the document is longer, since it includes
all the text of the DTD (\Aref{dtd}{below}). 
It also means that the document is more
portable, since it does not rely on external references that may not be
available. However, the receiver of such a document does not know that it is a
proper VOTable, since the DTD may be different from the official version. 

\item If the DTD is a local file, it means that the document processing still
works even when the machine is disconnected from the internet. However, when the
XML file is moved to a new directory or sent by email, the DTD must move with
it.

\item Referencing a DTD at a standard place on the internet makes the XML
document portable, and files can be moved at will. However, the document
processing will fail when not connected to the internet. We expect the VOTable
DTD to be mirrored at several sites, including:

\begin{tabular}{l}
{\bf\fg{DarkRed}\Plain{http://us-vo.org/xml/VOTable.dtd}}\\
{\bf\fg{DarkRed}\Plain{http://cdsweb.u-strasbg.fr/xml/VOTable.dtd}}\\
\end{tabular}
\end{itemize}


\section{Table}
\label{sec:table}

The Table element is written in XML as a  {\elem{DESCRIPTION}}
and {\elem{LINK}} elements, together with a collection of 
{\elem{FIELD}} elements that describe the nature of the table columns.
Finally, the data of the Table may be specified with a \elem{DATA} element.

A {\elem{FIELD}} element may have several sub-elements, 
including the informational {\elem{DESCRIPTION}},
and {\elem{LINK}}, as well as {\elem{VALUES}},
that can express limits and ranges of the values that the
corresponding cell can contain, such as minimum, maximum, or
enumeration of possible values. 

The {\elem{FIELD}} must contain a {\attr{datatype}}
attribute, which expresses the nature of the data that is in the
cells of this column of the table.  This attribute determines how data is read
and stored internally, and is mandatory.

Each table cell may contain more than one of the specified
datatype, and this is specified with {{the
\attr{arraysize} attribute}}, as explained above, inducing a
multidimensional array structure on those table cells. 


Strings are not a primitive type: characters are.~ To
simulate variable length strings users can use variable length arrays
of characters, for example:

\begin{verbatim}
<FIELD ID="unboundedString" datatype="char" arraysize="*"/>
\end{verbatim}

VOTables support two kinds of characters: ASCII 1-byte characters
and Unicode 2 byte characters. Unicode is a way to represent
characters that is an alternative to ASCII. It uses two bytes per
character instead of one, it is strongly supported by XML tools, and
it can handle a large variety of international alphabets. Therefore
VOTable supports not only ASCII strings ({\attrval{datatype}{char}}),
but also Unicode ({\attrval{datatype}{unicodeChar}}).

For details of the exact meaning of all valid datatypes, please see
\Aref{sec:datatypes}{section 7}.

If the data is written as {\elem{TABLEDATA}},
and a table cell contains an array or complex number, then it should
be encoded as multiple numbers separated by white space.

A {\elem{FIELD}} may also specify a \attr{null} attribute 
through a {\elem{VALUES}}
element. For example: {\attrval{null}{-99}}.
When this value is found in the corresponding data, it is assumed that no data
exists for that table cell; the parser may choose to use this also
when unparsable data is found, and the null value will be substituted
instead.
\iftrue	% Added FO 2002-03-21
The default representation of a ``null'' value is an empty column
in the \elem{TABLEDATA} representation (i.e. \verb+<TD></TD>+).
For \elem{FITS} and \elem{BINARY} data, the {\em NaN} (not-a-number)
patterns are recommended to represent floating-point ``null'' values.
The ``null'' convention is therefore only necessary for primitive types
that do not have a natural ``null'' value, such as int, short, byte, etc.
\fi

\subsection{Numerical Accuracy}

The VOTable format is meant for transferring, storing, and
processing tabular data, it is not intended for presentation
purposes. Therefore (in contrast with Astrores) we generally avoid
giving rules on presentation, such as formatting. However, we retain
the {\attr{width}} attribute of the {\elem{FIELD}},
which is meant as a hint to the
presentation system about the number of characters to use for input
or output of the quantity. Inevitably some at least of the data will
have to be presented -- either as actual tables, or in graphs, etc...
In any case, some estimation of the accuracy has to be known.

But there is a semantic difference between a number written as
\value{5.12} and one that is written \value{5.1200}, in that
the former implies three significant digits of accuracy, and the
latter five digits. Therefore the number of digits to show is not
purely a presentation matter, but part of the metadata content of the
number.

VOTable therefore provides the {\attr{precision}}
attribute in the {\elem{FIELD}}
element to express the number of significant digits, or equivalently,
the log of the implied error estimate of the numbers in the column.
More control is available through an initial character: setting this
to {\value{E}}
rather than the default {\value{F}}
implies that the {\attr{precision}}
measures the relative error (significant figures) rather than its
absolute error (decimal places). Thus {\attrval{precision}{E5}}
 means an implied relative error $10^{-5}$ (5 significant digits), 
 and {\attrval{precision}{5}}
 or {\value{F5}} means an implied absolute error $10^{-5}$
 (5 digits following the decimal point).

\subsection{Units}

The quantities in a column of the table may have physical units,
and this is specified by the {\attr{units}}
attribute of the {\elem{FIELD}}.
Examples are:

\begin{verbatim}
      units="cm-2.s-1.keV-1"
      units="erg.s-1"
\end{verbatim}

The syntax of this string is defined in reference [3].

\subsection{Unified Content Descriptors}

The CDS in Strasbourg has used the metadata from thousands of
astronomical tables to make a hierarchical glossary of the scientific
meanings of the data in those tables [4]. Of 1600 entries in the
glossary, here are a few typical examples.

\begin{tabular}{ll}
{\value{PHOT\_INT-MAG\_B}}     &  Integrated total blue magnitude \\
{\value{ORBIT\_ECCENTRICITY}}  &  Orbital eccentricity \\
{\value{STAT\_MEDIAN}}         &  Statistics Median Value \\
{\value{INST\_QE}}             &  Detector's Quantum Efficiency \\
\end{tabular}

\noindent The {\attr{ucd}} attribute of the {\elem{FIELD}} element
is to hold this information.

\subsection{VALUES element}

The {\elem{VALUES}}
element of the {\elem{FIELD}}
is designed to hold subsidiary information about the nature of the
data in the field. It may have {\elem{MIN}}
and {\elem{MAX}}
elements, and it may contain {\elem{OPTION}}
elements. The latter contains name and value attributes, and may also
contain more {\elem{OPTION}}
elements, so that a hierarchy of keyword-values pairs may be
associated with each field.

There may also be a {\attr{null}}
attribute, as discussed above. If this is present in a table cell, it
is assumed to mean that no data is present. 

\subsection{LINK Elements}
\label{sec:link}

The {\elem{LINK}} element is to provide pointers to other documents 
or data servers on the Internet through a URL. In VOTable, the {\elem{LINK}}
element may be part of the {\elem{RESOURCE}},
{\elem{TABLE}} or {\elem{FIELD}} elements. The {\attr{href}}
attribute of the {\elem{LINK}}
is meant to provide a URL that is at least valid syntactically, even
though there need be no assurance that the link will actually connect
and deliver data. It may be that a strange protocol is implied that
the parser does not know about, for example {\value{httpg://server/file}}.
However, parsers are expected to understand at least the {\value{file}},
{\value{http}} and {\value{ftp}} protocols.

The {\attr{gref}}
attribute is meant for a higher-level protocol of some type, perhaps
a logical name for a data resource, perhaps a GLU reference [5].

In the Astrores format, from which VOTable is derived, 
there is additional semantics for the {\elem{LINK}}
element; the \elem{href} attribute is used as a template for creating
URL's. This behavior is explained in \Aref{LINK}{Appendix}, and it represents
a further proposal, a possible extension of VOTable.


\section{Data Content}

While the bulk of the metadata of a VOTable document is in the
{\elem{FIELD}} elements, the data content of the table is in a single {\elem{DATA}}
element. The data is organized in ``reading" order, so that
the content of each row appears in the same order as the order of the
{\elem{FIELD}} tags, with each row having the same number of items as there are
{\elem{FIELD}} tags. 


\label{Image1}
\ifhtx\tag{IMG SRC="serial.gif" NAME="Image1" ALIGN=BOTTOM BORDER=0}\else
\begin{figure}
\includegraphics[width=\textwidth]{serial.jpg}
\caption{Data serialization}
\end{figure}
\fi

The data section of the VOTable document is created through a data
pipeline. The abstract table is first serialized by one of several
methods, then it may be Encoded for compression or other reasons. The
result may be embedded in the XML file ({\it local} data), or it may
be {\it remote} data.

The figure shows how the abstract table is rendered into the
VOTable document. First the data is {\it serialized}, either
as XML, a FITS binary table, or tyhe VOTable
Binary format. This data stream may then be {\it encoded},
perhaps for compression or to convert binary to text. Finally, the
data stream may be put in a remote file with a URL-type pointer in
the VOTable document; or the table data may be embedded in the
VOTable. 

\subsection{Data Serialization}

The serialization elements and their attributes are:

\subsubsection{TABLEDATA}
\label{sec:TABLEDATA}

This element is a way to build the table in pure XML, and is the
only serialization method that does not allow an encoding or a remote
data stream. It contains {\elem{TR}}
elements, which in turn contain {\elem{TD}}
elements. An example:

\begin{verbatim}
<TABLEDATA>
  <TR>
    <TD>Procyon</TD> <TD>114.827242</TD>
    <TD>5.227506</TD>  
  </TR>
  <TR>
    <TD>Vega</TD>    <TD>279.234106</TD>
    <TD>38.782992</TD> 
  </TR>
</TABLEDATA>
\end{verbatim}

The number of {\elem{TD}} elements should be in number equal to the
number of {\elem{FIELD}} elements declaring the table; when there are
less {\elem{TD}}'s than expected, the corresponding values are set
to \value{null}s; superfluous {\elem{TD}}'s are ignored.

While this serialization has a high overhead in the number of
bytes, it has the advantage that XML tools can manipulate and present
the table data directly.

Each item in the {\elem{TD}}
tag is passed to a reader that is implicitly defined by the {\attr{datatype}}
attribute of the corresponding {\elem{FIELD}},
which attempts to read the object from it. If it reads a value that
is the same as the {\elem{NULL}}
value for that field, then the cell will contain that value, and is
therefore assumed to contain no data.

The reader may not succeed, for example if we try to parse the
string \value{36.9H9}
into a float, where the alphabetic character is obviously a problem. 
In this case, the parser may choose to insert the {\attr{null}}
value (no data available), or it may use a NaN (not a number), or it
may throw an exception. It might however be
useful if the data provider would warn that invalid data patterns
could be used to designate non-existing data -- via an \attr{invalid}
attribute.

If a cell contains an array or complex number, 
it should be encoded as multiple numbers separated by
whitespace. However in the case of character and Unicode strings, no
separators are required. Here is an example of a table with a single
row, that has arrays in the table cells:

\label{example2}
\begin{verbatim}
<TABLE>
  <FIELD ID="aString" datatype="char" arraysize="10"/>
  <FIELD ID="Floats" datatype="float" arraysize="3"/>
  <FIELD ID="varComplex" datatype="floatComplex" arraysize="*"/>
  <DATA><TABLEDATA>
  <TR>
   <TD>Apple</TD><TD>1.62 4.56 3.44</TD>
   <TD>67 1.57  4 3.14  77 -1.57</TD>
  </TR><TR>
   <TD>Orange</TD><TD>2.33 4.66 9.53</TD>
   <TD>39 0  46 3.14</TD>
  </TR>
  </TABLEDATA></DATA>
</TABLE>
\end{verbatim}

The first entry is a fixed-length array of 10 characters; since
the value being presented ({\tt Apple}) has 5 characters, this
is padded with trailing blanks. The second cell is an
array of three floats.
The last cell contains a variable array of complex numbers, each complex
number being represented by its real part followed by at least a blank
and its imaginary part -- hence 6 numbers for 3 complex numbers,
or 4 numbers for 2 complex numbers.

\subsubsection{FITS}

The FITS format for binary tables is well-used in astronomy [2],
and its structure is a major influence on the VOTable specification.
Metadata is stored in a header section, followed by the data. The
metadata is substantially equivalent to the metadata of the VOTable
format. One important difference is that VOTable does not require
specification of the number of rows in the table, an important
freedom if the table is being created dynamically from a stream.

The VOTable specification does not define the behavior of parsers
with respect to this doubling of the metadata. A parser may ignore
the FITS metadata, or it may compare it with the VOTable metadata for
consistency, or other possibilities.

The following code shows a fragment that might have been created
by a FITS-to-VOTable converter. Each FITS keyword has been converted
to a \elem{PARAM}, and the data itself is remotely stored and gzipped at an
ftp site:

\begin{plain}
\elemdef{RESOURCE}{}\\
\hspace*{0.5em}\elemdef{PARAM}{ \attrval{name}{EPOCH} \attrval{datatype}{float} 
        \attrval{value}{1999.987}}
        Original Epoch of the coordinates
\hspace*{0.5em}\elemdef{\slash PARAM}{} \\
\hspace*{0.5em}\elemdef{PARAM}{ \attrval{name}{TELESCOP} \attrval{datatype}{char} 
   \attrval{arraysize}{*} \attrval{value}{VTel} \slash}\\
\hspace*{0.5em}\elemdef{INFO}{ \attrval{name}{HISTORY}}
  The very first Virtual Telescope observation made in 2002 \\
\hspace*{0.5em}\elemdef{\slash INFO}{} \\
\hspace*{0.5em}\elemdef{TABLE}{}
\hspace*{0.5em}\elemdef{FIELD}{\quad(insert field metadata here) }\\
\hspace*{0.5em}\elemdef{DATA}{}\elemdef{FITS}{ \attrval{extnum}{2}}\\
\hspace*{1em}\elemdef{STREAM}{ %Not for REMOTE data !! \attrval{encoding}{gzip} 
           \attrval{href}{ftp://archive.cacr.caltech.edu/myfile.fit.gz}\slash}\\
\hspace*{1.0em}\elemdef{\slash FITS}{}\elemdef{\slash DATA}{} \\
\hspace*{0.5em}\elemdef{\slash TABLE}{}\\
\elemdef{\slash RESOURCE}{}
\end{plain}

The FITS file may contain many data objects (known as extensions, 
numbered from 1 up -- the main header being numbered 0), and the
\attr{extnum} attribute allows the VOTable to point to one of
those.


\subsubsection{BINARY}

The Binary format is intended to be easy to read by parsers, so
that additional libraries are not required. It is just a sequence of
byte strings, the length of each string corresponding to the {\attr{datatype}}
and {\attr{arraysize}} attributes of the {\elem{FIELD}}
elements in the metadata. The binary format consists of a sequence of
records, with no header bytes, no alignment considerations, no block sizes.

Table cells may contain arrays of primitive types, each of which
may be of fixed or variable length. In the former case, the number of
bytes is the same for each instance of the item, as specified by the
{\attr{arraysize}}
attribute of the {\elem{FIELD}}.
If all the fields have a fixed {\attr{arraysize}},
then each record of the binary format has the same length, as the sum
of {\attr{arraysize}}
times the length in bytes of the corresponding {\attr{datatype}}.


In the case of variable-length arrays of primitives, however, the
Binary format becomes more complex. Each record has first a part for
the fixed-length fields, (as well as four bytes for each of the
variable-length fields), followed by a section for the variable
length fields. The four bytes for the variable-length field is
interpreted as a four-byte integer with
the number of items in
the variable-length array, as shown in the figure. The parser can
then read the data by computing appropriate offsets. This is done by
multiplying the size and number of the primitives in each table cell
to get length in bytes, then
adding these lengths from previous
variable-length sections of the record.

\label{Image2}
\ifhtx\begin{TABULAR}{c}
\tag{IMG SRC="binary.gif" NAME="Image2" ALIGN=LEFT BORDER=0}\end{TABULAR}
\else\begin{center}
\begin{figure}
\includegraphics[width=0.8\textwidth]{binary}
\caption{Data Storage in BINARY mode}
\end{figure}\end{center}

\par The figure shows the byte layout for this binary format for the same data
as the example in \Aref{sec:TABLEDATA}{section 6.1.1}.
Each record has a ten-byte character
array, followed by an array of three four-byte floats, and then a variable
number of complex numbers. The number of elements of these variable arrays 
are stored (3 and 2 in the two records shown), followed by the corresponding 
data (made of 24 and 16 bytes).
\fi


\subsection{Data Encoding}

As a result of the serialization, the table has been converted to
a byte stream, either text or binary. If the {\elem{TABLEDATA}}
serialization is used, then those elements are directly in the XML
document, and conventional tools can be used to encode the entire XML document.
However, VOTable also provides limited encoding of its own. 
A VOTable document may point to a remote data resource that is compressed; 
rather than decompressing before sending on the wire, it can be dynamically
decoded by the VOTable reader. We might also use the encoding facilities to 
convert a binary file to text (through base64 encoding), so that binary 
data can be used in the XML document.

In this version of VOTable, it is not possible to encode
individual columns of the table: the whole table must be encoded in
the same way.

In order to use an encoding of the data, it must be enclosed in a
{\elem{STREAM}}
element, whose attributes define the nature of the encoding. The
{\attr{encoding}}
attribute is a string that should indicate to the parser how to undo
the encoding that has been applied. Parsers should understand and
interpret these values at least:
\begin{itemize}
        \item {\attrval{encoding}{gzip}}
        implies that the data following has been compressed with the gzip
        filter, so that gunzip or similar should be applied.
        \item {\attrval{encoding}{base64}}
        implies that the base64 filter has been applied, to convert binary
        to text.
\end{itemize}

The parser may also respond to the string {\value{dynamic}},
implying that the data is in a remote resource (see below), and the
encoding will be delivered with the header of the data. This occurs
with the http protocol, where the MIME header indicates the type of
encoding that has been used. The default value of the encoding
attribute is the null string, meaning that no encoding has been
applied. In future releases, we will allow more complex strings in
the encoding attribute, allowing combinations of encoding filters and
a way for the parser to find the software needed for the decoding.

\subsection{Remote Data}

If the encoding of the data produces text, or if the serialization
is naturally text-based, then it can be directly embedded into the
XML document. However, if the data encoding produces binary, or if
the data is very large, it may be preferable to keep the data
separate from the metadata. The text contained in the {\elem{STREAM}}
element is then interpreted as the location of the data, rather than
the data itself. The location is specified in a URL-type syntax, for
example:

\begin{plain}
\elemdef{STREAM}{ \attrval{href}{ftp://server.com/mydata.dat}\slash}

\par\elemdef{STREAM}{ \attrval{href}{ftp://server.com/mydata.dat}
        \attrval{expires}{2002-02-22}\slash}

\par\elemdef{STREAM}{ \attrval{href}{httpg://server.com/mydata.dat} 
        \attrval{actuate}{onLoad}\slash}

\par\elemdef{STREAM}{ \attrval{file}{file:///usr/home/me/mydata.dat}\slash}
\end{plain}


The examples are the well-known anonymous ftp, and http protocols.
Also is an example of a Grid-based access to data through httpg, 
and finally a reference to a local file.

There are further attributes of the {\elem{STREAM}}
element that may be useful. The {\attr{expires}}
tag is for when the VOTable is part of a pipeline of data processing,
when data is being dynamically created and stored in temporary space,
in which case it may be deleted after a certain time limit. The
{\attr{expires}}
attribute expresses when a remote resource may cease to become valid,
and is expressed in Universal Time in the same way as the FITS
specification [2], itself conforming to ISO 8601 standard, for example:

\begin{verbatim}
<STREAM expires="2002-01-31T12:00:00">
\end{verbatim}

The {\attr{rights}}
attribute expresses authentication information that may be necessary
to access the remote resource. If  the VOTable document is suitably
encrypted, this attribute could be used to store a password.

The {\attr{actuate}}
attribute is borrowed from the XML Xlink specification, expressing
when the remote link should be actuated. The default is {\value{onRequest}},
meaning that the data is only fetched when explicitly requested (like
a link on an HTML page), and the {\value{onLoad}}
value means that data should be fetched as soon as possible (like an
embedded image on an HTML page).

\section{Definitions of Primitive Datatypes}
\label{sec:datatypes}

\begin{itemize}
\item {\bf Logical}\quad If the value of the {\attr{datatype}}
attribute specifies data type {\value{boolean}},
the contents of the field{ }shall consist of
ASCII \value{T}, \value{t},  or \value{1} indicating true or 
ASCII \value{F}, \value{f}, or \value{0} indicating false. 
The ``null'' value is indicated by a space (hexadecimal 20)
or a question mark \value{?} (hexadecimal 3F).
%The  0 byte (hexadecimal 00) indicating an invalid value.

\item {\bf Bit Array} \quad If the value of the {\attr{datatype}}
attribute specifies data type {\value{bit}},
the contents of the field{ }shall consist of
a sequence of bits starting with the most significant bit; the bits
following shall be in order of decreasing significance, ending with
the least significant bit. A bit field shall be composed of the
smallest number of bytes that can accommodate the number of elements
in the field. Padding bits shall be 0.

\item {\bf Byte}\quad If the value of the {\attr{datatype}}
attribute specifies data type {\value{unsignedByte}},
the field shall contain a sequence of zero or more members, composed
of unsigned bytes. The most significant byte shall be first. Within
each byte the most significant bit shall be first, and subsequent
bits shall be in order of decreasing significance. An array of bytes
is also known as a ``blob", and can be used for storing
general byte data.

\item {\bf Character}\quad if the value of the {\attr{datatype}}
attribute specifies data type {\value{char}},
the field shall contain a character string of zero or more members,
composed of ASCII text. This character string may be terminated
before the length specified by the repeat count by an ASCII NULL
(hexadecimal code 00). Characters after the first ASCII NULL are not
defined. A string with the number of characters specified by the
repeat count is not NULL terminated. Null strings are defined by the
presence of an ASCII NULL as the first character.

\item {\bf Unicode Character}\quad If the value of the {\attr{datatype}}
attribute specifies data type {\value{unicodeChar}},
the field shall contain a character string of zero or more members,
composed of Unicode text. Each character is represented by two bytes,
in order that many non-Latin alphabets can be represented.

\item {\bf 16-Bit Integer}\quad If the value of the {\attr{datatype}}
attribute specifies datatype {\value{short}}, the data in the field shall consist of
twos-complement signed 16-bit integers, contained in two bytes. The
most significant byte shall be first. Within each byte the most
significant bit shall be first, and subsequent bits shall be in order
of decreasing significance. 


\item {\bf 32-Bit Integer }\quad If the value of the {\attr{datatype}}
attribute specifies datatype {\value{int}},
the data in the field shall consist of twos-complement signed 32-bit
integers, contained in four bytes. The most significant byte shall be
first, and subsequent bytes shall be in order of decreasing
significance. Within each byte, the most significant bit shall be
first, and subsequent bits shall be in order of decreasing
significance. 


\item {\bf 64-Bit Integer}\quad If the value of the {\attr{datatype}}
attribute specifies datatype {\value{long}},
the data in the field shall consist of twos-complement signed 64-bit
integers, contained in eight bytes. The most significant byte shall
be first, and subsequent bytes shall be in order of decreasing
significance. Within each byte, the most significant bit shall be
first, and subsequent bits shall be in order of decreasing
significance. 


\item {\bf Single Precision Floating Point}\quad If
the value of the {\attr{datatype}} attribute specifies datatype {\value{float}},
the data in field shall consist of ANSI/IEEE-754 32-bit floating
point numbers. All IEEE special values are recognized. The IEEE {NaN}
pattern is used to represent ``null" values.

\item {\bf Double Precision Floating Point}\quad If
the value of the {\attr{datatype}}
attribute specifies datatype {\value{double}},
the data in the field shall consist of ANSI/IEEE-754
64-bit double precision floating point numbers. All IEEE special
values are recognized. The IEEE {NaN}
pattern is used to represent ``null" values.

\item {\bf Single Precision Complex}\quad If the value of the {\attr{datatype}}
attribute specifies datatype {\value{floatComplex}},
the data in the field shall consist of a sequence of pairs of 32-bit
single precision floating point numbers. The first member of each
pair shall represent the real part of a complex number, and the
second member shall represent the imaginary part of that complex
number. If either member contains a {NaN},
the entire complex value is ``null".

\item {\bf Double Precision Complex}\quad If the
value of the {\attr{datatype}}
attribute specifies datatype {\value{doubleComplex}},
the data in the field{ }shall consist of a
sequence of pairs of 64-bit double precision floating point numbers.
The first member of each pair shall represent the real part of a
complex number, and the second member of the pair shall represent the
imaginary part of that complex number. If either member contains a
{NaN}, the entire complex
value is ``null".
\end{itemize}


\section{Sample VOTable Document}
\label{sec:sample}

\ifhtx\Beg{TABULAR}{\bg{LightCyan} CELLPADDING=4}{||l||}
\else\footnotesize\fi
\begin{verbatim}
<!DOCTYPE VOTABLE SYSTEM "http://us-vo.org/xml/VOTable.dtd">
<VOTABLE version="1.0" xmlns="http://vizier.u-strasbg.fr/VOTable">
  <DESCRIPTION>This is an example VOTable document</DESCRIPTION>
  <DEFINITIONS>
    <COOSYS ID="myJ2000" equinox="2000." epoch="2000" system="eq_FK5"/>
  </DEFINITIONS>
  <RESOURCE name="GSC1.2">
    <DESCRIPTION>
     This is an excerpt of the HST Guide Star Catalog, Version 1.2 (Lasker+ 1996).  
     This version was re-reduced with PPM catalogue.
    </DESCRIPTION>
    <TABLE>
      <DESCRIPTION>   Default result of GSC1.2 Server around a target</DESCRIPTION>
      <FIELD ID="_r" name="_r" ucd="POS_ANG_DIST" unit="arcmin" 
          datatype="float" width="7" precision="4">
        <DESCRIPTION>Distance from target NGC40</DESCRIPTION>
        <VALUES type="actual">
          <MIN value="0.0"/>
          <MAX value="10.0"/>
        </VALUES>
      </FIELD>
      <FIELD ID="gsc" name="GSC-Id" datatype="char" ucd="ID_MAIN" arraysize="10">
        <DESCRIPTION>The GSC-Id is made of 10 digits, 5 representing the plate number, 
             and 5 the object number on the plate.
        </DESCRIPTION>
      </FIELD>
      <FIELD ID="ra" name="RA(J2000)" ref="myJ2000" ucd="POS_EQ_RA" 
          unit="deg" datatype="double" precision="F5">
        <DESCRIPTION>Right ascension in J2000, epoch of plate</DESCRIPTION>
      </FIELD>
      <FIELD ID="dec" name="Dec(J2000)" ref="myJ2000" ucd="POS_EQ_DE" 
          unit="deg" datatype="double" precision=" F5" >
      <DESCRIPTION>Declination in J2000, epoch of plate</DESCRIPTION>
      </FIELD>
      <FIELD ID="pos_err" name="PossErr" unit="arcsec" datatype="float" 
          precision="1" ucd="ERROR">
      <DESCRIPTION>Mean error on position</DESCRIPTION>
      </FIELD>
      <FIELD ID="mag" name="Pmag" ucd="PHOT_PHG_MAG" unit="mag" 
          datatype="float" width="5" precision="2">
      <DESCRIPTION>photographic magnitude (see n_Pmag)</DESCRIPTION>
      </FIELD>
      <FIELD ID="mag_err" name="e_Pmag" ucd="ERROR" unit="mag" 
          datatype="float" width="4" precision="2">
      <DESCRIPTION>Mean error on photographic magnitude</DESCRIPTION>
      </FIELD>
      <FIELD ID="class" name="Class" ucd="CLASS_CODE" datatype="short"  width="1" >
      <DESCRIPTION>Class of object (0=star; 3=non-stellar)</DESCRIPTION>
      <VALUES type="actual">
      <OPTION name="star" value="0"/>
      <OPTION name="galaxy" value="3"/>
      </VALUES>
      </FIELD>
      <LINK content-role="doc" title="documentation" href="http://vizier.u-strasbg.fr/viz-bin/Cat?I/254"/>
      <DATA><TABLEDATA>
<TR><TD>0.0146</TD><TD>0430201297</TD><TD>4.7766</TD><TD>72.8474</TD><TD>3.6</TD><TD>8.59 </TD>
    <TD>0.20</TD><TD>0</TD></TR>
<TR><TD>0.9704</TD><TD>0430200545</TD><TD>5.4576</TD><TD>72.6528</TD><TD>0.2</TD><TD>12.18</TD>
    <TD>0.34</TD><TD>0</TD></TR>
<TR><TD>0.9730</TD><TD>0430200545</TD><TD>3.9867</TD><TD>72.9484</TD><TD>0.2</TD><TD>12.09</TD>
    <TD>0.20</TD><TD>0</TD></TR>
<TR><TD>1.5843</TD><TD>0430202363</TD><TD>8.9587</TD><TD>72.6635</TD><TD>0.2</TD><TD>14.38</TD>
    <TD>0.34</TD><TD>0</TD></TR>
<TR><TD>2.8586</TD><TD>0430200269</TD><TD>5.4847</TD><TD>72.8272</TD><TD>0.3</TD><TD>14.96</TD>
    <TD>0.20</TD><TD>3</TD></TR>
<TR><TD>2.9198</TD><TD>0430200153</TD><TD>10.4746</TD><TD>72.4542</TD><TD>0.2</TD><TD>12.89</TD>
    <TD>0.20</TD><TD>0</TD></TR>
<TR><TD>2.9215</TD><TD>0430200153</TD><TD>6.9484</TD><TD>72.1162</TD><TD>0.2</TD><TD>13.06</TD>
    <TD>0.34</TD><TD>0</TD></TR>
<TR><TD>3.0487</TD><TD>0430202336</TD><TD>4.7586</TD><TD>72.9837</TD><TD>0.2</TD><TD>14.38</TD>
    <TD>0.34</TD><TD>0</TD></TR>
<TR><TD>3.2247</TD><TD>0430200121</TD><TD>7.9585</TD><TD>72.5565</TD><TD>0.2</TD><TD>12.39</TD>
    <TD>0.21</TD><TD>0</TD></TR>
<TR><TD>3.2269</TD><TD>0430200121</TD><TD>7.9484</TD><TD>72.5874</TD><TD>0.2</TD><TD>12.50</TD>
    <TD>0.34</TD><TD>0</TD></TR>
      </TABLEDATA></DATA>
    </TABLE>
 </RESOURCE>
</VOTABLE>
\end{verbatim}
\ifhtx\End{TABULAR}\fi
\normalsize


\section{The DTD for VOTable}
\label{dtd}


{\bf Note}: this DTD is also accessible in the 2 sites:

\begin{tabular}{l}
{\bf\fg{DarkRed}\Plain{http://us-vo.org/xml/VOTable.dtd}}\\
{\bf\fg{DarkRed}\Plain{http://cdsweb.u-strasbg.fr/xml/VOTable.dtd}}\\
\end{tabular}

\smallskip
\noindent and a draft version of a VOTable document making use of 
XML Schemas terminology [8] is included as \Aref{xsd}{an Appendix}.

%\fg{DarkBlue}
\ifhtx\Beg{TABULAR}{\bg{LavenderBlush} CELLPADDING=4}{||l||}
\inputverbatim{VOTable_v1.0.dtd}
\End{TABULAR}
\else\bigskip\thickrule\footnotesize\verbatiminput{VOTable_v1.0.dtd}\normalsize
\thickrule\fi

%\clearpage
\section{Schema Diagram for VOTable}
\ifhtx\tag{IMG SRC="diagram_v1.gif" NAME="VOTable Schema" 
   ALIGN=BOTTOM BORDER=0}\else
%\begin{figure}[htbp]
%\hspace*{-1cm}
\includegraphics[width=\textwidth]{diagram_v1.jpg}
%height=0.75\textheight
%\caption{Schema Diagram for VOTable}
%\end{figure}
\fi

\ifhtx\par\thickrule\par\else\clearpage\fi
\appendix

\noindent {\bf\LARGE Appendices}

\section{A draft XML Schema defining VOTable}
\label{xsd}

{\bf Note}: 
The XML Schema introduces more strict definitions of some patterns which
can otherwise not be specified in a DTD, like the {\attr{arraysize}}
which can only be made of digits and {\tt x}, and an optional {\tt*}
terminator. Like the DTD presented in \Aref{dtd}{section 9},  
this XML Schema is also accessible from

\begin{quote}
\begin{tabular}{l}
{\bf\fg{DarkRed}\Plain{http://us-vo.org/xml/VOTable.xsd}}\\
{\bf\fg{DarkRed}\Plain{http://cdsweb.u-strasbg.fr/xml/VOTable.xsd}}\\
\end{tabular}
\end{quote}

%\begin{tabular}{l}
%{\bf\fg{DarkRed}\Plain{http://us-vo.org/xml/VOTable.dtd}}\\
%{\bf\fg{DarkRed}\Plain{http://cdsweb.u-strasbg.fr/doc/VOTable/VOTable.dtd}}\\
%\end{tabular}

%\fg{DarkBlue}
\ifhtx\Beg{TABULAR}{\bg{honeydew1} CELLPADDING=4}{||l||}
\inputverbatim{VOTable_v1.0.xsd}
\End{TABULAR}
\else\thickrule\footnotesize\verbatiminput{VOTable_v1.0.xsd}\normalsize
\thickrule\fi

\section{VOTable LINK substitutions}
\label{LINK}

This section summarizes a part of the Astrores format which is a proposed
extension to VOTable, allowing the document to represent not just a 
table and its structure, but also a {\em request} for a table. It defines the 
behavior of a \elem{LINK} when it appears inside a \elem{TABLE}.

When a {\elem{LINK}} element appears within a {\elem{TABLE}},
there is extra functionality implied. The {\attr{href}}
or {\attr{gref}} attributes may not be a simple link, but instead 
a template for a link. For example, in the 
table of \Aref{example1}{section 1.1}, we add the link:

\begin{verbatim}
<LINK href="http://us-vo.org/lookup?Star=${Star-Name}&RA=${RA}&DE=${Dec}"/>
\end{verbatim}

The implication is that the text is seen in the context of a
particular row of the table, and a substitution filter is applied. If
the selected row of the table is the first one, the result of the
substitution would be:

\begin{verbatim}
http://us-vo.org/lookup?Star=Procyon&RA=114.827&DE=5.227
\end{verbatim}

Whenever the pattern {\tt{\$\{...\}}}
is found in the original link, the part in the braces is compared
with the set of {\attr{name}}
attributes of the fields of the table. If a match is found, then the
value from that field of the selected row is used in place of the
{\tt{\$\{...\}}}. If no match is found, no substitution is made. Thus the
parser makes available to the calling application a value of the {\attr{href}}
and {\attr{gref}}
attributes that depends on which row of the table has been selected.
Another way to think of it is that there is not a single link
associated with the table, but rather an implicitly defined new
column of the table. This mechanism can be used to connect each row
of the table to further information resources.

The {\attr{action}} attribute is related to the Query mechanism described in
the \Aref{query}{next section}.


The purpose of the link is
defined by the {\attr{content-role}}
attribute. The allowed values are {\value{query}},
{\value{hints}}, and {\value{doc}}.
The first implies that string substitution should be used as defined
above, and the latter two imply first that no substitution is needed,
and that the link points to either information for use by the
application ({\value{hints}})
or human-readable documentation ({\value{doc}}).

The {\attr{type}}
attribute of the {\elem{FIELD}}
may carry values that express the status of the field when the
enclosing table describes the components for submitting a query,
rather than a data document. If the value is {\value{noquery}},
then the marked field is ignored in the creation of the action query
-- this field does not belong to the form described by the set of
{\elem{FIELD}}s.
A computed column (value computed from other {\elem{FIELD}}s)
is a typical example of a {\elem{FIELD}} which content 
is to be ignored in the generation of a query.

If {\attrval{type}{trigger}},
then the marked field contains data necessary for correct {\elem{LINK}}
generation. If for instance only the columns "RA" and "Dec"
are asked, but a link requires the knowledge of a "RecordNumber"
to be operational, the result contains the additional column
``RecordNumber" flagged as a \value{trigger} field.

\section{VOTable Query Extension}
\label{query}

\begin{quote}
\em\fg{DarkBlue} The definitions enclosed in this section are {\bf not} part of 
VOTable. This section is a short explanation on how Astrores defines
the set of parameters and fields which can be qualified for a query --
what could be defined as the contents of a {\bf form}.
VOTable currently does not define the parameters available for a query;
such definitions are delayed to the next version of VOTable, and could
make use of the Web Services Description Language (WSDL) 
\end{quote}

\noindent In Astrores [1], the details on the input parameters available in
queries are described by the 
{\elem{PARAM}} and {\elem{FIELD}}, and the syntax used
to generate the actual query is described in the ASU [6] procotol:
the {\elem{FIELD}} elements are
paired in the form {\it name}{{\tt=}}{\it value},
where {\it name} is the contents of the
\attr{name} attribute, and  {\it value} represents a constraint
written with the ASU conventions (e.g. \value{$<8$}
 or {\value{12.0..12.5}}
which denotes a range of values). Such pairs are  appended to the
{\attr{action}} specified in the {\elem{LINK}}
element contained in the {{\elem{RESOURCE}}},
separated by the ampersand (\&) symbol --
in a way similar to the {\elem{FORM}} HTML syntax. 
{{\elem{PARAM}}} or {\elem{FIELD}}
which have the attribute {\attrval{type}{noquery}}
are however ignored, and are never paired.  A valid query  could be:

\begin{verbatim}
http://server/asu-xml?-source=I/271/out&-out.max=99&-c=01:02:03-12:31:14&Rmag=12.0..12.5
\end{verbatim}

and the corresponding VOTable document that generates it:

\ifhtx\Beg{TABULAR}{\bg{LightCyan} CELLPADDING=4}{||l||}
\else\small\fi
\begin{verbatim}
<?xml version="1.0"?>
<!DOCTYPE VOTABLE SYSTEM "http://us-vo.org/xml/VOTable.dtd">
<VOTABLE version="1.0">
  <DEFINITIONS>
    <COOSYS ID="J2000" equinox="2000." epoch="2000." system="eq_FK5"/>
  </DEFINITIONS>
  <RESOURCE ID="GSC2.2.01" type="meta">
    <DESCRIPTION>The GSC 2.2 Catalogue (STScI, 2001,455851237 objects)</DESCRIPTION> 
    <PARAM ID="MaxRec" name="-out.max" ucd="NUMBER" datatype="int" value="50">
      <DESCRIPTION>Maximal number of retrieved records</DESCRIPTION> 
      <VALUES multiple="no" type="legal">
        <MIN value="1" inclusive="yes" /> 
        <MAX value="9999" inclusive="yes" />
      </VALUES>
    </PARAM>
    <PARAM ID="SkyLocation" name="-c" ucd="POS_EQ" datatype="char" arraysize="*">
      <DESCRIPTION>Target position in the sky according to the ASU syntax in J2000
      </DESCRIPTION> 
    </PARAM>
    <TABLE>
      <FIELD name="GSC2.2" UCD="ID_MAIN" datatype="char" arraysize="14">
        <DESCRIPTION>Identification of the object</DESCRIPTION></FIELD>
      <FIELD name="RA(ICRS)" UCD="POS_EQ_RA_MAIN" ref="J2000" 
          datatype="double" width="10" precision="6" unit="deg">
        <DESCRIPTION>Right Ascension in ICRS (J2000), at Epoch
        </DESCRIPTION>
      </FIELD>
      <FIELD name="DE(ICRS)" UCD="POS_EQ_DEC_MAIN" ref="J2000" 
          datatype="double" width="10" precision="6" unit="deg">
        <DESCRIPTION>Declination in ICRS (J2000)
        </DESCRIPTION>
      </FIELD>
      <FIELD name="Rmag" UCD="PHOT_PHG_R" datatype="float" width="5" 
          precision="2" unit="mag">
        <DESCRIPTION>?Magnitude in F photographic band (red)
        </DESCRIPTION>
      </FIELD>
      <FIELD name="e_Rmag" UCD="ERROR" datatype="float" width="5" 
          precision="2" unit="mag">
        <DESCRIPTION>? Mean error on Rmag (2)</DESCRIPTION> 
      </FIELD>
      <LINK content-role="query" action="asu-xml?-source=I/271/out&amp;" /> 
    </TABLE>
  </RESOURCE>
</VOTABLE>
\end{verbatim}
\ifhtx\End{TABULAR}\fi
\normalsize

Note that the {\elem{RESOURCE}} displaying the parameters accessible 
for a query has the {\attrval{type}{meta}}
attribute; it is also assumed that only one {\elem{LINK}}
having the {\attrval{content-role}{query}}
attribute together with an {\attr{action}}
attribute exists within the current {\elem{RESOURCE}}.


\clearpage
\section*{References}

\noindent [1] Accomazzi{\it  et. al, Describing Astronomical Catalogues and
Query Results with XML
}\\ \hspace*{1em}{{http://vizier.u-strasbg.fr/doc/astrores.htx}}

\noindent [2] {\it FITS: Flexible Image Transport
Specification}, specifically the Binary Tables
Extension
\\ \hspace*{1em}{{http://fits.gsfc.nasa.gov/}}

\noindent [3] {\it Standards for Astronomical
Catalogues: Units, CDS
Strasbourg}
\\ \hspace*{1em}{{http://vizier.u-strasbg.fr/doc/catstd-3.2.htx}}

\noindent [4] {\it Unified Content
Descriptors}
\\ \hspace*{1em}{{http://vizier.u-strasbg.fr/doc/UCD.htx}}

\noindent [5] {\it GLU: G\'{e}n\'{e}rateur de Liens Uniformes, CDS
Strasbourg}
\\ \hspace*{1em}{{http://simbad.u-strasbg.fr/glu/glu.htx}}

\noindent [6] {\it ASU: Astronomical Server URL, CDS
Strasbourg}
\\ \hspace*{1em}{{http://vizier.u-strasbg.fr/doc/asu.html}}

\noindent [7] {\it XDF: Extensible Data format, ADC}
\\ \hspace*{1em}{{http://xml.gsfc.nasa.gov/XDF/XDF\_home.html}}

\noindent [8] {\it XML Schema: W3C Document}
\\ \hspace*{1em}{{http://www.w3.org/XML/Schema}}

\end{document}
