Removing trailing whitespace

Author: msdemlei

DALI.tex

@@ -267,7 +267,7 @@ \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 
+resource name to be described in the service capability metadata
 (Section~\ref{sec:vosi-capabilities}).
 
 \subsection{DALI-examples}
@@ -289,7 +289,7 @@ \subsection{DALI-examples}
 $$
 
 DAL services may implement the /examples resource and include it in the
-capabilities described by the VOSI-capabilities resource 
+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.
 
@@ -733,8 +733,8 @@ \subsection{Sexagesimal Coordinates}
 (latitude) must fall within [-90,90], minutes must fall within [0,60), and seconds
 must fall within [0,60). Valid values for \verb|xtype="hms"| are from 0:0:0 to 24:0:0.
 Valid values for \verb|xtype="dms"| are from -90:0:0 to 90:0:0; an optional + sign at
-the start is allowed (e.g. +10:20:30) but not required. The upper bound on minutes 
-and seconds is not part of the valid range; for example 12:34:60 is not allowed and must 
+the start is allowed (e.g. +10:20:30) but not required. The upper bound on minutes
+and seconds is not part of the valid range; for example 12:34:60 is not allowed and must
 be expressed as 12:35:00 instead.
 
 \subsection{Point}
@@ -754,7 +754,7 @@ \subsection{Point}
 
 Coordinate values are not limited to fall within a defined valid range; this is a change from
 DALI 1.1 where equatorial coordinates were explicitly limited. Software may have
-to perform range reduction in some coordinate systems (for example, spherical coordinates) in 
+to perform range reduction in some coordinate systems (for example, spherical coordinates) in
 order to correctly interpret or use the coordinate values. Coordinate values are more likely to
 work as expected if they are expressed in the simplest form and do not require range reduction.
 For example, in spherical coordinates, \verb|362.0 2.0| is equivalent to \verb|2.0 2.0|, but the
@@ -766,7 +766,7 @@ \subsection{Point}
 \subsection{Circle}
 Circle values serialised in VOTable or service parameters must have the following metadata in the
 \xmlel{FIELD} element: \verb|datatype="double"| or \verb|datatype="float"|, \verb|arraysize="3"|,
-\verb|xtype="circle"|. 
+\verb|xtype="circle"|.
 The values are ordered as a point followed by a radius. For example:
 
 \begin{verbatim}
@@ -803,11 +803,11 @@ \subsection{Range}
 \noindent
 includes values from 10 to 11 (coordinate1) and from 20 to 21 (coordinate2).
 
-Valid coordinate value limits are specified by \verb|xtype="point"| above. 
-This range form is used as part of the value of the POS parameter in 
-\citep{2015ivoa.spec.1223D} and \citep{2017ivoa.spec.0517B} (see also "shape" below). 
+Valid coordinate value limits are specified by \verb|xtype="point"| above.
+This range form is used as part of the value of the POS parameter in
+\citep{2015ivoa.spec.1223D} and \citep{2017ivoa.spec.0517B} (see also "shape" below).
 For example, a range can span the meridian (longitude 0): 359 1 -1 1 is interpreted
-as the small (2x2 degree) coordinate range from 359 across the meridian to 1 degree 
+as the small (2x2 degree) coordinate range from 359 across the meridian to 1 degree
 longitude.
 
 Range-valued service parameters may include additional metadata like minimum and
@@ -837,7 +837,7 @@ \subsection{Polygon}
 10.0 10.0 10.2 10.0 10.2 10.2 10.0 10.2
 \end{verbatim}
 
-Valid coordinate value limits are specified by \verb|xtype="point"| above. 
+Valid coordinate value limits are specified by \verb|xtype="point"| above.
 Vertices must be ordered such that the polygon
 winding direction is counter-clockwise (when viewed from the origin toward the
 sky) as described in \citep{2007ivoa.spec.1030R}.
@@ -906,7 +906,7 @@ \subsection{Shape}
 polygon 10.0 10.0 10.2 10.0 10.2 10.2 10.0 10.2
 \end{verbatim}
 
-The interpretation and constraints on the coordinate values are as specified 
+The interpretation and constraints on the coordinate values are as specified
 for the individual xtypes above.
 
 The shape xtype provides a compatible description of the POS parameter in
@@ -948,40 +948,40 @@ \subsection{Shape}
 more limited context.
 
 \subsection{URI}
-URI values \citep{std:RFC3986} serialised in VOTable or service parameters 
-should have the following metadata in the \xmlel{FIELD} element: \verb|datatype="char"|, 
-\verb|arraysize="*"|, \verb|xtype="uri"| (where arraysize may also be fixed length or 
+URI values \citep{std:RFC3986} serialised in VOTable or service parameters
+should have the following metadata in the \xmlel{FIELD} element: \verb|datatype="char"|,
+\verb|arraysize="*"|, \verb|xtype="uri"| (where arraysize may also be fixed length or
 variable length with limit).
 
 \subsection{UUID}
-Universal Unique Identifier (UUID) values serialised in VOTable or service parameters 
-should have the following metadata in the \xmlel{FIELD} element: \verb|datatype="char"|, 
-\verb|arraysize="36"|, \verb|xtype="uuid"| (where arraysize may also be fixed length or 
+Universal Unique Identifier (UUID) values serialised in VOTable or service parameters
+should have the following metadata in the \xmlel{FIELD} element: \verb|datatype="char"|,
+\verb|arraysize="36"|, \verb|xtype="uuid"| (where arraysize may also be fixed length or
 variable length with limit).
 
-UUID values \citep{std:RFC4122} are serialised using the canonical ascii (hex) 
+UUID values \citep{std:RFC4122} are serialised using the canonical ascii (hex)
 representation, for example: e0b895ca-2ee4-4f0f-b595-cbd83be40b04.
 
 \subsection{Unsupported Types}
 
 Support for any specific \xmlel{xtype} in implementations (client or service) is specified in
 the service standard document. However, support for a specific \xmlel{xtype} as input (params
-and uploaded content) should generally be considered optional. Implementations should 
-be able to read and write the underlying data type without knowing the semantics added 
-by the \xmlel{xtype}. In cases where understanding the meaning of an \xmlel{xtype} is required (for 
-example, the POS param in SODA) and a service does not support the serialized value, 
-the service should issue an error message that starts with the following text with the 
+and uploaded content) should generally be considered optional. Implementations should
+be able to read and write the underlying data type without knowing the semantics added
+by the \xmlel{xtype}. In cases where understanding the meaning of an \xmlel{xtype} is required (for
+example, the POS param in SODA) and a service does not support the serialized value,
+the service should issue an error message that starts with the following text with the
 most specific \xmlel{xtype} noted:
 \begin{verbatim}
 unsupported-xtype: {xtype} [optional detail here]
 \end{verbatim}
 and may include additional detail where noted. For example, the value of the SODA POS parameter
-is a \verb|xtype="shape"|, but if the implementation does not support the "range" construct, it 
+is a \verb|xtype="shape"|, but if the implementation does not support the "range" construct, it
 would respond (minimally) with:
 \begin{verbatim}
 unsupported-xtype: range
 \end{verbatim}
-This behaviour will allow for new \xmlel{xtype}s to be introduced and for \verb|xtype="shape"| 
+This behaviour will allow for new \xmlel{xtype}s to be introduced and for \verb|xtype="shape"|
 to be extended to include additional subtypes in the future.
 
 \section{Parameters}
@@ -1084,7 +1084,7 @@ \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~\ref{sec:response-error}) 
+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.