# Diff of /trunk/projects/dal/SCS/ConeSearch.tex

trunk/projects/dal/SCS/SCS.tex revision 5689 by molinaro, Mon Oct 9 12:02:59 2017 UTC trunk/projects/dal/SCS/ConeSearch.tex revision 5690 by molinaro, Fri Nov 15 11:52:41 2019 UTC
# Line 32  Line 32
32
33  \begin{document}  \begin{document}
34  \begin{abstract}  \begin{abstract}
35  This specification defines a simple query protocol, named Simple Cone Search (SCS or simply cone search hereafter), for retrieving records from a catalog of astronomical sources. The query describes a sky position and an angular distance, defining a cone on the sky. The response returns a list of astronomical sources from the catalog whose positions lie within the cone, formatted as a VOTable. This version aims essentially at aligning this specification with the Data Access Layer (DAL) landscape at the time of writing.  This specification defines a simple query protocol, named Simple Cone
36    Search, for retrieving records
37    from a catalog of astronomical sources. The query describes a sky
38    position and an angular distance, defining a cone on the sky. The
39    response returns a list of astronomical sources from the catalog whose
40    positions lie within the cone, formatted as a VOTable. This version aims
41    essentially at aligning this specification with the Data Access Layer
42    (DAL) landscape at the time of writing.
43  \end{abstract}  \end{abstract}
44
45
46  \section*{Acknowledgments}  \section*{Acknowledgments}
47  This document was originally published as a document of the US National Virtual Observatory (NVO) \todo{check if the document or a link is still available} and then transcripted into an IVOA standards document format to became an IVOA recommendation. The changes made in this transcription and in the process of producing the first recommendation are reported in Appendix \ref{app:changes}.  This document was originally published as a document of the US National
48    Virtual Observatory (NVO) \todo{check if the document or a link is still
49  The Simple Cone Search (SCS) version 1.03 document has been developed with support from the National Science Foundation's Information Technology Research Program under Cooperative Agreement AST0122449 with The Johns Hopkins University.  available} and then transcripted into an IVOA standards document format
50    to became an IVOA recommendation. The changes made in this transcription
51  The SCS-1.1 revision has been developed under the ASTERICS project, supported by the European Commission Framework Programme Horizon 2020 Research and Innovation action, grant agreement n. 653477.  and in the process of producing the first recommendation are reported in
52    Appendix \ref{app:changes}.
53  Work of the original authors of the Cone Search specification as well as the numerous data providers who have implemented and continue to support this protocol is kindly acknowledged.
54    The Simple Cone Search version 1.03 document has been developed
55    with support from the National Science Foundation's Information
56    Technology Research Program under Cooperative Agreement AST0122449 with
57    The Johns Hopkins University.
58
59    The ConeSearch-1.1 revision has been developed under the ASTERICS
60    project, supported by the European Commission Framework Programme
61    Horizon 2020 Research and Innovation action, grant agreement n. 653477.
62
63    Work of the original authors of the Cone Search specification as well as
64    the numerous data providers who have implemented and continue to support
65    this protocol is kindly acknowledged.
66
67  \section*{Conformance-related definitions}  \section*{Conformance-related definitions}
68
# Line 62  Line 81
81
82  \section{Introduction}  \section{Introduction}
83
84  This specification describes how a provider of an astronomical source catalog can publish that catalog to the Virtual Observatory in such a way that a simple cone search can be done. The data remains in the control of the data provider, served through a web server to the world, but the query profile and response profile are carefully controlled, as described below. It is intended that setting up this web service be simple enough that data providers will not have to spend too much time on it (their funding to support such services is typically small). At the same time, the service implementation and the data it provides can serve as a basis for more sophisticated tools.  This specification describes how a provider of an astronomical source
85    catalog can publish that catalog to the Virtual Observatory in such a
86  This specification does not specify how cone search services are implemented, or how the data are stored or manipulated. The concern of this specification is how the data are exposed to the world through well-defined requests and responses.  way that a simple cone search can be done. The data remains in the
87    control of the data provider, served through a web server to the world,
88  This specification assumes that the data provider has already selected a catalog of astronomical sources. This catalog can be presented as a single table; it is expected that the table contains several columns.  but the query profile and response profile are carefully controlled, as
89    described below. It is intended that setting up this web service be
90    simple enough that data providers will not have to spend too much time
91    on it (their funding to support such services is typically small). At
92    the same time, the service implementation and the data it provides can
93    serve as a basis for more sophisticated tools.
94
95    This specification does not specify how cone search services are
96    implemented, or how the data are stored or manipulated. The concern of
97    this specification is how the data are exposed to the world through
98    well-defined requests and responses.
99
100    This specification assumes that the data provider has already selected a
101    catalog of astronomical sources. This catalog can be presented as a
102    single table; it is expected that the table contains several columns.
103
104  \subsection{Role within the VO Architecture}  \subsection{Role within the VO Architecture}
105
# Line 81  Line 114
114  % from FIGURES in the Makefile, too.  % from FIGURES in the Makefile, too.
115
116  \includegraphics[width=0.9\textwidth]{archdiag.png}  \includegraphics[width=0.9\textwidth]{archdiag.png}
117  \caption{Architecture diagram for SCS - TODO}  \caption{Architecture diagram for Simple Cone Search - TODO}
118  \label{fig:archdiag}  \label{fig:archdiag}
119  \end{figure}  \end{figure}
120
# Line 91  Line 124
124  \section{Resource}  \section{Resource}
125  \label{sec:resif}  \label{sec:resif}
126
127  A SCS service for accessing catalogue resources is implemented as a synchronous resource, as compliant as possible to the DALI specification \citep{std:DALI}.  A Simple Cone Search service for accessing catalogue resources is implemented as a
128    synchronous resource, as compliant as possible to the DALI specification
129    \citep{std:DALI}.
130
131  \begin{table}[th]  \begin{table}[th]
132  \begin{center}  \begin{center}
# Line 105  Line 140
140  \sptablerule  \sptablerule
141  \label{table:resources}  \label{table:resources}
142  \end{tabular}  \end{tabular}
143  \caption{SCS resources tree}  \caption{Simple Cone Search resources tree}
144  \end{center}  \end{center}
145  \end{table}  \end{table}
146
147  It \textbf{must} have one \{query\} resource and \textbf{should} have a VOSI-capability resource and a VOSI-availability one. The VOSI-capability \textbf{must} be a sibling to the \{query\} one.  It \textbf{must} have one \{query\} resource and \textbf{should} have a
148    VOSI-capability resource and a VOSI-availability one. The
149    VOSI-capability \textbf{must} be a sibling to the \{query\} one.
150
151  \subsection{\{query\} resource}  \subsection{\{query\} resource}
152  \label{sec:basepar}  \label{sec:basepar}
153  The SCS \{query\} resource \textbf{must} meet the following requirements:  The Simple Cone Search \{query\} resource \textbf{must} meet the following requirements:
154  \begin{itemize}  \begin{itemize}
155          \item the resource \textbf{must} respond to requests submitted using an HTTP GET query string, and \textbf{should} respond to HTTP POST query actions (as described in later in this same section);          \item the resource \textbf{must} respond to requests submitted using
156          \item the response, by default, \textbf{must} be a valid VOTable document, providing a table containing the sources of the catalogue whose positions are within the cone described in the query request (see Sec.~\ref{sec:response});  an HTTP GET query string, and \textbf{should} respond to HTTP POST query
157          \item in case of error, the response \textbf{must} follow prescriptions as described in Sec.~\ref{sec:error}.  actions (as described in later in this same section);
158            \item the response, by default, \textbf{must} be a valid VOTable
159    document, providing a table containing the sources of the catalogue
160    whose positions are within the cone described in the query request (see
161    Sec.~\ref{sec:response});
162            \item in case of error, the response \textbf{must} follow
163    prescriptions as described in Sec.~\ref{sec:error}.
164  \end{itemize}  \end{itemize}
165
166  The SCS service \texttt{\{query\}} resource is a synchronous web resource, as described by DALI, of the form  The Simple Cone Search service \texttt{\{query\}} resource is a synchronous web resource, as described by DALI, of the form
167  $$\hbox{\nolinkurl{http://<server>/<local_path>?} }$$  $$\hbox{\nolinkurl{http://<server>/<local_path>?} }$$
168  To this base URL the query parameters, described hereafter, are attached to build the query request to be submitted through HTTP.  To this base URL the query parameters, described hereafter, are attached to build the query request to be submitted through HTTP.
169
170  Usage of fixed, custom query parameters, defined by the service provider to build a base URL of the form  Usage of fixed, custom query parameters, defined by the service provider to build a base URL of the form
171  $$\hbox{\nolinkurl{http://<server>/<local_path>?<base\_query>&}}$$  $$\hbox{\nolinkurl{http://<server>/<local_path>?<base\_query>&}}$$
172  (standard behaviour of base URLs in SCS-1.03) is allowed but \textbf{deprecated} in order to bring cone searches base URLs in the common ReST shape promoted by DALI. Clients \textbf{must} anyway treat opaquely these fixed \texttt{<base\_query>} additions.  (standard behaviour of base URLs in Simple Cone Search-1.03) is allowed but \textbf{deprecated} in order to bring cone searches base URLs in the common ReST shape promoted by DALI. Clients \textbf{must} anyway treat opaquely these fixed \texttt{<base\_query>} additions.
173
174  In the case of HTTP POST action, the behaviour of SCS services having the deprecated base URL format (including custom extra parameters) is not specified. It is however suggested to adopt a mixed GET/POST solution, so the let the fixed \texttt{<base\_query>} arguments always be submitted in the query part of the HTTP request.  In the case of HTTP POST action, the behaviour of Simple Cone Search services having the deprecated base URL format (including custom extra parameters) is not specified. It is however suggested to adopt a mixed GET/POST solution, so the let the fixed \texttt{<base\_query>} arguments always be submitted in the query part of the HTTP request.
175
176  On the opposite, services having plain \texttt{\{query\}} base URLs as mandated by this specification are highly encouraged to support HTTP POST method in order to fulfill DALI compliance.  On the opposite, services having plain \texttt{\{query\}} base URLs as mandated by this specification are highly encouraged to support HTTP POST method in order to fulfill DALI compliance.
177
# Line 148  Line 191
191
192  \subsubsection{RESPONSEFORMAT}  \subsubsection{RESPONSEFORMAT}
193  \label{subsubsec:responseformat}  \label{subsubsec:responseformat}
194  An SCS service \textbf{must} provide responses in VOTable \citep{std:VOTABLE} format, compliant with respect to what will be detailed in Sec.~\ref{sec:response}, but \textbf{should} also support the DALI \textbf{RESPONSEFORMAT} parameter. Allowed media types for VOTable response \textbf{should} be the \texttt{application/x-votable+xml} or \texttt{text/xml} as specified by DALI but \texttt{text/xml;content=x-votable} may be considered legal for backward compatibility reasons.  An Simple Cone Search service \textbf{must} provide responses in VOTable
195    \citep{std:VOTABLE} format, compliant with respect to what will be
196    detailed in Sec.~\ref{sec:response}, but \textbf{should} also support
197    the DALI \textbf{RESPONSEFORMAT} parameter. Allowed media types for
198    VOTable response \textbf{should} be the
199    \texttt{application/x-votable+xml} or \texttt{text/xml} as specified by
200    DALI but \texttt{text/xml;content=x-votable} may be considered legal for
201    backward compatibility reasons.
202
203  \subsubsection{VERB}  \subsubsection{VERB}
204  The query \textbf{may} contain the optional single valued parameter, \textbf{VERB}, whose value is an integer (either 1, 2, or 3) indicating verbosity which determines how many columns are to be returned in the resulting table. If the service supports the parameter, then when the value is 1, the response should include the bare minimum of columns that the provider considers useful in describing the returned objects (while still remaining compliant with this standard; see section \ref{sec:response} below). When the value is 3, the service should return all of the columns that are available for describing the objects. A value of 2 is intended for requesting a medium number of columns between the minimum and maximum (inclusive) that are considered by the provider to most typically useful to the user. When the VERB parameter is not provided, the server should respond as if VERB=2. If the VERB parameter is not supported by the service, the service should ignore the parameter and should always return the same set of columns for every request.  The query \textbf{may} contain the optional single valued parameter, \textbf{VERB}, whose value is an integer (either 1, 2, or 3) indicating verbosity which determines how many columns are to be returned in the resulting table. If the service supports the parameter, then when the value is 1, the response should include the bare minimum of columns that the provider considers useful in describing the returned objects (while still remaining compliant with this standard; see section \ref{sec:response} below). When the value is 3, the service should return all of the columns that are available for describing the objects. A value of 2 is intended for requesting a medium number of columns between the minimum and maximum (inclusive) that are considered by the provider to most typically useful to the user. When the VERB parameter is not provided, the server should respond as if VERB=2. If the VERB parameter is not supported by the service, the service should ignore the parameter and should always return the same set of columns for every request.
# Line 159  Line 209
209
210  \subsection{Query examples}  \subsection{Query examples}
211  \begin{bigdescription}  \begin{bigdescription}
214  \item[Limit number of records in response] \nolinkurl{http://my.cone/search?RA=10.68\&DEC=41.26\&SR=1\&MAXREC=100}  \item[Limit number of records in response] \nolinkurl{http://my.cone/search?RA=10.68\&DEC=41.26\&SR=1\&MAXREC=100}
216  \end{bigdescription}  \end{bigdescription}
217
218  \subsection{Availability: VOSI-availability}  \subsection{Availability: VOSI-availability}
219  A web service with SCS capabilities \textbf{should} have a VOSI-availability resource as described in DALI. Since VOSI relaxed the availability endpoint, letting it be located elsewhere than being a sibling to the service base URL, support for this interface is encouraged even in the case of services having base URL of the deprecated form.  A web service with Simple Cone Search capabilities \textbf{should} have a VOSI-availability resource as described in DALI. Since VOSI relaxed the availability endpoint, letting it be located elsewhere than being a sibling to the service base URL, support for this interface is encouraged even in the case of services having base URL of the deprecated form.
220
221  \subsection{Capabilities: VOSI-capabilities}  \subsection{Capabilities: VOSI-capabilities}
222  A web service with SCS capabilities must have a VOSI-capabilities resource as described in DALI. The standardID for the {query} capability is reported, among other details and recommendations in Sec.~\ref{subsec:capability}.  A web service with Simple Cone Search capabilities must have a VOSI-capabilities resource as described in DALI. The standardID for the {query} capability is reported, among other details and recommendations in Sec.~\ref{subsec:capability}.
223
224  Services that present the \texttt{\{query\}} base URL as a plain ReST resource without additional opaque query parameters are strongly encouraged to provide a capabilities endpoint as a sibling to the \texttt{\{query\}} resource. The capabilities resource may be unfeasible to maintain for services exposing a base URL with the deprecated format.  Services that present the \texttt{\{query\}} base URL as a plain ReST resource without additional opaque query parameters are strongly encouraged to provide a capabilities endpoint as a sibling to the \texttt{\{query\}} resource. The capabilities resource may be unfeasible to maintain for services exposing a base URL with the deprecated format.
225
# Line 185  Line 235
235
236  In the case the service response is serialised in the default, VOTable, format, this response \textbf{MUST} comply with the following requirements.  In the case the service response is serialised in the default, VOTable, format, this response \textbf{MUST} comply with the following requirements.
237
238  There \textbf{must} be a single \xmlel{RESOURCE} with \xmlel{type}=\texttt{"results"}\todo{Do current cone services use this attribute? Update: no, most SCS-1.03 services do not.} in the VOTable, and containing a single \xmlel{TABLE}\todo{should we relax on the number of tables? Discuss this with apps.}.  There \textbf{must} be a single \xmlel{RESOURCE} with \xmlel{type}=\texttt{"results"}\todo{Do current cone services use this attribute? Update: no, most Simple Cone Search-1.03 services do not.} in the VOTable, and containing a single \xmlel{TABLE}\todo{should we relax on the number of tables? Discuss this with apps.}.
239
240  The \xmlel{TABLE} \textbf{must} have \xmlel{FIELD}s where the following UCD values have been set. There \textbf{must} only be one \xmlel{FIELD} with each of these UCDs:  The \xmlel{TABLE} \textbf{must} have \xmlel{FIELD}s where the following UCD values have been set. There \textbf{must} only be one \xmlel{FIELD} with each of these UCDs:
241  \begin{itemize}  \begin{itemize}
# Line 209  Line 259
259
260  The service \textbf{may} also return an error if the search radius (given by the SR parameter) is larger than the one set by the \xmlel{maxSR} element child of the \xmlel{capability} one of the service described as a VO resource (see Sec.~\ref{sec:regext}).  The service \textbf{may} also return an error if the search radius (given by the SR parameter) is larger than the one set by the \xmlel{maxSR} element child of the \xmlel{capability} one of the service described as a VO resource (see Sec.~\ref{sec:regext}).
261
262  The service \textbf{may}, as an alternative, report exceptions using the profile expressed by the previous SCS recommendation \citep[v1.03]{std:SCS}. This alternative for error reporting is to be considered \textbf{deprecated}, being the purpose of this specification to fill in the gap of the SCS protocol with the general DAL landscape. The way the alternative works is detailed in Sec.~\ref{subsec:err103} here below.  The service \textbf{may}, as an alternative, report exceptions using the
263    profile expressed by the previous Simple Cone Search recommendation
264    \citep[v1.03]{std:SCS}. This alternative for error
265    reporting is to be considered \textbf{deprecated}, being the purpose of
266    this specification to fill in the gap of the Simple Cone Search protocol
267    with the general DAL landscape. The way the alternative works is
268    detailed in Sec.~\ref{subsec:err103} here below.
269
270  \subsection{(\textbf{deprecated}) Alternative Error Response}  \subsection{(\textbf{deprecated}) Alternative Error Response}
271  \label{subsec:err103}  \label{subsec:err103}
# Line 257  Line 313
313  The content of \textbf{Section \ref{sec:regext}} is taken from REC-SimpleDALRegExt-1.1, sections 1, 2 and 3, specifically section 3.1 that is dedicated to the Simple Cone Search case.  The content of \textbf{Section \ref{sec:regext}} is taken from REC-SimpleDALRegExt-1.1, sections 1, 2 and 3, specifically section 3.1 that is dedicated to the Simple Cone Search case.
315
316  To adequately describe that a service supports the Simple Cone Search protocol, it is necessary to define SCS specific capability metadata. This is needed both to allow discovery of cone search services within VO registered resources (through the Registry Interfaces standard, \citet{std:RI1}, deploying VOResource documents, \citet{std:VOR}) and to generally describe service behaviour to help applications consume it properly, given compliance to the protocol.  To adequately describe that a service supports the Simple Cone Search
317    protocol, it is necessary to define Simple Cone Search specific
318  This section specifies these metadata for cone search resources and is intended to be applicable wherever VOResource records are used, in particular for standard encoding of resource descriptions within IVOA registries and for encoding capability metadata available through VOSI \citep{std:VOSI11} interfaces.  capability metadata. This is needed both to allow discovery of cone
319    search services within VO registered resources (through the Registry
320    Interfaces standard, \citet{std:RI1}, deploying VOResource documents,
321    \citet{std:VOR}) and to generally describe service behaviour to help
322    applications consume it properly, given compliance to the protocol.
323
324    This section specifies these metadata for cone search resources and is
325    intended to be applicable wherever VOResource records are used, in
326    particular for standard encoding of resource descriptions within IVOA
327    registries and for encoding capability metadata available through VOSI
328    \citep{std:VOSI11} interfaces.
329
330  Apart from the above standards referenced here above, this registry extension depends on the VODataService \citep{std:VODS11} standard.  Apart from the above standards referenced here above, this registry
331    extension depends on the VODataService \citep{std:VODS11} standard.
332
333  \subsection{Resource record and Capability requirements}  \subsection{Resource record and Capability requirements}
334  To be recognized as a SCS, the service resource must be described as a resource of type \xmlel{vr:Service} (defined in the VOResource schema) or one of its legal sub-types. The resource type is set by setting the \xmlel{xsi:type} attribute on the element representing the root of the VOResource record to the namespace-qualified resource type name. SCS \textbf{should} be of the resource type \xmlel{vs:CatalogService} (defined in the VODataService extension schema)\footnote{\xmlel{vr:} and \xmlel{vs:} are the canonical prefixes for the namespaces associated with VOResource and VODataService XML schemata}.  To be recognized as a Simple Cone Search, the service resource must be described as a resource of type \xmlel{vr:Service} (defined in the VOResource schema) or one of its legal sub-types. The resource type is set by setting the \xmlel{xsi:type} attribute on the element representing the root of the VOResource record to the namespace-qualified resource type name. Simple Cone Search \textbf{should} be of the resource type \xmlel{vs:CatalogService} (defined in the VODataService extension schema)\footnote{\xmlel{vr:} and \xmlel{vs:} are the canonical prefixes for the namespaces associated with VOResource and VODataService XML schemata}.
335
336  Since the \xmlel{vs:CatalogService} resource type allows it, record authors are encouraged to include a full description of the columns in the table returned in query response (assuming full verbosity), as well as to provide sky coverage information.  Since the \xmlel{vs:CatalogService} resource type allows it, record authors are encouraged to include a full description of the columns in the table returned in query response (assuming full verbosity), as well as to provide sky coverage information.
337
# Line 272  Line 339
339  \label{subsec:capability}  \label{subsec:capability}
340  The VOResource record \textbf{must} include a \xmlel{capability} element that \textbf{must} have a \xmlel{standardID} attribute set to  The VOResource record \textbf{must} include a \xmlel{capability} element that \textbf{must} have a \xmlel{standardID} attribute set to
341  $$\hbox{\nolinkurl{ivo://ivoa.net/std/conesearch#query-1.1}}$$  $$\hbox{\nolinkurl{ivo://ivoa.net/std/conesearch#query-1.1}}$$
342  to unambiguously identify the resource as a Simple Cone Search compliant to SCS-1.1 version. The \xmlel{capability} \textbf{should} also have \xmlel{xsi:type="cs:ConeSearch"} to specialize the \xmlel{vr:Capability} to be of the specific sub-type supporting the cone search protocols. The \xmlel{cs:} here refers to the canonical prefix for the namespace associated with the SCS extension schema, that is  to unambiguously identify the resource as a Simple Cone Search compliant to Simple Cone Search-1.1 version. The \xmlel{capability} \textbf{should} also have \xmlel{xsi:type="cs:ConeSearch"} to specialize the \xmlel{vr:Capability} to be of the specific sub-type supporting the cone search protocols. The \xmlel{cs:} here refers to the canonical prefix for the namespace associated with the Simple Cone Search extension schema, that is
343  $$\hbox{\nolinkurl{http://www.ivoa.net/xml/ConeSearch/v1.0} ,}$$  $$\hbox{\nolinkurl{http://www.ivoa.net/xml/ConeSearch/v1.0} ,}$$
344  the same as for SCS-1.03, as explained in the XML Schema Versioning \citep{note:schemaversioning} document; distinction among the two schemata version being delivered by the \xmlel{version} attribute in the schema root element.  the same as for Simple Cone Search-1.03, as explained in the XML Schema
345    Versioning \citep{note:schemaversioning} document; distinction among the
346    two schemata version being delivered by the \xmlel{version} attribute in
347    the schema root element.
348
349  The \xmlel{cs:ConeSearch} type is described in Sec.~\ref{subsec:cstype}.  The \xmlel{cs:ConeSearch} type is described in Sec.~\ref{subsec:cstype}.
350
# Line 400  Line 470
470  % /GENERATED  % /GENERATED
471
472  The custom metadata that the \xmlel{cs:ConeSearch} type provides is given  The custom metadata that the \xmlel{cs:ConeSearch} type provides is given
473  above. Other genaral metadata useful to describe the SCS  above. Other genaral metadata useful to describe the Simple Cone Search
474  specification are directly part of the core VOResource schema.  specification are directly part of the core VOResource schema.
475
476  \subsubsection{testQuery and the Query Type}  \subsubsection{testQuery and the Query Type}
# Line 420  Line 490
490  \begin{generated}  \begin{generated}
491  \begingroup  \begingroup
493          \hbox to 5.5em{\emph{#1}\hfil}}\vspace{2ex}\noindent\textbf{\xmlel{cs:Query} Type Schema Documentation}                                  \hbox to
494    5.5em{\emph{#1}\hfil}}\vspace{2ex}\noindent\textbf{\xmlel{cs:Query} Type
495    Schema Documentation}
496
497  \noindent{\small  \noindent{\small
498              A query to be sent to the service              A query to be sent to the service
# Line 605  Line 677
677          \item Added DALI MAXREC and RESPONSEFORMAT          \item Added DALI MAXREC and RESPONSEFORMAT
678          \item Added POST as optional HTTP query method          \item Added POST as optional HTTP query method
680          \item Plain porting of the HTML document into ivoatex template, including change history, then modified it and reshaped.          \item Plain porting of the HTML document into ivoatex template,
681    including change history, then modified it and reshaped.
682  \end{itemize}  \end{itemize}
683
684  \subsection{Changes from PR-1.02}  \subsection{Changes from PR-1.02}
# Line 615  Line 688
688
689  \subsection{Changes from PR-1.01}  \subsection{Changes from PR-1.01}
690  \begin{itemize}[noitemsep]  \begin{itemize}[noitemsep]
691          \item eliminated the choice of encoding an ERROR response in a PARAM that is a direct child of VOTABLE as this is not legal in the VOTable schema.          \item eliminated the choice of encoding an ERROR response in a PARAM
692    that is a direct child of VOTABLE as this is not legal in the VOTable
693    schema.
694          \item Allowed the use of the INFO element for error messages.          \item Allowed the use of the INFO element for error messages.
695          \item In examples, made sure PARAM elements have datatype attributes          \item In examples, made sure PARAM elements have datatype attributes
696          \item Corrected wording to be definitive that positions are given in the ICRS coordinate system.          \item Corrected wording to be definitive that positions are given in the ICRS coordinate system.
# Line 638  Line 713
713
714  \subsection{Changes from the original NVO Specification Document}  \subsection{Changes from the original NVO Specification Document}
715  \begin{itemize}[noitemsep]  \begin{itemize}[noitemsep]
716          \item References to the original HTML document have been replaced with references to this IVOA specification.          \item References to the original HTML document have been replaced with
717    references to this IVOA specification.
718          \item Replaced references to "curator" with "data provider" or similar wording.          \item Replaced references to "curator" with "data provider" or similar wording.
719          \item Replaced references to the NVO with references either to the IVOA or this specification, as appropriate.          \item Replaced references to the NVO with references either to the IVOA or this specification, as appropriate.
720          \item Ambiguous language like "perhaps" has been replaced with more definitive wording where appropriate. Use of the word "will" is replaced with "must" and "can" with "may", in accordance with the definitions set in the preface.          \item Ambiguous language like "perhaps" has been replaced with more definitive wording where appropriate. Use of the word "will" is replaced with "must" and "can" with "may", in accordance with the definitions set in the preface.
# Line 663  Line 739
739          \item An appendix has been added to describe the current practice for registering Cone Search services.          \item An appendix has been added to describe the current practice for registering Cone Search services.
740  \end{itemize}  \end{itemize}
741
742  \bibliography{ivoatex/ivoabib,ivoatex/docrepo,scs}  \bibliography{ivoatex/ivoabib,ivoatex/docrepo,ConeSearch}
743
744
745  \end{document}  \end{document}

Legend:
 Removed from v.5689 changed lines Added in v.5690