# [Volute] r4105 - trunk/projects/dal/SCS

Volute commit messages volutecommits at g-vo.org
Fri May 26 08:53:24 CEST 2017

Author: molinaro
Date: Fri May 26 08:53:22 2017
New Revision: 4105

Log:
SCS - initial commit with ivoatex porting - MMo

trunk/projects/dal/SCS/Makefile   (contents, props changed)
trunk/projects/dal/SCS/REC-SCS-1.03-20080222.html   (contents, props changed)
trunk/projects/dal/SCS/SCS.tex   (contents, props changed)
trunk/projects/dal/SCS/archdiag.png   (contents, props changed)
trunk/projects/dal/SCS/scs.bib   (contents, props changed)
Modified:
trunk/projects/dal/SCS/   (props changed)

==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/projects/dal/SCS/Makefile	Fri May 26 08:53:22 2017	(r4105)
@@ -0,0 +1,28 @@
+# ivoatex Makefile.  The ivoatex/README for the targets available.
+
+# short name of your document (edit $DOCNAME.tex; would be like RegTAP) +DOCNAME = SCS + +# count up; you probably do not want to bother with versions <1.0 +DOCVERSION = 1.1 + +# Publication date, ISO format; update manually for "releases" +DOCDATE = 2017-06-21 + +# What is it you're writing: NOTE, WD, PR, REC, PEN, or EN +DOCTYPE = WD + +# Source files for the TeX document (but the main file must always +# be called$(DOCNAME).tex
+SOURCES = \$(DOCNAME).tex
+
+# List of pixel image files to be included in submitted package
+FIGURES = archdiag.png
+
+# List of PDF figures (for vector graphics)
+VECTORFIGURES =
+
+# Additional files to distribute (e.g., CSS, schema files, examples...)
+AUX_FILES =
+
+include ivoatex/Makefile

==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/projects/dal/SCS/README	Fri May 26 08:53:22 2017	(r4105)
@@ -0,0 +1,13 @@
+Simple Cone Search - source repository
+
+This ivoatex SCS source repo was started out of the HTML version of
+REC-SCS-1.03-20080222.html (that for this reason is preserved in this
+source bundle).
+
+Initial porting, whose goal was to bring the specification to revision
+1.1  has been a plain transposition of the HTML into LaTeX, and includes
+all of the history changes that the original document listed in appendix.
+Porting tried to be as faithful as possible, given broken links and
+references, styling issues and so. However the goal was not to produce
+as one-to-one ivoatex SCS-1.03, but to form a basis to start the
+revision from.

