[Volute] r3518 - trunk/projects/dal/SODA

Volute commit messages volutecommits at g-vo.org
Wed Oct 26 18:05:47 CEST 2016


Author: pdowler.cadc
Date: Fri Sep  2 09:06:08 2016
New Revision: 3518

Log:
added text to make multi-valued parameters optional and specific error codes for use when not supported

Modified:
   trunk/projects/dal/SODA/SODA.tex

Modified: trunk/projects/dal/SODA/SODA.tex
==============================================================================
--- trunk/projects/dal/SODA/SODA.tex	Wed Aug 31 12:03:14 2016	(r3517)
+++ trunk/projects/dal/SODA/SODA.tex	Fri Sep  2 09:06:08 2016	(r3518)
@@ -364,7 +364,20 @@
 \label{sec:parameters}
 
 The \{sync\} and \{async\} resources accept the same set of
-parameters.
+parameters. Support for multiple values of parameters is optional. 
+If a request includes multiple values for a parameter and the 
+service does not support multipe values for that parameter, the 
+request must fail with the MultiValuedParamNotSupported error listed
+below (\ref{sec:error-codes}). For example, a service may 
+allow only single values for ID but multiple values for cutout parameters. 
+Supported multiplicity may also differ between {sync} and {async} requests.
+
+In general, services would support multi-valued parameters as they may be 
+able to provide more efficent access to data files. Clients may attempt to use 
+multi-valued parameters, but must be prepared to fall back to multiple requests 
+if the service indicates this is not supported. A future version of 
+\citep{std:DataLink} should provide a mechanism to describe parameter 
+multiplicity.
 
 
 \subsection{Common Parameters}
@@ -381,27 +394,13 @@
 descriptor resources that can be used by clients to set the
 ID parameter.
 
-The ID parameter is single-valued in \{sync\} requests, so
-\{sync\} soda requests access a single dataset or file.
-Multiple ID parameters may be submitted in \{async\} requests
-on order to bundle access to multiple datasets or files in a
-single job.
-
 The UCD \citep{std:UCD} describing the ID parameter is\\
 \ucd{meta.ref.url;meta.curation}.
 
 \subsection{Filtering Parameters}
 
 Filtering parameters are used to extract subsets of larger
-datasets or data files. In general, filtering parameters are
-single-valued in \{sync\} requests and multi-valued in \{async\}
-requests (exceptions noted below). When multiple values of
-filtering parameters are used in an \{async\} job, each
-combination of values produces zero or one result. For
-example, if an \{async\} job included two POS and two BAND
-values, there could be as many as four results (or fewer if
-some combinations do not produce a result because the filter
-does not intersect the bounds of the data).
+datasets or data files. 
 
 \subsubsection{CIRCLE} 
 \label{sec:CIRCLE}
@@ -415,9 +414,6 @@
 CIRCLE=12 34 0.5
 \end{lstlisting}
 
-The CIRCLE parameter is single-valued for \{sync\} requests and
-multi-valued for \{async\} jobs.
-
 The UCD \citep{std:UCD} describing the CIRCLE parameter is
 \ucd{phys.angArea;obs}.
 
@@ -437,9 +433,6 @@
 POLYGON=12 34 14 34 14 36 12 36
 \end{lstlisting}
 
-The POLYGON parameter is single-valued for \{sync\} requests and
-multi-valued for \{async\} jobs.
-
 The UCD \citep{std:UCD} describing the POLYGON parameter is
 \ucd{phys.angArea;obs}.
 
@@ -510,9 +503,6 @@
 reference systems (specifically the native system of the
 data).
 
-The POS parameter is single-valued for \{sync\} requests and
-multi-valued for \{async\} jobs.
-
 The UCD \citep{std:UCD} describing the POS parameter is \ucd{phys.angArea;obs}.
 
 Since it is string-valued, POS is unitless; however, the numeric values
@@ -578,13 +568,9 @@
 use of other reference systems (specifically the native
 system of ther data).
 
-The BAND parameter is single-valued for \{sync\} requests and
-multi-valued for \{async\} jobs.
-
 The UCD \citep{std:UCD} describing the BAND parameter is \ucd{em.wl}.
 
 
-
 \subsubsection{TIME}
 \label{sec:TIME}
 
@@ -614,14 +600,10 @@
 \end{lstlisting}
 \end{itemize}
 
