Merge pull request #34 from pdowler/master

fix cross-refs and clarify overflow

DALI.tex

@@ -233,7 +233,7 @@ \subsection{Asynchronous Execution: DALI-async}
 A concrete DAL service specification will specify zero or more asynchronous job
 submission resources and whether they are mandatory or optional. It may mandate
 a specific resource name to support simple client use, or it can allow the
-resource name to be described in the service metadata (Section 2.5 ).
+resource name to be described in the service metadata (Section~\ref{sec:vosi-capabilities}).
 
 \subsection{Synchronous Execution: DALI-sync}
 \label{sec:dali-sync}
@@ -266,7 +266,8 @@ \subsection{Synchronous Execution: DALI-sync}
 A concrete DAL service specification will specify zero or more synchronous job
 submission resources and whether they are mandatory or optional. It may mandate
 a specific resource name to support simple client use, or it can allow the
-resource name to be described in the service capability metadata (Section 2.5 ).
+resource name to be described in the service capability metadata 
+(Section~\ref{sec:vosi-capabilities}).
 
 \subsection{DALI-examples}
 \label{sec:dali-examples}
@@ -287,7 +288,8 @@ \subsection{DALI-examples}
 $$
 
 DAL services may implement the /examples resource and include it in the
-capabilities described by the VOSI-capabilities resource (Section 2.5 ); if they
+capabilities described by the VOSI-capabilities resource 
+(Section~\ref{sec:vosi-capabilities}); if they
 do not, retrieving its URL must yield a 404 HTTP error code.
 
 The document at /examples must be well-formed XML. This restriction is imposed
@@ -1075,8 +1077,8 @@ \subsubsection{RESPONSEFORMAT}
 In some cases, the specification for a specific format may be parameterised
 (e.g., the media type may include optional semi-colon and additional key-value
 parameters). A DAL service must accept a RESPONSEFORMAT parameter indicating a
-format that the service supports and should  fail (Section 4.2 ) where the
-RESPONSEFORMAT parameter specifies a format not supported by the service
+format that the service supports and should  fail (Section~\ref{sec:response-error}) 
+where the RESPONSEFORMAT parameter specifies a format not supported by the service
 implementation.
 
 A concrete DAL service specification will specify any mandatory or optional
@@ -1120,11 +1122,11 @@ \subsubsection{MAXREC}
 enforce a limit on the value of MAXREC that is smaller than the value in the
 request. If the size of the result exceeds the resulting limit, the service must
 only return the requested number of rows. If the result set is truncated in this
-fashion, it must include an overflow indicator as specified in Section 4.4.1 .
+fashion, it must include an overflow indicator as specified in Section \ref{sec:response-overflow}.
 
 The service must support the special value of MAXREC=0. This value indicates
 that, in the event of an otherwise valid request, a valid response be returned
-containing metadata, no results, and an overflow indicator (Section 4.4.1 ). The
+containing metadata, no results, and an overflow indicator. The
 service is not required to execute the request and the overflow indicator does
 not necessarily mean that there is at least one record satisfying the query. The
 service may perform validation and may try to execute the request, in which case
@@ -1325,7 +1327,7 @@ \subsection{Redirection}
 A concrete DAL service specification may require that HTTP redirects (302 or
 303) be used to communicate the location of an alternate resource which should
 be accessed by the client via the HTTP GET method. For example, the UWS pattern
-used for DALI-async (Section 2.1 ) requires this behaviour. Even when not
+used for DALI-async (\ref{sec:dali-async}) requires this behaviour. Even when not
 required, concrete DAL service specifications must allow implementers to use
 redirects and clients must be prepared to follow these redirects using normal
 HTTP semantics \citep{std:HTTP}.
@@ -1389,12 +1391,11 @@ \subsection{Use of VOTable}
 
 \subsubsection{Overflow}
 \label{sec:response-overflow}
-If an overflow occurs (for example, result exceeds MAXREC), the service must include an
-\xmlel{INFO}
-element in the \xmlel{RESOURCE} with \verb|name="QUERY\_STATUS"| and the
-\verb|value="OVERFLOW"|. If
-the initial \xmlel{INFO} element (above) specified the overflow, no further elements are
-needed, e.g.:
+If an overflow occurs (for example, result exceeds MAXREC) and the output format
+is VOTable, the service must include an \xmlel{INFO} element in the \xmlel{RESOURCE}
+with \verb|name="QUERY\_STATUS"| and the \verb|value="OVERFLOW"|. If the initial
+\xmlel{INFO} element (above) specified the overflow, no further elements are needed,
+e.g.:
 
 \begin{lstlisting}[language=XML]
 <RESOURCE type="results">
@@ -1416,6 +1417,10 @@ \subsubsection{Overflow}
 </RESOURCE>
 \end{lstlisting}
 
+There is no defined mechanism to indicate overflow (truncation) of output for formats
+other than VOTable. Specifically, simple text formats like \verb|text/csv| and
+\verb|text/tab-separated-values| do not support indicating overflow.
+
 In general, services may truncate the output results when reaching a limit. A default or
 user-specified value of the MAXREC parameter is a common mechanism that causes truncation
 of results, but service providers may also impose limits in services that do not use