==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/projects/dal/SCS/REC-SCS-1.03-20080222.html	Fri May 26 08:53:22 2017	(r4105)
@@ -0,0 +1,1182 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html>
+<title>Cone Search (Recommendation)</title>
+
+<script type="text/javascript" src="/misc/jquery-1.2.6.min.js"></script>
+<script type="text/javascript" src="/misc/generated-toc.js"></script>
+
+<style type="text/css">
+    .issue {background-color: yellow}
+    .postponedissue {background-color: yellow}
+    .def code
+    .future {background-color: pink}
+    .draftedit {background-color: white}
+    .draftdelete {background-color: white}
+    .note { margin-left: 4em }
+
+div.exampleInner pre { margin-left: 1em;
+                       margin-top: 0em; margin-bottom: 0em}
+div.exampleOuter {border: 4px double gray;
+div.exampleInner { border-top-width: 4px;
+                   border-top-style: double;
+                   border-top-color: white;
+                   border-bottom-width: 4px;
+                   border-bottom-style: double;
+                   border-bottom-color: white;
+                   padding: 0px; margin: 0em }
+div.exampleWrapper { margin: 4px }
+                    margin: 4px}
+</style>
+
+<body>
+
+<a href="http://www.ivoa.net/"><img alt="IVOA" src="http://www.ivoa.net/pub/images/IVOA_wb_300.jpg"
+   width="300" height="169"></a>
+
+<h1>Simple Cone Search<br />
+Version 1.03</h1>
+<h2>IVOA Recommendation
+22 February 2008</h2>
+
+<dl>
+
+  <dt>This version:</dt>
+  <dd><a href="http://www.ivoa.net/Documents/REC/DAL/ConeSearch-20080222.html">
+      http://www.ivoa.net/Documents/REC/DAL/ConeSearch-20080222.html</a></dd>
+
+  <dd><a href="http://www.ivoa.net/Documents/latest/ConeSearch.html">
+      http://www.ivoa.net/Documents/latest/ConeSearch.html</a></dd>
+
+  <dt>Previous versions:</dt>
+  <dd><a href="http://www.ivoa.net/Documents/PR/DAL/ConeSearch-20070914.html">
+      http://www.ivoa.net/Documents/PR/DAL/ConeSearch-20070914.html</a></dd>
+  <dd><a href="http://www.ivoa.net/Documents/PR/DAL/ConeSearch-20070628.html">
+      http://www.ivoa.net/Documents/PR/DAL/ConeSearch-20070628.html</a></dd>
+  <dd><a href="http://www.ivoa.net/Documents/PR/DAL/ConeSearch-20060908.html">
+      http://www.ivoa.net/Documents/PR/DAL/ConeSearch-20060908.html</a><br />
+  </dd>
+
+  <br/>
+
+  <dt>Working Group:</dt>
+  <dt>Editor:</dt>
+  <dd><a href="http://www.ivoa.net/twiki/bin/view/IVOA/RayPlante">
+      Raymond Plante</a>
+  <dt>Authors:</dt>
+  <dd><a href="http://www.ivoa.net/twiki/bin/view/IVOA/RoyWilliams">
+      Roy Williams</a><br>
+      <a href="http://www.ivoa.net/twiki/bin/view/IVOA/BobHanisch">
+      Robert Hanisch</a><br>
+      <a href="http://www.ivoa.net/twiki/bin/view/IVOA/AlexSzalay">
+      Alex Szalay</a><br>
+      <a href="http://www.ivoa.net/twiki/bin/view/IVOA/RayPlante">
+      Raymond Plante</a></dd>
+</dl>
+
+<hr>
+</div>
+
+<h2><a name="abstract" id="abstract">Abstract</a></h2>
+
+This specification defines a simple query protocol for retrieving records
+from a catalog of astronomical sources.  The query describes 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 of
+the specification is essentially a transcription of the original Cone
+Search specification in order to move it into the IVOA standardization
+process.
+
+<div class="status">
+<h2><a name="status" id="status">Status of this document</a></h2>
+
+<p>
+This document has been produced by the IVOA Resource Registry Working
+Group.<br/>
+It has been reviewed by IVOA Members and other interested parties, and
+has been endorsed by the IVOA Executive Committee as an IVOA
+Recommendation as of 2007 September 27. It is a stable document and
+may be used as reference material or cited as a normative reference
+from another document. IVOA's role in making the Recommendation is to
+draw attention to the specification and to promote its widespread
+deployment. This enhances the functionality and interoperability
+inside the Astronomical Community.
+</p>
+
+<p>
+This document was originally published as a document of the
+<a href="http://www.us-vo.org/">US National Virtual Observatory</a>
+(NVO), available at
+<a href="http://us-vo.org/pubs/files/conesearch.html">http://us-vo.org/pubs/files/conesearch.html</a>.
+This IVOA version is essentially a transcription of that document into
+the IVOA standards document format.  Minor changes have been made to sharpen
+the specification description where needed and to otherwise fit it
+into the IVOA standards context; these changes are enumerated in
+<a href="#appA">Appendix C</a>.  It is the intention of this document
+that <strong>all existing services compliant with the original NVO
+document will be compliant with this specification</strong>.
+Similarly, all future service implementations that are based on this
+specification are expected to be compliant with the spirit of the
+original NVO document and practices in the VO current at the time of
+this writing; thus, existing client applications should work with the
+new implementations without change.
+</p>
+
+<p>
+Comments on this document can be sent to the Data Access Layer Working
+Group via <a href="mailto:dal at ivoa.net">dal at ivoa.net</a>.
+</p>
+
+<p>
+A list of <a href="http://www.ivoa.net/Documents/">current IVOA
+Recommendations and other technical documents</a> can be found at
+http://www.ivoa.net/Documents/.
+</p>
+
+<h2><a id="acknowledge" name="acknowledge">Acknowledgments</a></h2>
+
+<p>Cone Search represents the first and arguably the most successful
+"standard protocol" developed within the Virtual Observatory
+movement.  The editor, therefore, gratefully acknowledges the 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.</p>
+
+<p>This document has been developed with support from the <a
+href="http://www.nsf.gov">National Science Foundation's</a>
+Information Technology Research Program under Cooperative Agreement
+AST0122449 with The Johns Hopkins University.</p>
+
+<a name="conf">
+<h3>Conformance-related definitions</h3></a>
+
+<p>The words "MUST", "SHALL", "SHOULD", "MAY", "RECOMMENDED", and
+"OPTIONAL" (in upper or lower case) used in this document are to be
+interpreted as described in IETF standard, RFC 2119
+<a href="#should">[RFC 2119]</a>.  </p>
+
+<p>The <a name="d:vo"><strong>Virtual Observatory (VO)</strong></a> is
+general term for a collection of federated resources that can be used
+to conduct astronomical research, education, and outreach.
+<a name="d:ivoa">The</a> <a href="http://www.ivoa.net"><strong>International
+Virtual Observatory Alliance (IVOA)</strong></a> is a global
+collaboration of separately funded projects to develop standards and
+infrastructure that enable VO applications. </p>
+
+<p><a name="d:cone">A <strong>Cone</strong></a> is a circular region
+on the sky defined by a sky position and a radius around that
+position.  A <a name="d:cs"><strong>Cone Search</strong></a> is a
+query for information related to a Cone.  The <a name="d:csp">
+<strong>Cone Search Protocol</strong></a> refers to the protocol
+described in this document.  A <a name="d:css"><strong> Cone Search
+Service</strong></a> is a service implementation that complies with
+this standard.  </p>
+
+<!--
+<a name="synnot">
+<h3>Syntax Notation</h3></a>
+
+<p>This document uses the Augmented Backus-Naur Form (ABNF) notation
+(<a href="#abnf">RFC 2234</a>) to formally define syntax for the query
+syntax.  It references the following core ABNF syntax productions
+(defined in section 6.1): ALPHA, DIGIT.  </p>
+  -->
+
+<h2><a id="contents" name="contents">Contents</a></h2>
+<ul class="toc">
+  <li><a href="#abstract">Abstract</a></li>
+  <li><a href="#status">Status of this document</a></li>
+  <li><a href="#acknowledge">Acknowledgments</a></li>
+  <li><a href="#conf">Conformance-related definitions</a></li>
+<!--
+  <li><a href="#synnot">Syntax Notation</a></li>
+  -->
+  <li><a href="#intro">1. Introduction</a>
+  <li><a href="#req">2. Service Interface Requirements</a>
+  <li><a href="#prof">3. The Resource Profile</a>
+  <li><a href="#appA">Appendix A: Sample VOTable Response
+  <li><a href="#appB">Appendix B: Current Practices for Representing
+       Resource Profiles</a></li>
+  <li><a href="#appC">Appendix C: Changes History</a>
+       <ul>
+         <li> <a href="#appC1">C.1. Changes From the Original NVO
+              Specification Document</a></li>
+         <li> <a href="#appC2">C.2. Changes From Previous IVOA Versions</a></li>
+       </ul>
+  <li><a href="#References">References</a></li>
+</ul>
+<hr>
+
+<h2><a name="intro">1. Introduction</a></h2>
+
+<p>
+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.
+</p>
+
+<p>
+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.
+</p>
+
+<p>
+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.
+</p>
+
+<a name="req">
+<h2>2.  Service Interface Requirements</h2></a>
+
+A service implementation that is compliant with this standard must
+meet the following requirements:
+
+<ol>
+  <li> the service must respond to a HTTP GET request represented by a
+       URL having two parts:
+       <ul>
+
+         <li> <p>A base URL of the form:</p>
+
+              <p>
+
+              </p>
+
+              <p>
+              <i><path></i> are URI-compliant components
+              indicating the domain address and local location path
+              where the service is deployed.  The
+              <i><server-address></i> may end with one or more
+              locally supported URL arguments, <i><extra-GET-arg></i>;
+              these arguments are not recognized parts of the Cone Search
+              protocol and thus are treated opaquely by clients of the
+              service as part of the base URL.
+              </p>
+
+              <p>
+              Note that when it contains extra GET arguments, the base
+              URL ends in an ampersand, <strong>&</strong>; if
+              there are no extra arguments, then it ends in a question
+              mark, <strong>?</strong>.
+              </p>
+
+              <p>
+
+          <TBODY>
+          <TR>
+            <TD>
+              <DL>
+                <DT><STRONG>Examples:</STRONG>
+                <DD><TT>http://mycone.org/cgi-bin/VOsearch? <BR>
+                </DD>
+              </DL>
+            </TD>
+
+          </TR>
+          </TBODY>
+        </TABLE>
+              </p>
+
+              <p>Every query to a given cone search service uses the same
+              base URL.</p>
+
+         <li> <p>Constraints expressed as a list of ampersand-delimited
+              GET arguments of the form: <br>
+
+              <i><name></i><b>=</b><i><value></i>
+              </p>
+
+              <p>
+              where <i><name></i> is a parameter name specified
+              by this specification and <i><value></i> is its
+              value.  The constraints represent the query parameters which
+              can vary for each successive query.  The order of the
+              name-parameter pairs is not significant.
+              </p>
+
+         <li> <P>The baseURL and constraint list are concatenated to form
+              the query.  </P>
+
+         <li> <p><a name="p:req">
+              The set of query constraints must include the following
+              parameters</a>, which are interpreted by the service with
+	      the stated meaning:
+
+              <ul>
+                <li><a name="p:RA"><b>RA</b></a> -- a right-ascension
+                     in the ICRS coordinate system for the positon of
+                     the center of the cone to search, given in
+                     decimal degrees. </li>
+                <li><a name="p:DEC"><b>DEC</b></a> -- a declination in
+                     the ICRS coordinate system for the positon of
+                     the center of the cone to search, given in
+                     decimal degrees. </li>
+                <li><a name="p:SR"><b>SR</b></a> -- the radius of the
+                     cone to search, given in decimal degrees. </li>
+              </ul></p>
+
+              <p>
+	  <TBODY>
+	  <TR>
+	    <TD>
+	      <DL>
+		<DT><STRONG>Example:</STRONG>
+		<DD><TT>http://mycone.org/cgi-bin/search?RA=180.567&DEC=-30.45&SR=0.0125
+		  </tt></DD>
+
+	      </DL>
+	    </TD>
+	  </TR>
+	  </TBODY>
+	</TABLE>
+              </p>
+
+         <li> <p>The query MAY contain the optional parameter,
+              <a name="p:VERB"><strong>VERB</strong></a>, 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.  Support for this parameter by a
+              Cone Search service implementation is optional.  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 <a href="#response">section
+              2.2</a> 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 columns for
+              every request.  </p> </li>
+
+         <li> <p>There may be other parameters in the query, but this
+              document does not specify their meaning or usage.  If a
+              query includes an optional parameter, either one
+              specified by this document or not, that is not supported
+              by the service implementation, the service must ignore
+              that parameter.</p>  </li>
+       </ul>
+
+       A query following this syntax represents a request for
+       information on sources located within the specified cone on the
+       sky.
+
+  <li> <p><a name="resp"></a>The service must respond with an XML
+       document in the VOTable format, that represents a table of
+       astronomical sources whose positions are within the cone (see
+       <a href="#appA">Appendix A</a> for an example).  There may also
+       be other sources outside the cone -- the service implementor
+       may decide on the exact search criterion used internally to the
+       service to select the sources.</p>  </li>
+
+       <p>
+       The base MIME-type of the HTTP response should be <TT>text/xml</TT>.
+       The more specific form <TT>text/xml;content=x-votable</TT> may
+       optionally be used.  The MIME-type, <tt>text/xml;votable</tt>
+       shall also be considered legal (for backward compatibility
+       reasons); however, this value is strongly discouraged as it is
+       not compliant with the MIME-type standard [<a href="#mime">MIME</a>].
+       The XML content of the response must be compliant with VOTable
+       schema, version 1.0 [<a href="#vot10">VOTable v1.0</a>] or 1.1
+       [<a href="#vot11">VOTable v1.1</a>].
+       </p>
+
+<blockquote>
+<dl>
+  <dt> <strong>Editor's Note:</strong> </dt>
+  <dd> The original NVO specification allowed a MIME-type of
+       <tt>text/xml;votable</tt>, thus for backward compatibility this
+       is still allowed but discouraged.  </dd>
+</dl>
+</td></tr></tbody></table>
+</blockquote>
+
+       <p>The VOTable MUST comply with these conditions:</p>
+
+       <ul>
+
+         <li> <p>There must be a single RESOURCE in the VOTable, and
+              that contains a single TABLE.</p> </li>
+
+         <li> <p>The TABLE must have FIELDS where the following UCD
+              [<a href="http://vizier.u-strasbg.fr/UCD">UCD</A>] values
+              have been set.  There must only be one FIELD with each of
+              these UCDs: </p> </li>
+
+              <ul>
+                <li> <p>Exactly one FIELD must have ucd="ID_MAIN", with
+                     an array character type (fixed or variable length),
+                     representing an ID string for that record of the
+                     table. This identifier may not be repeated in the
+                     table, and it could be used to retrieve that same
+                     record again from that same table.</p>  </li>
+
+                <li> <p>Exactly one FIELD must have ucd="POS_EQ_RA_MAIN",
+                     with type double, representing the
+                     right-ascension of the source in the ICRS
+                     coordinate system. </p> </li>
+
+                <li> <p>Exactly one FIELD must have ucd="POS_EQ_DEC_MAIN",
+                     with type double, representing the declination of
+                     the source in the ICRS coordinate system. <p> </li>
+              </ul>
+
+         <li> <p> The VOTable may include an expression of the uncertainty
+              of the positions given in the above mentioned
+              fields to be interpreted either as a positional error of
+              the source positions, or an angular size if the
+              sources are resolved.  If this uncertainty is not
+              provided, it should be taken to be zero; otherwise, it
+              may be set for all table entries with a PARAM in the
+              RESOURCE which has a UCD that is set to OBS_ANG-SIZE and
+              has a value which is the angle in decimal degrees.
+              Alternatively, a different value for each row in the
+              table can be given via a FIELD in the table having a UCD
+              set to OBS_ANG-SIZE. </p> </li>
+
+         <li> <p> There may be other FIELDs in the table.  Their
+              specification should include a description, data-type,
+              and UCD.  </p> </li>
+       </ul>
+
+  <li> <p> The service must respond with a stubbed version of the
+       VOTable in the case of error.  This must happen if the three
+       <a href="#p:req">required parameters</a> (RA, DEC, SR) are not
+       all present, or if their values cannot be parsed to
+       floating-point numbers, or if the numbers are out of range
+       (DEC=91.0, for example).  The service may also make an error
+       return if the search radius (give by the <a href="p:SR">SR</a>
+       parameter) is larger than the MaxSR parameter of the Resource
+       Profile (see <a href="prof">Section 3</a>). </p> </li>
+
+       <P> In the case of error, the service MUST respond with a
+       VOTable that contains a single PARAM element <em>or</em> a
+       single INFO element with <B><code>name="Error"</code></B>,
+       where the corresponding value attribute should contain some
+       explanation of the nature of the error.  If an INFO element is
+       used, it must appear as a direct child of one of the following
+       elements: </p>
+
+       <ul>
+         <li> the root VOTABLE element (which is preferred by this
+              document), or
+         <li> the RESOURCE element </li>
+       </ul>
+
+       <p>If a PARAM element is used, it must appear as a direct child of
+       one of following elements: </p>
+
+       <ul>
+         <li> the RESOURCE element, or </li>
+         <li> a DEFINITION element below the root
+              VOTABLE element (which is discouraged by this document).   </li>
+       </ul>
+
+<blockquote>
+<dl>
+  <dt> <strong>Editor's Note:</strong> </dt>
+  <dd> It was recognized that this requirement, as it was described in
+       the original NVO specification, is ambiguous about both the
+       element to use for the ERROR message and its location in the document.
+       The VOTable standard allows PARAM and INFO elements to appear in
+       various places within the document.  Since several of the
+       different methods have been used in practice by
+       Cone Search service implementations, no attempt is made in this
+       version to correct this ambiguity.  All of the above-mentioned
+       locations should be considered legal, and Cone Search service
+       clients should be prepared to look in all of them for an ERROR
+       message.  The use of PARAM as a child of DEFINITIONS is
+       discouraged as the DEFINITIONS element was deprecated in
+       VOTable v1.1.</dd>
+</dl>
+</td></tr></tbody></table>
+</blockquote>
+
+<div class="exampleOuter">
+<a name="ex:errors"></a>
+<div class="exampleWrapper"><a name="ex:votable">Error INFO as child
+of VOTABLE (preferred)</a></div>
+<div class="exampleInner" style="background-color: rgb(213, 222, 227);">
+<pre><?xml version="1.0"?>
+<!DOCTYPE VOTABLE SYSTEM "http://us-vo.org/xml/VOTable.dtd">
+<VOTABLE version="1.0">
+  <DESCRIPTION>MAST Simple Cone Search Service</DESCRIPTION>
+  <INFO ID="Error" name="Error" value="Error in input RA value: as3f"/>
+</VOTABLE>
+</pre>
+</div>
+<div class="exampleWrapper"><a name="ex:votable">Error PARAM as child
+of RESOURCE (allowed)</a></div>
+<div class="exampleInner" style="background-color: rgb(213, 222, 227);">
+<pre><?xml version="1.0"?>
+<!DOCTYPE VOTABLE SYSTEM "http://us-vo.org/xml/VOTable.dtd">
+<VOTABLE version="1.0">
+  <DESCRIPTION>
+     HEASARC Browse data service
+     Please send inquiries to mailto:request at athena.gsfc.nasa.gov
+  </DESCRIPTION>
+  <RESOURCE ID="error_resource">
+   <PARAM ID="Error" name="Error" datatype="char" arraysize="*"
+          value="Invalid data type: text/html"/>
+ </RESOURCE>
+</VOTABLE>
+</pre>
+</div>
+</div>
+
+
+
+       <p> Other conditions may NOT be considered erroneous, for
+       example if a query cone is in the Southern hemisphere and the
+       catalog coverage is in the Northern hemisphere. This type of
+       query is different from an error return; it should return a
+       VOTable as described above, with metadata, but no data
+       records. In particular, a zero value of Search Radius should
+       not return an error   condition. This is because an application
+       may be more interested in the metadata than the data, and send
+       a fixed query (for example RA=0&DEC=90&SR=0) simply to
+       discover the fields delivered by the service. </p> </li>
+
+</ol>
+
+<a name="prof">
+<h2>3.  The Resource Profile</h2></a>
+
+<p>
+A Cone Search service MUST be described with a Resource Profile that
+includes the following information.  The Profile is composed of named
+metadata listed below.  The format used to encode the profile should be
+compliant with the publishing standards of the IVOA throughout the time
+the service is supported by the data provider.  The metadata names
+and values used in the profile encoding should match those given below
+as closely as possible; where they do not match exactly, they should
+be consistent with the IVOA metadata conventions in place at any given
+time and the mapping of names and values actually used and those given
+below should be well documented.
+</p>
+
+<blockquote>
+<dl>
+  <dt> <strong>Editor's Note:</strong> </dt>
+  <dd> The original NVO specification pre-dates the IVOA standard for
+       resource metadata [<a name="rm">RM</a>], and so, obviously,
+       some inconsistencies with that standard exist.  To deal with
+       this, the wording of this section has been altered to allow
+       profiles to be constructed according to the latest practices in
+       the IVOA.  Appendix B outlines the mapping of the metadata
+       listed below to that in the RM as well as the XML Schema used
+       to render the metadata within a Registry.</dd>
+</dl>
+</td></tr></tbody></table>
+</blockquote>
+
+<p>
+Several of the metadata listed below can have values that are
+hierarchical; this hierarchy should be represented in a manner most
+appropriate to the format used.  When the format does not provide any
+such mechanism, it is recommended that the value be represented as a
+strings delimited by dots with the root domain of the value appearing
+first.
+</p>
+
+<p>
+The resource profile consists of the following metadata with the
+stated definitions:
+</p>
+
+<ul>
+  <li> <p><b>ResponsibleParty</b>: The data provider's name and
+       email.</p></li>
+
+  <li> <p><b>ServiceName</b>:  The name of the catalog served by the
+       service, for example "IRSA.2MASS.ExtendedSources".</p></li>
+
+  <li> <p><b>Description</b>: A couple of paragraphs of text that
+       describe the nature of the catalog and its wider context.</p></li>
+
+  <li> <p><b>Instrument</b>:  The instrument that made the observations, for
+       example STScI.HST.WFPC2. </p></li>
+
+  <li> <p><b>Waveband</B>: The waveband of the observations, with ONE
+       selected from this list: radio, millimeter, infrared, optical,
+       ultraviolet, xray, gammaray.  </p></li>
+
+  <li> <p><b>Epoch</B>: The epoch of the observations, as a free-form
+       string.  </p></li>
+
+  <li> <p><b>Coverage</B>: The coverage on the sky, as a free-form
+       string.  </p></li>
+
+  <li> <p><b>MaxSR</B>: The largest search radius, given in decimal
+       degrees, that will be accepted by the service without returning
+       an error condition.  A value of 180.0 indicates that there is
+       no restriction.   </p></li>
+
+  <li> <p><b>MaxRecords</B>: The largest number of records that the
+       service will return.  </p></li>
+
+  <li> <p><b>Verbosity</B>: True or false, depending on whether the
+       service supports the VERB keyword in the request.   </p></li>
+
+  <li> <p><b>BaseURL</B>: The base URL for the service as described in
+       <a href="#req">Section 2</a>.   </p></li>
+</ul>
+
+<p>
+The service will be considered published to the VO if the profile has
+been added to an IVOA Registry according to the IVOA standards and
+conventions at the time the service is made available, TOGETHER with
+maintaining the web service that is described by the profile in
+compliant order.
+</p>
+
+<a name="appA">
+<h2>Appendix A: Sample VOTable Response</h2></a>
+
+<p>
+This is a sample of a legal response to a Cone Search query.
+</p>
+
+<div class="exampleOuter">
+<a name="ex:errors">
+<div class="exampleInner" style="background-color: rgb(213, 222, 227);">
+<pre><?xml version="1.0"?>
+<!DOCTYPE VOTABLE SYSTEM "http://us-vo.org/xml/VOTable.dtd">
+<VOTABLE version="1.0">
+  <DEFINITIONS>
+    <COOSYS system="eq_FK5" equinox="2000" />
+  </DEFINITIONS>
+
+  <RESOURCE ID="T9001">
+     <DESCRIPTION>
+       HEASARC Browse data service
+       Please send inquiries to mailto:request at athena.gsfc.nasa.gov
+    </DESCRIPTION>
+           value="0.0516666666666667" />
+
+    <TABLE ID="heasarc_first_9001">
+      <DESCRIPTION> Faint Images of the Radio Sky at Twenty cm Source Catalog (FIRST) </DESCRIPTION>
+
+      <FIELD name="unique_id" datatype="char" arraysize="*"  ucd="ID_MAIN">
+        <DESCRIPTION> Integer key </DESCRIPTION>
+      </FIELD>
+
+      <FIELD name="name" datatype="char" arraysize="*"  >
+        <DESCRIPTION> FIRST Source Designation </DESCRIPTION>
+      </FIELD>
+
+      <FIELD name="ra" datatype="double" unit="degree" ucd="POS_EQ_RA_MAIN">
+        <DESCRIPTION> Right Ascension </DESCRIPTION>
+      </FIELD>
+
+      <FIELD name="dec" datatype="double" unit="degree" ucd="POS_EQ_DEC_MAIN">
+        <DESCRIPTION> Declination </DESCRIPTION>
+      </FIELD>
+
+      <FIELD name="flux_20_cm" datatype="double" unit="mJy" >
+        <DESCRIPTION> Peak 1.4GHz Flux Density (mJy) </DESCRIPTION>
+      </FIELD>
+
+      <FIELD name="flux_20_cm_error" datatype="double" unit="mJy" >
+        <DESCRIPTION> Estimated rms in at Source (mJy) </DESCRIPTION>
+      </FIELD>
+
+      <FIELD name="int_flux_20_cm" datatype="double" unit="mJy" >
+
+        <DESCRIPTION> Integrated 1.4GHz Flux Density (mJy) </DESCRIPTION>
+      </FIELD>
+
+      <DATA>
+        <TABLEDATA>
+<TR>
+  <TD>384559</TD><TD>FIRST J120002.6+595708</TD>
+  <TD>180.0110042</TD><TD>59.9523889</TD>
+  <TD>    1.11</TD><TD> 0.139</TD><TD>    1.14</TD>
+</TR>
+<TR>
+  <TD>385094</TD><TD>FIRST J120025.3+600103</TD>
+  <TD>180.1057250</TD><TD>60.0175556</TD>
+  <TD>    2.89</TD><TD> 0.142</TD><TD>    2.56</TD>
+</TR>
+<TR>
+  <TD>384928</TD><TD>FIRST J120018.1+600236</TD>
+  <TD>180.0755500</TD><TD>60.0434750</TD>
+  <TD>   19.38</TD><TD> 0.145</TD><TD>   19.23</TD>
+</TR>
+<TR>
+  <TD>384490</TD><TD>FIRST J115959.4+600403</TD>
+  <TD>179.9978875</TD><TD>60.0677083</TD>
+  <TD>    1.01</TD><TD> 0.147</TD><TD>    1.20</TD>
+</TR>
+        </TABLEDATA>
+      </DATA>
+    </TABLE>
+
+  </RESOURCE>
+</VOTABLE>
+</pre>
+</div>
+</div>
+
+<a name="appB">
+<h2>Appendix B: Current Practices for Representing Resource Profiles</h2></a>
+
+<a name="appB1">
+<h3>B.1.  Mapping for Resource Profile Metadata to the RM</h3></a>
+
+<p>
+As mentioned in an Editor's Note in <a href="#prof">Section 3</a>, the
+original NVO specification pre-dated the IVOA standard for resource
+metadata known as the RM [<a href="#rm">RM</a>].  This section
+indicates how the resource profile metadata defined in this
+specification maps to the metadata defined in the RM.
+</p>
+
+<blockquote>
+<table border="2" cellspacing="2">
+  <tr>
+  </tr>
+  <tr>
+    <td><b>ResponsibleParty</b></td>
+    <td>Publisher, <br>
+        Contact.Email</td>
+  </tr>
+  <tr>
+    <td><b>ServiceName</b></td>
+    <td>Title</td>
+  </tr>
+  <tr>
+    <td><b>Description</b></td>
+    <td>Description</td>
+  </tr>
+  <tr>
+    <td><b>Instrument</b></td>
+    <td>Instrument</td>
+  </tr>
+  <tr>
+    <td><b>Waveband</b></td>
+    <td>Coverage.Spectral</td>
+  </tr>
+  <tr>
+    <td><b>Epoch</b></td>
+    <td>Coverage.Temporal.StartTime,<br>
+        Coverage.Temporal.StopTime<sup>1</sup></td>
+  </tr>
+  <tr>
+    <td><b>Coverage</b></td>
+    <td>Coverage.Spatial</td>
+  </tr>
+  <tr>
+    <td><b>MaxSR</b></td>
+  </tr>
+  <tr>
+    <td><b>MaxRecords</b></td>
+    <td>Service.MaxReturnRecords</td>
+  </tr>
+  <tr>
+    <td><b>Verbosity</b></td>
+    <td><i>n/a</i><sup>2</sup></td>
+  </tr>
+  <tr>
+    <td><b>BaseURL</b></td>
+    <td>Service.BaseURL</td>
+  </tr>
+</table>
+<sup>1</sup>The notion of the epoch the observations is captured in
+the RM as the temporal coverage.  The notion of the equinox of the
+observational positions is captured part of the RM's
+Coverage.Spatial.  <br>
+<sup>2</sup>As this concept is not covered by the RM, it should be
+</blockquote>
+
+<a name="appB2">
+<h3>B.2.  VOResource (pre-v1.0) Schema Extension for Cone Search
+Services</h3></a>
+
+<p>
+Just prior to the adoption of IVOA standard for registry interfaces,
+v1.0 [<a href="#RI">RI</a>], resource descriptions were encoded using
+the VOResource XML Schema,
+<a href="http://www.ivoa.net/xml/VOResource/v0.10">v0.10</a> and its
+family of extension schemas.  The extensions used to specifically
+describe Cone Search services were
+<a href="http://www.ivoa.net/xml/VOResource/v0.10">VODataService,
+v0.5</a> and <a href="http://www.ivoa.net/xml/ConeSearch/v0.3">
+ConeSearch, v0.3</a>.  See the embedded documentation in each of these
+schemas for the precise definitions and usage of the metadata encodable
+through them.
+</p>
+
+<p>
+The following table enumerates the mapping of resource profile
+metadata defined in this specification with those defined in the XML
+schemas.
+</p>
+
+<blockquote>
+<table border="2" cellspacing="2">
+  <tr>
+  </tr>
+  <tr>
+    <th>Schema Name</th>
+    <th>XPath Name</th>
+  </tr>
+  <tr>
+    <td><b>ResponsibleParty</b></td>
+    <td>VOResource</td>
+    <td><code>curation/publisher</code>, <br>
+        <code>curation/contact/email</code></td>
+  </tr>
+  <tr>
+    <td><b>ServiceName</b></td>
+    <td>VOResource</td>
+    <td><code>title</code></td>
+  </tr>
+  <tr>
+    <td><b>Description</b></td>
+    <td>VOResource</td>
+    <td><code>content/description</code></td>
+  </tr>
+  <tr>
+    <td><b>Instrument</b></td>
+    <td>VOResource</td>
+    <td><code>instrument</code></td>
+  </tr>
+  <tr>
+    <td><b>Waveband</b></td>
+    <td>VODataService</td>
+    <td><code>coverage/spectral/waveband</code></td>
+  </tr>
+  <tr>
+    <td><b>Epoch</b></td>
+    <td>VODataService</td>
+    <td><code>coverage/temporal/startTime</code>,<br>
+        <code>coverage/temporal/stopTime</code><sup>1</sup></td>
+  </tr>
+  <tr>
+    <td><b>Coverage</b></td>
+    <td>VODataService</td>
+    <td><code>coverage/spatial</code><sup>2</sup></td>
+  </tr>
+  <tr>
+    <td><b>MaxSR</b></td>
+    <td>ConeSearch</td>
+    <td><code>capability/maxSR</code></td>
+  </tr>
+  <tr>
+    <td><b>MaxRecords</b></td>
+    <td>ConeSearch</td>
+    <td><code>capability/maxRecords</code></td>
+  </tr>
+  <tr>
+    <td><b>Verbosity</b></td>
+    <td>ConeSearch</td>
+    <td><code>capability/verbosity</code></td>
+  </tr>
+  <tr>
+    <td><b>BaseURL</b></td>
+    <td>VOResource</td>
+    <td><code>interface/accessURL</code></td>
+  </tr>
+</table>
+<sup>1</sup>The notion of the epoch the observations is captured in
+the schema inside coverage/temporal.  The notion of the equinox of the
+observational positions is captured within coverage/spatial/region,
+such as in coverage/spatial/region[@xsi:type='vs:Circle']/coordFrame. <br>
+<sup>2</sup>the coverage/spatial element encodes its information as a
+complex set of child elements.
+</blockquote>
+
+<a name="appB3">
+<h3>B.3.  VOResource (v1.0) Schema Extension for Cone Search Services</h3></a>
+
+<p>
+With the expected adoption of the IVOA standard for Registry Interface
+[<a href="#RI">RI</a>], resources are described using the VOResource
+schema, v1.0 [<a href="VOR">VOR</a>] and its family of extensions.
+Cone Search services are specifically described using the
+<a href="http://www.ivoa.net/xml/VOResource/v0.10">VODataService,
+v1.0</a>, and <a href="http://www.ivoa.net/xml/ConeSearch/v0.3">
+ConeSearch, v1.0</a>, extension schemas.  Coverage information is
+encoded using the Space-Time Coordinates (STC) schema
+[<a href="#stc">STC</a>].
+</p>
+
+<p>
+The following table enumerates the mapping of resource profile
+metadata defined in this specification with those defined in the XML
+schemas.
+</p>
+
+<table border="2" cellspacing="2">
+  <tr>
+  </tr>
+  <tr>
+    <th>Schema Name</th>
+    <th>XPath Name</th>
+  </tr>
+  <tr>
+    <td><b>ResponsibleParty</b></td>
+    <td>VOResource</td>
+    <td><code>curation/publisher</code>, <br>
+        <code>curation/contact/email</code></td>
+  </tr>
+  <tr>
+    <td><b>ServiceName</b></td>
+    <td>VOResource</td>
+    <td><code>title</code></td>
+  </tr>
+  <tr>
+    <td><b>Description</b></td>
+    <td>VOResource</td>
+    <td><code>content/description</code></td>
+  </tr>
+  <tr>
+    <td><b>Instrument</b></td>
+    <td>VOResource</td>
+    <td><code>instrument</code></td>
+  </tr>
+  <tr>
+    <td><b>Waveband</b></td>
+    <td>VODataService</td>
+    <td><code>coverage/waveband</code></td>
+  </tr>
+  <tr>
+    <td><b>Epoch</b></td>
+    <td>VODataService</td>
+    <td><code>coverage/stc:STCResourceProfile/stc:AstroCoordArea</code><sup>1</sup></td>
+  </tr>
+  <tr>
+    <td><b>Coverage</b></td>
+    <td>VODataService</td>
+    <td><code>coverage/stc:STCResourceProfile/stc:AstroCoordArea</code><sup>1</sup></td>
+  </tr>
+  <tr>
+    <td><b>MaxSR</b></td>
+    <td>ConeSearch</td>
+    <td><code>capability/maxSR</code></td>
+  </tr>
+  <tr>
+    <td><b>MaxRecords</b></td>
+    <td>ConeSearch</td>
+    <td><code>capability/maxRecords</code></td>
+  </tr>
+  <tr>
+    <td><b>Verbosity</b></td>
+    <td>ConeSearch</td>
+    <td><code>capability/verbosity</code></td>
+  </tr>
+  <tr>
+    <td><b>BaseURL</b></td>
+    <td>VOResource</td>
+    <td><code>capability/interface[@role='std']/accessURL</code></td>
+  </tr>
+</table>
+<sup>1</sup>In STC, coverage on the sky and in time are described in
+an integrated way within the stc:AstroCoordArea element.  The notion
+of the equinox of the observational positions is captured within
+stc:AstroCoordSystem element.
+
+<p>
+Subsequent versions of this document should include the ConeSearch
+extension schema as a formal part of the specification.
+</p>
+
+
+<a name="appC">
+<h2>Appendix C: Change History</h2></a>
+
+<a name="appC1">
+<h3>Appendix C.1: Changes From the Original NVO Specification Document</h3></a>
+
+<ul>
+  <li> References to the original HTML document have been replaced with
+       references to this IVOA specification. </li>
+  <li> Replaced references to "curator" with "data provider" or
+       similar wording.  </li>
+  <li> Replaced references to the NVO with references either to the
+       IVOA or this specification, as appropriate.  </li>
+  <li> 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 <a href="#conf">preface</a>.  </li>
+  <li> Grammatical and spelling corrections have been made. </li>
+  <li> The content is organized into sections typical of an IVOA spec.
+  <li> Description of the URL syntax is sharper, borrowing language
+       from the SIA specification [<a href="#sia">SIA</a>].  This
+       includes:
+       <ul>
+         <li> more explicitly specifying the form of the URL </li>
+         <li> sharpening the definition of the input parameters </li>
+         <li> indicating that parameter order is not significant </li>
+         <li> stating explicitly that unsupported optional arguments
+              should be ignored. </li>
+         <li> re-ordering information for improved flow.
+       </ul>
+  <li> The version of VOTable supported is explicitly stated. </li>
+  <li> Whereas the NVO version describes the parameter with
+       ucd="OBS_ANG-SIZE" as "an expression of the opening angle of
+       the cones", this version describes it specifically as "an
+       expression of the uncertainty of the positions".  </li>
+  <li> A note has been added to recognize the ambiguity in the
+       location of the ERROR parameter.  </li>
+  <li> The general description of the resource profile has been
+       altered to allow rendering of the metadata to change according
+       to the standards and conventions of the IVOA.  </li>
+  <li> An editor's note has been added that makes reference to the RM
+       document [RM]. </li>
+  <li> A requirement that <b>MaxSR</b> be given in decimal degrees has
+  <li> For the <b>BaseURL</b> resource profile metadatum, the example
+       has been replaced with a reference to the BaseURL syntax
+       description.  </li>
+  <li> An appendix has been added to describe the current practice for
+       registering Cone Search services.  </li>
+</ul>
+
+<a name="appC2">
+<h3>Appendix C.2:  Changes from Previous IVOA Versions</h3></a>
+
+<h4>Changes from v1.01</h4>
+
+<ul>
+  <li> 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.  </li>
+  <li> allowed the use of the INFO element for error messages. </li>
+  <li> In examples, made sure PARAM elements have datatype attributes </li>
+  <li> Corrected wording to be definitive that positions are given in
+       the ICRS coordinate system. </li>
+  <li> other typos </li>
+</ul>
+
+<h4>Changes from v1.02:</h4>
+<ul>
+  <li> converted to Recommendation
+</ul>
+
+<h4>Changes from v1.00</h4>
+
+<ul>
+  <li> various typos </li>
+  <li> clarified description of VERB parameter:
+       <ul>
+         <li> clarified what is meant by optional for client and
+              server </li>
+         <li> clarified the meaning of the values
+       </ul></li>
+  <li> Explicitly mention the 3 legal locations for ERROR messages</li>
+  <li> refer to string types as character arrays, as per the VOTable
+       std.</li>
+  <li> prefers text/xml;content=x-votable over text/xml;votable.</li>
+  <li> added examples of error message, legal response in appendix
+</ul>
+
+<h2><a id="References">References</a></h2>
+
+<dl>
+  <dt> <a name="should">[RFC 2119]</a> </dt>
+  <dd> Bradner, S. 1997. <cite><a href="http://www.ietf.org/rfc/rfc2119.txt">
+       Key words for use in RFCs to Indicate Requirement
+       Levels</a></cite>, IETF RFC 2119,
+       <code>http://www.ietf.org/rfc/rfc2119.txt</code> </dd>
+
+<!--
+  <dt> <a name="abnf">[RFC 2234]</a> </dt>
+  <dd> Crocker, D. and Overell, P. 1997.
+       <cite><a href="http://www.ietf.org/rfc/rfc2234.txt">Augmented
+       BNF for Syntax Specifications: ABNF</a></cite>, IETF RFC 2234,
+       <code>http://www.ietf.org/rfc/rfc2234.txt</code> </dd>
+  -->
+
+  <dt> <a name="mime">[MIME]</a> </dt>
+  <dd> Freed, N. and Borenstein, N. 1996,
+       <cite><a href="http://www.ietf.org/rfc/rfc2046.txt">Multipurpose
+       Internet Mail Extensions (MIME) Part Two:  Media
+       Types</a></cite>, IETF RFC 2046,
+       <code>http://www.ietf.org/rfc/rfc2046.txt</code> </dd>
+
+  <dt> <a name="vot10">[VOTable v1.0]</a> </dt>
+  <dd> Ochsenbein, François et al. 2003, <cite>
+       <a href="http://www.ivoa.net/Documents/PR/VOTable/VOTable-20031017.html">
+       VOTable: A Proposed XML Format for Astronomical Tables, Version
+       1.0</a></cite>,
+       <code>http://www.ivoa.net/Documents/PR/VOTable/VOTable-20031017.html</code>.
+       </dd>
+
+  <dt> <a name="vot11">[VOTable v1.1]</a> </dt>
+  <dd> Ochsenbein, François et al. 2004, <cite>
+       <a href="http://www.ivoa.net/Documents/REC/VOTable/VOTable-20040811.html">
+       VOTable: A Proposed XML Format for Astronomical Tables, Version
+       1.1</a></cite>,
+       <code>http://www.ivoa.net/Documents/REC/VOTable/VOTable-20040811.html</code>.
+       </dd>
+
+  <dt> <a name="RM">[RM]</a></dt>
+  <dd> Hanisch, Robert (ed.) 2004.
+       Resource Metadata for the Virtual Observatory, Version 1.01</a></cite>,
+       IVOA Recommendation,
+       </dd>
+
+  <dt> <a name="sia">[SIA]</a> </dt>
+  <dd> Tody, Doug and Plante, Ray 2004, <cite>
+       <a href="http://www.ivoa.net/Documents/WD/SIA/sia-20040524.html">
+       Simple Image Access Specification Version 1.0</a></cite>,
+       <code>http://www.ivoa.net/Documents/WD/SIA/sia-20040524.html</code>.
+
+</dl>
+
+<hr>
+<font size="-3">
+<!-- hhmts start -->
+<!-- hhmts end -->
+</font>
+</body> </html>