-The TIME parameter is single-valued for \{sync\} requests and
-multi-valued for \{async\} jobs.
-
 The UCD \citep{std:UCD} describing the TIME parameter is
 \ucd{time.interval;obs.exposure}.
 
 
-
 \subsubsection{POL}
 \label{sec:POL}
 
@@ -638,9 +620,7 @@
 POL=V
 \end{lstlisting}
 
-\item The POL parameter is multi-valued; multiple values can be
-included in a single request and all will be extracted.
-Extract only the IQU components:
+\item Extract only the IQU components:
 \begin{lstlisting}
 POL=I
 POL=Q
@@ -648,9 +628,9 @@
 \end{lstlisting}
 \end{itemize}
 
-The POL parameter enumerated and thus multi-valued for both \{sync\} and
-\{async\} requests.  Unlike general filtering parameters, all values of
-POL are combined into a single filter; for example, if the request
+As shown in the example above, the POL parameter must support multiple values 
+for both \{sync\} and \{async\} requests.  Unlike general filtering parameters, 
+all values of POL are combined into a single filter; for example, if the request
 includes the three values above, the job would generate one result with
 some or all of these polarization states (per combination of ID and
 other filtering parameters).
@@ -667,7 +647,10 @@
 The spatial parameters (CIRCLE, POLYGON and POS) constrain the spatial support of the output virtual dataset. (The ObsCore attribute name is s\_region - utype `obscore:Char.SpatialAxis.Coverage.Support.Area'' -). The spatial support of the output dataset is included in the spatial support of the archived dataset.
 
 The TIME parameter constrains the time bounds of the SODA output virtual dataset (Obscore feature of utype "Char.TimeAxis.Coverage.Bounds.Limits"). The time bounds of the output dataset are limited by the time bounds of the archived dataset.
-The BAND parameter constrains the spectral bounds of the SODA output virtual dataset (Obscore feature of utype "Char.spectralAxis.Coverage.Bounds.LImits"). The spectral bounds of the output datasets are limited by the spectral bounds of the archived dataset.
+The BAND parameter constrains the spectral bounds of the SODA output virtual 
+dataset (Obscore feature of utype "Char.spectralAxis.Coverage.Bounds.Limits"). 
+The spectral bounds of the output datasets are limited by the spectral bounds of 
+the archived dataset.
 
 The POL parameter constrain the  list of polarization states in  the output virtual dataset (ObsCore feature of name "pol\_states" - utype``obscore:Char.PolarizationAxis.stateList''). The
 valid values for this param are included in the list given by the value
@@ -691,17 +674,17 @@
 \href{http://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaResReg}{http://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaResReg}.}.
 
 \begin{table}[mht]
-\begin{tabular}{llll}
+\begin{tabular}{l l l l}
 \sptablerule
-\textbf{Name}&\textbf{UCD}&\textbf{Unit}&\textbf{Semantics}\cr
+\textbf{Name}&\textbf{UCD}&\textbf{Unit}&\textbf{Semantics} \cr
 \sptablerule
-ID&meta.ref.url;meta.curation&&cf.~sect.~\ref{sec:ID}\cr
-CIRCLE&phys.angArea;obs&deg&cf.~sect.~\ref{sec:CIRCLE}\cr
-POLYGON&phys.angArea;obs&deg&cf.~sect.~\ref{sec:POLYGON}\cr
-POS&phys.angArea;obs&&cf.~sect.~\ref{sec:POS}\cr
-BAND&em.wl&m&cf.~sect.~\ref{sec:BAND}\cr
-TIME&time.interval;obs.exposure&d&cf.~sect.~\ref{sec:TIME}\cr
-POL&meta.code;phys.polarization&&cf.~sect.~\ref{sec:POL}\cr
+ID&meta.ref.url;meta.curation&&cf.~sect.~\ref{sec:ID} \cr
+CIRCLE&phys.angArea;obs&deg&cf.~sect.~\ref{sec:CIRCLE} \cr
+POLYGON&phys.angArea;obs&deg&cf.~sect.~\ref{sec:POLYGON} \cr
+POS&phys.angArea;obs&&cf.~sect.~\ref{sec:POS} \cr
+BAND&em.wl&m&cf.~sect.~\ref{sec:BAND} \cr
+TIME&time.interval;obs.exposure&d&cf.~sect.~\ref{sec:TIME} \cr
+POL&meta.code;phys.polarization&&cf.~sect.~\ref{sec:POL} \cr
 \sptablerule
 \end{tabular}
 \caption{Three-Factor Semantics for standard SODA parameters}
@@ -722,8 +705,6 @@
 clients via DataLink \citep{std:DataLink} service descriptor(s) as
 described in Section~\ref{sec:integration}.
 
-
-
 \section{Integration of Service Capabilities}
 \label{sec:integration}
 
@@ -968,300 +949,6 @@
 service itself can generate a data-specific service descriptor of itself
 may be included in SODA-1.1 or later.
 
-
-=======
-Parameters in SODA are uniquely defined by the triple of name, UCD
-\citep{std:UCD}, and unit \citep{std:VOUNIT}.  Data services are free to
-support as many such parameters as is appropriate for their datasets, in
-addition to supporting standard parameters.  With the three factors, it
-is unlikely that two service providers will by accident use the same
-three factors for parameters of differing semantics.  
-
-With standard parameters as defined in this document, clients can rely
-on certain semantics and exploit that knowledge in the provision of
-special UIs or APIs.  Standard parameters defined so far are given
-in table~\ref{table:standardpars}.  Instructions for how to propose
-additional standard parameters are given on the landing page of the IVOA
-DAL working group\footnote{At the time of writing, this is
-\href{http://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaResReg}{http://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaResReg}.}.
-
-\begin{table}[mht]
-\begin{tabular}{llll}
-\sptablerule
-\textbf{Name}&\textbf{UCD}&\textbf{Unit}&\textbf{Semantics}\cr
-\sptablerule
-ID&meta.ref.url;meta.curation&&cf.~sect.~\ref{sec:ID}\cr
-CIRCLE&phys.angArea;obs&deg&cf.~sect.~\ref{sec:CIRCLE}\cr
-POLYGON&phys.angArea;obs&deg&cf.~sect.~\ref{sec:POLYGON}\cr
-POS&phys.angArea;obs&&cf.~sect.~\ref{sec:POS}\cr
-BAND&em.wl&m&cf.~sect.~\ref{sec:BAND}\cr
-TIME&time.interval;obs.exposure&d&cf.~sect.~\ref{sec:TIME}\cr
-POL&meta.code;phys.polarization&&cf.~sect.~\ref{sec:POL}\cr
-\sptablerule
-\end{tabular}
-\caption{Three-Factor Semantics for standard SODA parameters}
-\label{table:standardpars}
-\end{table}
-
-Both standard and non-standard parameters should follow DALI conventions
-if at all possible.  Roughly, float-valued target fields should be accessed or
-constrained via interval-valued parameters (i.e., do not split up
-minimum and maximum into separate parameters).  Depending on their
-semantics, integer parameters should either be intervals or enumerated
-parameters (which typically can be repeated). Geometry fields should be
-accessed or constrained using geometry values (circle and polygon xtypes
-from DALI \citep{std:DALI}), following the examples of CIRCLE
-(\ref{sec:CIRCLE}) and POLYGON (\ref{sec:POLYGON}).
-
-Parameter metadata, including three-factor semantics, is conveyed to
-clients via DataLink \citep{std:DataLink} service descriptor(s) as
-described in Section~\ref{sec:integration}.
-
-
-\section{Integration of Service Capabilities}
-\label{sec:integration}
-
-Finding and using SODA services depends on several other standards;
-service providers can follow one or more stategies in integrating a
-range of standard and custom services with their SODA implementation.
-Here we describe these strategies and show how to use the standards
-together.
-
-Wthin the IVOA architecture, SODA servces could be found and used in two
-ways. First, a SODA service could be found in the IVOA Registry and used
-directly. Second, a description of a SODA service may be found along
-with specific dataset metadata; this is the primary anticipated usage:
-clients discover applicable SODA services while doing data discovery
-queries.
-
-The DatatLink \citep{std:DataLink} recommendation provides a mechanism
-to include ``a description of a SODA service'' using a standard resource
-called a service descriptor. The service descriptor is included in any
-VOTable \citep{std:VOTable} output and can describe the parameters for
-use with a DALI-sync or DALI-async compliant capability. Aside from DALI
-\citep{std:DALI} compliance, this may be a standard service or a custom
-service. Since the service descriptor can describe all input parameters,
-it can declare available standard parameters, extensions (custom
-parameters in standard services), and parameters for custom services.
-This mechanism is expected to be the primary means of finding and using
-a SODA service. 
-
-A generic SODA sync service descriptor describing the standard
-parameters (see sect.~\ref{sec:parameters}):
-
-\begin{lstlisting}[language=XML]
-<RESOURCE type="meta" ID="soda-sync" utype="adhoc:service">
-  <PARAM name="standardID" datatype="char" arraysize="*" 
-         value="ivo://ivoa.net/std/SODA#sync-1.0" />
-  <PARAM name="accessURL" datatype="char" arraysize="*" 
-        value="http://example.com/soda/sync" />
-  <GROUP name="inputParams">
-    <PARAM name="ID" ucd="meta.ref.url;meta.curation" 
-            ref="idcolumn-ref" 
-            datatype="char" arraysize="*" value="" />
-    <PARAM name="POS" ucd="phys.angArea;obs" 
-            datatype="char" arraysize="*" value="" />
-    <PARAM name="CIRC" unit="deg" ucd="phys.angArea;obs" 
-            datatype="double" arraysize="3" 
-            xtype="circle" value="" />
-    <PARAM name="POLY"  unit="deg" ucd="phys.angArea;obs"
-            datatype="double" arraysize="*" 
-            xtype="polygon"  value="" />
-    <PARAM name="BAND" unit="m" ucd="em.wl" 
-            datatype="double" arraysize="2" 
-            xtype="interval" value="" />
-    <PARAM name="TIME" ucd="time.interval;obs" unit="d" 
-            datatype="double" arraysize="2" 
-            xtype="interval" value="" />
-    <PARAM name="POL" ucd="meta.code;phys.polarization" 
-            datatype="char" arraysize="2*" value="" />
-  </GROUP>
-</RESOURCE>
-\end{lstlisting}
-
-This service descriptor is generic because the ID parameter uses a
-\xmlel{ref} attribute to specify that identifier values come from
-elsewhere in the document (usually this refers to a FIELD element that
-descrbes a table column within another RESOURCE element). Thus, this
-descriptor can be used with any ID values in that column.
-
-The PARAM with \texttt{name="standardID"} specifies that this service is
-a SODA sync service. The standardID values for SODA are specified in
-Section~\ref{sec:capabilities}. 
-
-The GROUP with \texttt{name="inputParams"} shows the standard
-description of the standard SODA parameters as defined in
-Section~\ref{sec:parameters}. Services should only include parameter
-descriptions for supported parameters; in a generic service descriptor
-``supported'' means supported by the implementation and does not imply
-that use of that parameter is applicable to all data (e.g. to all
-possible identifier values).
-
-
-\subsection{SODA Service in the Registry}
-\label{sec:reg-soda}
-
-Resources in the IVOA Registry may include SODA capabilites. In order to
-use such services, clients require a priori knowledge of suitable
-identifiers that are usable with a registered SODA service. Finding and
-using a SODA service via the registry is not expected to be a common
-usage pattern unless 
-
-
-\subsection{SODA Service Descriptor from Data Discovery}
-\label{sec:disc-soda}
-
-In the simplest case, the identifiers found via data discovery (e.g. the
-\texttt{obs\_publishder\_did} in Obscore \citep{std:OBSCORE}) can be
-used directly with an associated SODA service. The query response from
-SIAv2 \citep{std:SIAv2} or TAP \citep{std:TAP} should include one or
-more DataLink \citep{std:DataLink} service descriptors that describe the
-SODA capabilities. These would have a \texttt{standardID} parameter
-specifying SODA \{async\} or SODA \{sync\} as specified in
-Section~\ref{sec:capabilities} and an appropriate \texttt{accessURL}
-parameter for the service. If the service is registered, the provider
-can include a \texttt{resourceIdentifier} parameter. The supported SODA
-service parameters (standard and custom) would be declared in the
-inputParams group of the service descriptor. 
-
-The declaration of the ID parameter will specify which column in the
-data discovery response contains the  suitable identifier; although this
-is usually the obs\_publishder\_did from the ObsCore data model, this is
-not required and the provider may have the ID parameter reference
-another (possibly custom) column.
-
-The data discovery response will in general contain metadata the client
-can use to determine the values of SODA filtering parameters that will
-yield valid subsets of the data. For example, standard data discovery
-using either SIAv2 or TAP and Obscore will provide metadata for
-specifying POS, CIRCLE, and POLYGON (s\_region, s\_ra, s\_dec, s\_fov),
-BAND (em\_min, em\_max), TIME (t\_min, t\_max), and POL (pol\_states)
-parameters.
-
-When a service descriptor for a SODA service is provided in the data
-discovery response, it should be a generic descriptor (see above) for
-use with multiple ID values. Thus, there will normally be a single
-service descriptor for each available service.
-
-
-\subsection{SODA Service Descriptor from DataLink}
-\label{sec:disc-links-soda}
-
-In the general case, data discovery responses may contain usable HTTP
-URL(s) (e.g. in an Obscore \citep{std:OBSCORE} response, the
-\texttt{access\_url} contains a link that invokes a DataLink
-\citep{std:DataLink} links resource and the access\_format column
-contains the standard DataLink \citep{std:DataLink} content-type) or the
-document may contain a service descriptor for an associated DataLink
-links capability. For example, the latter:
-
-\begin{lstlisting}[language=XML]
-<RESOURCE type="results">
-<TABLE>
-  <FIELD name="obs_publisher_did" ucd="meta.ref.url;meta.curation" 
-        ID="primaryID" 
-        datatype="char" arraysize="*">
-    <DESCRIPTION>The publisher identifier for the dataset</DESCRIPTION>
-  </FIELD>
-...
-</TABLE>
-</RESOURCE>
-<RESOURCE type="meta" utype="adhoc:service">
-  <PARAM name="standardID" datatype="char" arraysize="*" 
-         value="ivo://ivoa.net/std/DataLink#links-1.0" />
-  <PARAM name="accessURL" datatype="char" arraysize="*"
-         value="http://example.com/srv/links" />
-  <GROUP name="inputParams">
-    <PARAM name="ID" ucd="meta.ref.url;meta.curation" 
-            ref="primaryID"
-            datatype="char" arraysize="*" value=""/>
-  </GROUP>
-</RESOURCE>
-\end{lstlisting}
-
-The client must call this service (with an identifier from the data
-discovery response) in order to get details about the available
-resources (files to download, related resources, and services that can
-be used to access the files). One or more of these related services can
-be SODA services.
-
-In this case, the response containing the links will not include all the
-dataset metadata necessary to determine values for SODA filtering
-parameters. While generic service descriptors (see above) are still
-permitted, it is much ore useful if the links response contains data- or
-file-specific service descriptors that make use of the ability to
-include metadata in the parameter descriptions. Thus, the provider will
-normally include one or more data-specific service descritors for each
-input ID, but scalability should not be a problem because clients
-nornally use a single or small number of ID(s) per invocation.
-
-A data-specific SODA sync service descriptor describing the standard
-parameters (see~\ref{sec:parameters}) with plausible values:
-
-\begin{lstlisting}[language=XML]
-<RESOURCE type="meta" ID="soda-xdk48g" utype="adhoc:service">
-  <PARAM name="standardID" datatype="char" arraysize="*" 
-        value="ivo://ivoa.net/std/SODA#sync-1.0" />
-  <PARAM name="accessURL" datatype="char" arraysize="*" 
-        value="http://example.com/soda/sync" />
-  <GROUP name="inputParams">
-    <!-- ID value for a specific RA-DEC-FREQ cube -->
-    <PARAM name="ID" ucd="meta.ref.url;meta.curation" 
-            datatype="char" arraysize="*" 
-            value="internal:123" />
-    <PARAM  name="POS" ucd="phys.angArea;obs" 
-            datatype="char" arraysize="*" value="" />
-    <PARAM name="CIRC" unit="deg" ucd="phys.angArea;obs" 
-            datatype="double" arraysize="3" 
-            xtype="circle" value="">
-      <VALUES> <MAX value="12.0 34.0 0.5"/> </VALUES>
-    </PARAM>
-    <PARAM name="POLY"  unit="deg" ucd="phys.angArea;obs"
-            datatype="double" arraysize="*" 
-            xtype="polygon"  value="">
-      <VALUES>
-        <MAX value="11.5 33.5 12.5 33.5 12.5 34.5 11.5 34.5"/> 
-      </VALUES>
-    </PARAM>
-    <PARAM name="BAND" unit="m" ucd="em.wl" 
-            datatype="double" arraysize="2" 
-            xtype="interval" value="">
-      <VALUES>
-        <MAX value="300.0e-9 800.0e-9"/>
-      </VALUES>
-    </PARAM>
-  </GROUP>
-</RESOURCE>
-\end{lstlisting}
-
-In this example, the \xmlel{ID} attribute of the service descriptor
-resource (soda-xdk48g) is generated and would be referenced from the
-\texttt{service\_def} column of the links table. Since this is a
-data-specific descriptor, the ID parameter has a fixed value instead of
-a ref attribute, and the CIRC, POLY, and BAND parameters have suggested
-values. The suggested values are the nominal maximum values which are
-interpretted as values of the regions or intervals that contain the
-data. For example, the value given for the POLY parameter is the
-bounding polygon for this data. The absence of a POL parameter means
-that polarization cutout is either not supported or not applicable to
-this data.
-
-In order to make it easier for clients, data-specific service
-descriptors should only include parameter descriptions when the action
-(cutout) can actually result in a modification of the data. For example,
-if the axis has only one bin (e.g. time axis for an RA-DEC-FREQ cube),
-then the associated parameter (e.g. TIME) should not be included in the
-descriptor - even when valid time bounds metadata is known.
-
-Providing values in the parameter descriptions of a data-specific
-service descriptor implies that the resource generating this has access
-to the applicable metadata. Depending on system architecture, this may
-difficult to implement.  An ``autodescription'' mechanism where the SODA
-service itself can generate a data-specific service descriptor of itself
-may be included in SODA-1.1 or later.
-
-
->>>>>>> .r3500
 \section{\{sync\} Responses}
 
 All responses from the \{sync\} resource follow the rules for
@@ -1294,8 +981,8 @@
 Content-Length and Last-Modified headers cannot usually be
 set.
 
-
 \subsection{Errors}
+\label{sec:error-codes}
 
 The error handling specified for DALI-sync resources applies
 to service failure. Error documents should be text using the
@@ -1303,12 +990,19 @@
 the following strings:
 
 \begin{table}[h]
-\begin{tabular}{rr}
-Error&General error (not covered below)\cr
-AuthenticationError&Not authenticated\cr
-AuthorizationError&Not authorized to access the resource\cr
-ServiceUnavailable&Transient error (could succeed with retry)\cr
-UsageError&Permanent error (retry pointless)\cr
+\begin{tabular}{l l}
+\sptablerule
+\textbf{error code} & \textbf{description}  \cr
+\sptablerule
+Error&General error (not covered below) \cr
+AuthenticationError&Not authenticated \cr
+AuthorizationError&Not authorized to access the resource \cr
+ServiceUnavailable&Transient error (could succeed with retry) \cr
+UsageError&Permanent error (retry pointless) \cr
+MultiValuedParamNotSupported&request included multiple values for a parameter\cr
+&but the service only supports a single value \cr
+NoContent&filtering of the data resulted in no usable content \cr
+\sptablerule
 \end{tabular}
 \caption{error messages with their meaning}
 \end{table}
@@ -1321,11 +1015,25 @@
 listed as children of the UWS results resource. The service
 provider is free to name each result.
 
+When multiple values of input parameters are accepted, 
+each combination of values produces one result. For
+example, if an \{async\} job included two CIRCLE and two BAND
+values, there must be four results. If a combination
+of input parameters does not produce a result (e.g. there is no 
+overlap between the parameter values and data extent), the job results 
+must contain a result entry that indicates this. This should be
+a result URL which returns a text/plain document with a message
+starting with one of the error labels in Section~\ref{sec:error-codes} 
+above.
+
 
 \section{Changes from Previous Versions}
 
 \subsection{Changes from PR-SODA-20160429}
 \begin{itemize}
+\item Make multiple values for all parameters optional in both {sync} and 
+{async} requests and introduce a specific error message if multiplicity of 
+a parameter is not supported.
 \item Added section introducing the different usage scenarios for SODA
 and how they can interact with other DAL capabilities. Moved the bulk of
 the nomative text to an integration section so that it follows the
@@ -1362,7 +1070,7 @@
 \item Removed REQUEST parameter since the DAL-WG decision to not
 include it when there is only one value.
 
-\item Clarified that ID and filierting parameters are single
+\item Clarified that ID and filtering parameters are single
 valued for \{sync\} and multi-valued for \{async\}, wth POL
 being multi-valued but still being treated as a single
 filter.


More information about the Volutecommits mailing list