==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/projects/dal/SCS/SCS.tex	Fri May 26 08:53:22 2017	(r4105)
@@ -0,0 +1,441 @@
+\documentclass[11pt,a4paper]{ivoa}
+\input tthdefs
+
+\usepackage{todonotes}
+
+\usepackage{listings}
+\lstset{flexiblecolumns=true,tagstyle=\ttfamily,
+showstringspaces=False}
+
+\usepackage{multirow}
+
+\title{Simple Cone Search}
+
+\ivoagroup{Data Access Layer}
+
+\author[http://www.ivoa.net/twiki/bin/view/IVOA/RayPlante]{Raymond Plante}
+\author[http://www.ivoa.net/twiki/bin/view/IVOA/MarcoMolinaro]{Marco Molinaro}
+\author[http://www.ivoa.net/twiki/bin/view/IVOA/MarkusDemleitner]{Markus Demleitner}
+\author[http://www.ivoa.net/twiki/bin/view/IVOA/BobHanisch]{Robert Hanisch}
+\author[http://www.ivoa.net/twiki/bin/view/IVOA/AlexSzalay]{Alex Szalay}
+\author[http://www.ivoa.net/twiki/bin/view/IVOA/RoyWilliams]{Roy Williams}
+
+\editor{Ray Plante, Marco Molinaro}
+
+\previousversion[http://www.ivoa.net/Documents/REC/DAL/ConeSearch-20080222.html]{REC 1.03}
+\previousversion[http://www.ivoa.net/Documents/PR/DAL/ConeSearch-20070914.html]{PR 2007-09-14}
+\previousversion[http://www.ivoa.net/Documents/PR/DAL/ConeSearch-20070628.html]{PR 2007-06-28}
+\previousversion[http://www.ivoa.net/Documents/PR/DAL/ConeSearch-20060908.html]{PR 2006-09-08}
+
+
+\begin{document}
+\begin{abstract}
+This specification defines a simple query protocol for retrieving records from a catalog of astronomical sources. The query describes 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 of the specification is essentially a transcription of the original Cone Search specification in order to move it into the IVOA standardization process.
+\end{abstract}
+
+
+\section*{Acknowledgments}
+This document was originally published as a document of the US National Virtual Observatory (NVO), available at \url{http://us-vo.org/pubs/files/conesearch.html}\todo{this link does not work anymore, find out if it's possible to find a link or remove it.}. This IVOA version is essentially a transcription of that document into the IVOA standards document format. Minor changes have been made to sharpen the specification description where needed and to otherwise fit it into the IVOA standards context; these changes are enumerated in Appendix \ref{appendix:c5}. It is the intention of this document that all existing services compliant with the original NVO document will be compliant with this specification. Similarly, all future service implementations that are based on this specification are expected to be compliant with the spirit of the original NVO document and practices in the VO current at the time of this writing; thus, existing client applications should work with the ne!
w impleme
ntations without change.
+
+Cone Search represents the first and arguably the most successful "standard protocol" developed within the Virtual Observatory movement. The editor, therefore, gratefully acknowledges the 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.
+
+This 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.
+
+\section*{Conformance-related definitions}
+
+The words MUST'', SHALL'', SHOULD'', MAY'', RECOMMENDED'', and
+OPTIONAL'' (in upper or lower case) used in this document are to be
+interpreted as described in IETF standard RFC2119 \citep{std:RFC2119}.
+
+The \emph{Virtual Observatory (VO)} is a
+general term for a collection of federated resources that can be used
+to conduct astronomical research, education, and outreach.
+The \href{http://www.ivoa.net}{International
+Virtual Observatory Alliance (IVOA)} is a global
+collaboration of separately funded projects to develop standards and
+infrastructure that enable VO applications.
+
+
+\section{Introduction}
+
+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 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.
+
+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.
+
+\subsection{Role within the VO Architecture}
+
+\begin{figure}
+\centering
+
+% Get the architecture diagram from the TCG chair
+% http://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaTCG
+% If they give you a PDF, for now dumb it down to a png by
+% convert -antialias -density 72x72 archdiag.pdf archdiag.png
+% Oh -- Notes don't need this; you'd have to remove archdiag.png
+% from FIGURES in the Makefile, too.
+
+\includegraphics[width=0.9\textwidth]{archdiag.png}
+\caption{Architecture diagram for SCS - TODO}
+\label{fig:archdiag}
+\end{figure}
+
+Fig.~\ref{fig:archdiag} shows the role this document plays within the
+IVOA architecture \citep{note:VOARCH}.
+
+\section{Service Interface Requirements}
+\label{sec:2}
+
+A service implementation that is compliant with this standard must meet the following requirements:
+
+\begin{enumerate}
+	\item the service must respond to a HTTP GET request represented by a URL having two parts:\\
+	\begin{itemize}
+		\item A base URL of the form\\
+
+
+		where <server-address> and <path> are URI-compliant components indicating the domain address and local location path where the service is deployed. The <server-address> may end with one or more locally supported URL arguments, <extra-GET-arg>; these arguments are not recognized parts of the Cone Search protocol and thus are treated opaquely by clients of the service as part of the base URL.\\
+Note that when it contains extra GET arguments, the base URL ends in an ampersand, \&; if there are no extra arguments, then it ends in a question mark, ?.\\
+		\begin{bigdescription}
+		\item[Examples] \url{http://mycone.org/cgi-bin/VOsearch?}\\
+		\end{bigdescription}
+		Every query to a given cone search service uses the same base URL.
+		\item Constraints expressed as a list of ampersand-delimited GET arguments of the form: <name>=<value> where <name> is a parameter name specified by this specification and <value> is its value. The constraints represent the query parameters which can vary for each successive query. The order of the name-parameter pairs is not significant.
+		\item The baseURL and constraint list are concatenated to form the query.
+		\item The set of query constraints must include the following parameters, which are interpreted by the service with the stated meaning:
+		\begin{description}
+			\item[\textbf{RA}] a right-ascension in the ICRS coordinate system for the positon of the center of the cone to search, given in decimal degrees.
+			\item[\textbf{DEC}] a declination in the ICRS coordinate system for the positon of the center of the cone to search, given in decimal degrees.
+			\item[\textbf{SR}] the radius of the cone to search, given in decimal degrees.
+		\end{description}
+		\begin{bigdescription}
+			\item[Example] \url{http://mycone.org/cgi-bin/search?RA=180.567&DEC=-30.45&SR=0.0125}
+		\end{bigdescription}
+		\item The query MAY contain the optional 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. Support for this parameter by a Cone Search service implementation is optional. 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 2.2 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 se!
rvice, th
e service should ignore the parameter and should always return the same columns for every request.
+		\item There may be other parameters in the query, but this document does not specify their meaning or usage. If a query includes an optional parameter, either one specified by this document or not, that is not supported by the service implementation, the service must ignore that parameter.
+	\end{itemize}
+	A query following this syntax represents a request for information on sources located within the specified cone on the sky.
+	\item The service must respond with an XML document in the VOTable format, that represents a table of astronomical sources whose positions are within the cone (see Appendix \ref{appendix:a} for an example). There may also be other sources outside the cone -- the service implementor may decide on the exact search criterion used internally to the service to select the sources.
+	The base MIME-type of the HTTP response should be \texttt{text/xml}. The more specific form \texttt{text/xml;content=x-votable} may optionally be used. The MIME-type, \texttt{text/xml;votable} shall also be considered legal (for backward compatibility reasons); however, this value is strongly discouraged as it is not compliant with the MIME-type standard \citep{std:MIME}. The XML content of the response must be compliant with VOTable schema, version 1.0 \citep{std:VOT11} or 1.1 \citep{2004ivoa.spec.0811O}.
+	\begin{bigdescription}
+		\item[Editor's Note] The original NVO specification allowed a MIME-type of text/xml;votable, thus for backward compatibility this is still allowed but discouraged.
+	\end{bigdescription}
+	The VOTable MUST comply with these conditions:
+	\begin{itemize}
+		\item There must be a single RESOURCE in the VOTable, and that contains a single TABLE.
+		\item The TABLE must have FIELDS where the following UCD \todo{SCS-1.03 used to point to CDS tools, but now those ones are overwritten by UCD1+ tools} values have been set. There must only be one FIELD with each of these UCDs:
+		\begin{itemize}
+			\item Exactly one FIELD must have ucd="ID\_MAIN", with an array character type (fixed or variable length), representing an ID string for that record of the table. This identifier may not be repeated in the table, and it could be used to retrieve that same record again from that same table.
+			\item Exactly one FIELD must have ucd="POS\_EQ\_RA\_MAIN", with type double, representing the right-ascension of the source in the ICRS coordinate system.
+			\item Exactly one FIELD must have ucd="POS\_EQ\_DEC\_MAIN", with type double, representing the declination of the source in the ICRS coordinate system.
+		\end{itemize}
+		\item 	The VOTable may include an expression of the uncertainty of the positions given in the above mentioned fields to be interpreted either as a positional error of the source positions, or an angular size if the sources are resolved. If this uncertainty is not provided, it should be taken to be zero; otherwise, it may be set for all table entries with a PARAM in the RESOURCE which has a UCD that is set to OBS\_ANG-SIZE and has a value which is the angle in decimal degrees. Alternatively, a different value for each row in the table can be given via a FIELD in the table having a UCD set to OBS\_ANG-SIZE.
+		\item There may be other FIELDs in the table. Their specification should include a description, data-type, and UCD.
+	\end{itemize}
+	\item The service must respond with a stubbed version of the VOTable in the case of error. This must happen if the three required parameters (RA, DEC, SR) are not all present, or if their values cannot be parsed to floating-point numbers, or if the numbers are out of range (DEC=91.0, for example). The service may also make an error return if the search radius (give by the SR parameter) is larger than the MaxSR parameter of the Resource Profile (see Section \ref{sec:3}).
+	In the case of error, the service MUST respond with a VOTable that contains a single PARAM element or a single INFO element with \texttt{name="Error"}, where the corresponding value attribute should contain some explanation of the nature of the error. If an INFO element is used, it must appear as a direct child of one of the following elements:
+	\begin{itemize}
+		\item the root VOTABLE element (which is preferred by this document), or
+		\item the RESOURCE element
+	\end{itemize}
+	If a PARAM element is used, it must appear as a direct child of one of following elements:
+	\begin{itemize}
+		\item the RESOURCE element, or
+		\item a DEFINITION element below the root VOTABLE element (which is discouraged by this document).
+	\end{itemize}
+	\begin{bigdescription}
+	\item[Editor's Note] It was recognized that this requirement, as it was described in the original NVO specification, is ambiguous about both the element to use for the ERROR message and its location in the document. The VOTable standard allows PARAM and INFO elements to appear in various places within the document. Since several of the different methods have been used in practice by Cone Search service implementations, no attempt is made in this version to correct this ambiguity. All of the above-mentioned locations should be considered legal, and Cone Search service clients should be prepared to look in all of them for an ERROR message. The use of PARAM as a child of DEFINITIONS is discouraged as the DEFINITIONS element was deprecated in VOTable v1.1.
+	\end{bigdescription}
+	\begin{bigdescription}
+	\item[Example Error Responses] Error INFO as child of VOTABLE (preferred)\\
+	\begin{lstlisting}[language=XML,basicstyle=\footnotesize]
+<?xml version="1.0"?>
+<!DOCTYPE VOTABLE SYSTEM "http://us-vo.org/xml/VOTable.dtd">
+<VOTABLE version="1.0">
+  <DESCRIPTION>MAST Simple Cone Search Service</DESCRIPTION>
+  <INFO ID="Error" name="Error" value="Error in input RA value: as3f"/>
+</VOTABLE>
+	\end{lstlisting}
+	Error PARAM as child of RESOURCE (allowed)
+	\begin{lstlisting}[language=XML,basicstyle=\footnotesize]
+<?xml version="1.0"?>
+<!DOCTYPE VOTABLE SYSTEM "http://us-vo.org/xml/VOTable.dtd">
+<VOTABLE version="1.0">
+  <DESCRIPTION>
+     HEASARC Browse data service
+     Please send inquiries to mailto:request at athena.gsfc.nasa.gov
+  </DESCRIPTION>
+  <RESOURCE ID="error_resource">
+   <PARAM ID="Error" name="Error" datatype="char" arraysize="*"
+          value="Invalid data type: text/html"/>
+ </RESOURCE>
+</VOTABLE>
+	\end{lstlisting}
+	\end{bigdescription}
+	Other conditions may NOT be considered erroneous, for example if a query cone is in the Southern hemisphere and the catalog coverage is in the Northern hemisphere. This type of query is different from an error return; it should return a VOTable as described above, with metadata, but no data records. In particular, a zero value of Search Radius should not return an error condition. This is because an application may be more interested in the metadata than the data, and send a fixed query (for example RA=0\&DEC=90\&SR=0) simply to discover the fields delivered by the service.
+\end{enumerate}
+
+\section{The Resource Profile}
+\label{sec:3}
+A Cone Search service MUST be described with a Resource Profile that includes the following information. The Profile is composed of named metadata listed below. The format used to encode the profile should be compliant with the publishing standards of the IVOA throughout the time the service is supported by the data provider. The metadata names and values used in the profile encoding should match those given below as closely as possible; where they do not match exactly, they should be consistent with the IVOA metadata conventions in place at any given time and the mapping of names and values actually used and those given below should be well documented.
+\begin{bigdescription}
+\item[Editor's Note] The original NVO specification pre-dates the IVOA standard for resource metadata [RM], and so, obviously, some inconsistencies with that standard exist. To deal with this, the wording of this section has been altered to allow profiles to be constructed according to the latest practices in the IVOA. Appendix B outlines the mapping of the metadata listed below to that in the RM as well as the XML Schema used to render the metadata within a Registry.
+\end{bigdescription}
+Several of the metadata listed below can have values that are hierarchical; this hierarchy should be represented in a manner most appropriate to the format used. When the format does not provide any such mechanism, it is recommended that the value be represented as a strings delimited by dots with the root domain of the value appearing first.
+
+The resource profile consists of the following metadata with the stated definitions:
+\begin{itemize}
+	\item[\textbf{ResponsibleParty}] The data provider's name and email.
+	\item[\textbf{ServiceName}] The name of the catalog served by the service, for example "IRSA.2MASS.ExtendedSources".
+	\item[\textbf{Description}] A couple of paragraphs of text that describe the nature of the catalog and its wider context.
+	\item[\textbf{Instrument}] The instrument that made the observations, for example STScI.HST.WFPC2.
+	\item[\textbf{Waveband}] The waveband of the observations, with ONE selected from this list: radio, millimeter, infrared, optical, ultraviolet, xray, gammaray.
+	\item[\textbf{Epoch}] The epoch of the observations, as a free-form string.
+	\item[\textbf{Coverage}] The coverage on the sky, as a free-form string.
+	\item[\textbf{MaxSR}] The largest search radius, given in decimal degrees, that will be accepted by the service without returning an error condition. A value of 180.0 indicates that there is no restriction.
+	\item[\textbf{MaxRecords}] The largest number of records that the service will return.
+	\item[\textbf{Verbosity}] True or false, depending on whether the service supports the VERB keyword in the request.
+	\item[\textbf{BaseURL}] The base URL for the service as described in Section \ref{sec:2}.
+\end{itemize}
+The service will be considered published to the VO if the profile has been added to an IVOA Registry according to the IVOA standards and conventions at the time the service is made available, TOGETHER with maintaining the web service that is described by the profile in compliant order.
+
+\appendix
+\section{Sample VOTable Response}
+\label{appendix:a}
+This is a sample of a legal response to a Cone Search query.
+\begin{lstlisting}[language=XML,basicstyle=\footnotesize]
+<?xml version="1.0"?>
+<!DOCTYPE VOTABLE SYSTEM "http://us-vo.org/xml/VOTable.dtd">
+<VOTABLE version="1.0">
+  <DEFINITIONS>
+    <COOSYS system="eq_FK5" equinox="2000" />
+  </DEFINITIONS>
+  <RESOURCE ID="T9001">
+     <DESCRIPTION>
+       HEASARC Browse data service
+       Please send inquiries to mailto:request at athena.gsfc.nasa.gov
+    </DESCRIPTION>
+           value="0.0516666666666667" />
+    <TABLE ID="heasarc_first_9001">
+      <DESCRIPTION> Faint Images of the Radio Sky at Twenty cm Source Catalog (FIRST) </DESCRIPTION>
+      <FIELD name="unique_id" datatype="char" arraysize="*"  ucd="ID_MAIN">
+        <DESCRIPTION> Integer key </DESCRIPTION>
+      </FIELD>
+      <FIELD name="name" datatype="char" arraysize="*"  >
+        <DESCRIPTION> FIRST Source Designation </DESCRIPTION>
+      </FIELD>
+      <FIELD name="ra" datatype="double" unit="degree" ucd="POS_EQ_RA_MAIN">
+        <DESCRIPTION> Right Ascension </DESCRIPTION>
+      </FIELD>
+      <FIELD name="dec" datatype="double" unit="degree" ucd="POS_EQ_DEC_MAIN">
+        <DESCRIPTION> Declination </DESCRIPTION>
+      </FIELD>
+      <FIELD name="flux_20_cm" datatype="double" unit="mJy" >
+        <DESCRIPTION> Peak 1.4GHz Flux Density (mJy) </DESCRIPTION>
+      </FIELD>
+      <FIELD name="flux_20_cm_error" datatype="double" unit="mJy" >
+        <DESCRIPTION> Estimated rms in at Source (mJy) </DESCRIPTION>
+      </FIELD>
+      <FIELD name="int_flux_20_cm" datatype="double" unit="mJy" >
+        <DESCRIPTION> Integrated 1.4GHz Flux Density (mJy) </DESCRIPTION>
+      </FIELD>
+      <DATA>
+        <TABLEDATA>
+		<TR>
+		  <TD>384559</TD><TD>FIRST J120002.6+595708</TD>
+		  <TD>180.0110042</TD><TD>59.9523889</TD>
+		  <TD>    1.11</TD><TD> 0.139</TD><TD>    1.14</TD>
+		</TR>
+		<TR>
+		  <TD>385094</TD><TD>FIRST J120025.3+600103</TD>
+		  <TD>180.1057250</TD><TD>60.0175556</TD>
+		  <TD>    2.89</TD><TD> 0.142</TD><TD>    2.56</TD>
+		</TR>
+		<TR>
+		  <TD>384928</TD><TD>FIRST J120018.1+600236</TD>
+		  <TD>180.0755500</TD><TD>60.0434750</TD>
+		  <TD>   19.38</TD><TD> 0.145</TD><TD>   19.23</TD>
+		</TR>
+		<TR>
+		  <TD>384490</TD><TD>FIRST J115959.4+600403</TD>
+		  <TD>179.9978875</TD><TD>60.0677083</TD>
+		  <TD>    1.01</TD><TD> 0.147</TD><TD>    1.20</TD>
+		</TR>
+        </TABLEDATA>
+      </DATA>
+    </TABLE>
+  </RESOURCE>
+</VOTABLE>
+\end{lstlisting}
+
+\section{Current Practices for Representing Resource Profiles}
+
+\subsection{Mapping for Resource Profile Metadata to the RM}
+As mentioned in an Editor's Note in Section \ref{sec:3}, the original NVO specification pre-dated the IVOA standard for resource metadata known as the RM \citep{STD:RM101}. This section indicates how the resource profile metadata defined in this specification maps to the metadata defined in the RM.
+\begin{table}[th]
+\begin{tabular}{p{0.4\textwidth}p{0.5\textwidth}}
+\sptablerule
+\sptablerule
+\textbf{ResponsibleParty} & Publisher, Contact.Email\\
+\textbf{ServiceName} & Title\\
+\textbf{Description} & Description\\
+\textbf{Instrument} & Instrument\\
+\textbf{Waveband} & Coverage.Spectral\\
+\textbf{Epoch} & Coverage.Temporal.StartTime, Coverage.Temporal.StopTime\textsuperscript{1}\\
+\textbf{Coverage} & Coverage.Spatial\\
+\textbf{MaxRecords} & Service.MaxReturnRecords\\
+\textbf{Verbosity} & n/a\textsuperscript{2}\\
+\textbf{BaseURL} & Service.BaseURL\\
+\sptablerule
+\label{table:b1meta}
+\end{tabular}
+\end{table}
+Table notes:
+\begin{enumerate}
+	\item The notion of the epoch the observations is captured in the RM as the temporal coverage. The notion of the equinox of the observational positions is captured part of the RM's Coverage.Spatial.
+	\item As this concept is not covered by the RM, it should be considered service-specific capability metadata.
+\end{enumerate}
+
+\subsection{VOResource (pre-v1.0) Schema Extension for Cone Search Services}
+Just prior to the adoption of IVOA standard for registry interfaces, v1.0, resource descriptions were encoded using the VOResource XML Schema, v0.10 and its family of extension schemas. The extensions used to specifically describe Cone Search services were VODataService, v0.5 and ConeSearch, v0.3\todo{The references to RI, VOResource, VODataService and ConeSearch here, are all referring to xsd schemata currently obsoleted.}. See the embedded documentation in each of these schemas for the precise definitions and usage of the metadata encodable through them.
+
+The following table enumerates the mapping of resource profile metadata defined in this specification with those defined in the XML schemas.
+
+\begin{table}[th]
+\begin{tabular}{p{0.38\textwidth}p{0.27\textwidth}p{0.34\textwidth}}
+\sptablerule
+&\textbf{Schema Name}&\textbf{XPath Name}\\
+\sptablerule
+\textbf{ResponsibleParty} & VOResource & curation/publisher, curation/contact/email\\
+\textbf{ServiceName} & VOResource & title\\
+\textbf{Description} &	VOResource & content/description\\
+\textbf{Instrument} & VOResource & instrument\\
+\textbf{Waveband} & VODataService & coverage/spectral/waveband\\
+\textbf{Epoch} & VODataService & coverage/temporal/startTime, coverage/temporal/stopTime\textsuperscript{1}\\
+\textbf{Coverage} & VODataService & coverage/spatial\textsuperscript{2}\\
+\textbf{MaxSR} & ConeSearch & capability/maxSR\\
+\textbf{MaxRecords} & ConeSearch & capability/maxRecords\\
+\textbf{Verbosity} & ConeSearch & capability/verbosity\\
+\textbf{BaseURL} & VOResource & interface/accessURL\\
+\sptablerule
+\caption{VOResource pre-0.10 extension}
+\label{table:extable}
+\end{tabular}
+\end{table}
+Table Notes:
+\begin{enumerate}
+ \item The notion of the epoch the observations is captured in the schema inside coverage/temporal. The notion of the equinox of the observational positions is captured within coverage/spatial/region, such as in coverage/spatial/region[@xsi:type='vs:Circle']/coordFrame.
+ \item the coverage/spatial element encodes its information as a complex set of child elements.
+\end{enumerate}
+
+\subsection{VOResource (v1.0) Schema Extension for Cone Search Services}
+With the expected adoption of the IVOA standard for Registry Interface, resources are described using the VOResource schema, v1.0 and its family of extensions. Cone Search services are specifically described using the VODataService, v1.0, and ConeSearch, v1.0, extension schemas. Coverage information is encoded using the Space-Time Coordinates (STC) schema.
+
+The following table enumerates the mapping of resource profile metadata defined in this specification with those defined in the XML schemas.
+
+\begin{table}[th]
+\begin{tabular}{p{0.4\textwidth}p{0.29\textwidth}p{0.3\textwidth}}
+\sptablerule
+&\textbf{Schema Name}&\textbf{XPath Name}\\
+\sptablerule
+\textbf{ResponsibleParty} & VOResource & curation/publisher, curation/contact/email\\
+\textbf{ServiceName} & VOResource & title\\
+\textbf{Description} &	VOResource & content/description\\
+\textbf{Instrument} & VOResource & instrument\\
+\textbf{Waveband} & VODataService & coverage/waveband\\
+\textbf{Epoch} & VODataService & coverage/stc:STCResourceProfile/stc:AstroCoordArea\textsuperscript{1}\\
+\textbf{Coverage} & VODataService & coverage/stc:STCResourceProfile/stc:AstroCoordArea\textsuperscript{1}\\
+\textbf{MaxSR} & ConeSearch & capability/maxSR\\
+\textbf{MaxRecords} & ConeSearch & capability/maxRecords\\
+\textbf{Verbosity} & ConeSearch & capability/verbosity\\
+\textbf{BaseURL} & VOResource & capability/interface[@role='std']/accessURL\\
+\sptablerule
+\caption{VOResource 1.0 extension}
+\label{table:extable}
+\end{tabular}
+\end{table}
+
+Table Notes:
+\begin{enumerate}
+	\item In STC, coverage on the sky and in time are described in an integrated way within the stc:AstroCoordArea element. The notion of the equinox of the observational positions is captured within stc:AstroCoordSystem element.
+\end{enumerate}
+Subsequent versions of this document should include the ConeSearch extension schema as a formal part of the specification.
+
+\section{Changes from Previous Versions}
+
+\subsection{Changes from REC-1.03}
+\begin{itemize}
+	\item Plain porting of the HTML document into ivoatex template, including change history.
+\end{itemize}
+
+\subsection{Changes from PR-1.02}
+\begin{itemize}
+	\item converted to Recommendation
+\end{itemize}
+
+\subsection{Changes from PR-1.01}
+\begin{itemize}
+	\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 Allowed the use of the INFO element for error messages.
+	\item In examples, made sure PARAM elements have datatype attributes
+	\item Corrected wording to be definitive that positions are given in the ICRS coordinate system.
+	\item Other typos.
+\end{itemize}
+
+\subsection{Changes from PR-1.00}
+\begin{itemize}
+	\item Various typos.
+	\item Clarified description of VERB parameter:
+	\begin{itemize}
+		\item Clarified what is meant by optional for client and server.
+		\item Clarified the meaning of the values.
+	\end{itemize}
+	\item Explicitly mention the 3 legal locations for ERROR messages.
+	\item Refer to string types as character arrays, as per the VOTable std.
+	\item Prefers text/xml;content=x-votable over text/xml;votable.
+	\item Added examples of error message, legal response in appendix.
+\end{itemize}
+
+\subsection{Changes from the original NVO Specification Document}
+\label{appendix:c5}
+\begin{itemize}
+	\item References to the original HTML document have been replaced with references to this IVOA specification.
+	\item Replaced references to "curator" with "data provider" or similar wording.
+	\item Replaced references to the NVO with references either to the IVOA or this specification, as appropriate.
+	\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 Grammatical and spelling corrections have been made.
+	\item The content is organized into sections typical of an IVOA spec.
+	\item Description of the URL syntax is sharper, borrowing language from the SIA specification [SIA]. This includes:
+	\begin{itemize}
+		\item More explicitly specifying the form of the URL.
+		\item Sharpening the definition of the input parameters.
+		\item Indicating that parameter order is not significant.
+		\item Stating explicitly that unsupported optional arguments should be ignored.
+		\item Re-ordering information for improved flow.
+	\end{itemize}
+	\item The version of VOTable supported is explicitly stated.
+	\item Whereas the NVO version describes the parameter with ucd="OBS\_ANG-SIZE" as "an expression of the opening angle of the cones", this version describes it specifically as "an expression of the uncertainty of the positions".
+	\item A note has been added to recognize the ambiguity in the location of the ERROR parameter.
+	\item The general description of the resource profile has been altered to allow rendering of the metadata to change according to the standards and conventions of the IVOA.
+	\item An editor's note has been added that makes reference to the RM document [RM].
+	\item A requirement that \textbf{MaxSR} be given in decimal degrees has been added.
+	\item For the \textbf{BaseURL} resource profile metadatum, the example has been replaced with a reference to the BaseURL syntax description.
+	\item An appendix has been added to describe the current practice for registering Cone Search services.
+\end{itemize}
+
+\bibliography{ivoatex/ivoabib,ivoatex/docrepo,scs}
+
+
+\end{document}

==============================================================================
Binary file. No diff available.

==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/projects/dal/SCS/scs.bib	Fri May 26 08:53:22 2017	(r4105)
@@ -0,0 +1,21 @@
+ at Misc{std:VOT11,
+	author={Francois Ochsenbein and Roy Williams and Clive Davenhall and Daniel Durand and Pierre Fernique and David Giaretta and Robert Hanisch and Tom McGlynn and Alex Szalay and Mark B. Taylor and Andreas Wicenec},
+	editor={Francois Ochsenbein},
+	howpublished={{IVOA Recommendation}},
+	title={VOTable Format Definition, Version 1.11},
+	year=2004,
+	month=aug,
+	day=11,
+	url={http://www.ivoa.net/documents/cover/VOT-20040811.html},
+}
+
+ at Misc{STD:RM101,
+	author={Robert Hanish and the IVOA Resource Registry WG and the NVO Metadata WG},
+	editor={Robert Hanish},
+	howpublished={{IVOA Recommendation}},
+	title={Resource Metadata for the Virtual Observatory, Version 1.01},
+	year=2004,
+	month=apr,
+	day=26,
+	url={http://www.ivoa.net/documents/RM/20040426/index.html}
+}
\ No newline at end of file