(r7) ConeSearchV10RFC < IVOA

IVOA Web>IvoaDAL>ConeSearch>ConeSearchV10RFC (revision 7) (raw view)~~EditAttach~~
---++ Simple Cone Search Proposed Recommendation: Request for Comments

This document will act as RFC center for the Simple
Cone Search V1.0 Proposed Recommendation.<br/>
The specification can be found at <a href=http://www.ivoa.net/Documents/PR/DAL/ConeSearch-20060908.html>
http://www.ivoa.net/Documents/PR/DAL/ConeSearch-20060908.html</a>

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your <nop>WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.  The deadline for comments is 21 April 2007.

Discussion about any of the comments or responses should be conducted
on the Data Access Layer mailing list, dal@ivoa.net.

---++ Comments from the Community
   * (1) This first comment is a sample comment

-- %MAINWEB%.DougTody - 2007-03-21
---

   * (1) I suggest EQUINOX should be a mandatory input. J2000 should not be assumed. EPOCH should be recommended. 

-- IVOA.RichardMcMahon - 28 Mar 2007   
---

   * section 2, part 1 : I find there is an ambiguity about the VERB parameter. The document states it is an "optional parameter" without telling if it applies to the client or to the server side. I think it should be made clear that this parameter is optional in the query, and that it is not compulsory for compliant services to support it. 
   * section 2, part 1 : typo in sentence "If a query includes an optional parameter ... the service should must ignore that parameter."
   * In the References section :
      * [VOTable 1.0] link points towards version 1.1 of the document, not version 1.0
      * [RM] link is incorrect (final 'l' is missing in the URL)

   * Although I perfectly understand the need to be backward-compatible with existing Cone Search implementations, there are 2 minor points I would find annoying if I was about to develop a new CS service, and willing to conform to the standard :
      * the document compels to use the old UCD1, at least for the 3 compulsory fields (unless I repeat these 3 fields with corresponding UCD1+, which is rather ugly)
      * I feel uneasy about the ambiguity on the location of the ERROR parameter. If we plan to choose one location over another in a future document, it will mean changes at the service level anyway. Otherwise, the document should state explicitely (not only in the editor's note)that both locations are allowed.
-- IVOA.ThomasBoch - 28 Mar 2007
---
   * "Compliance REQUIRES that a web service be maintained responds to...":
      * Needs rewording.

   * "RA -- a right-ascension in the J2000 coordinate system..." (also DEC):
      * Coordinate systems are not my thing, but J2000 looks like an epoch to me, rather than a coordinate system.  Shouldn't this say something like "the ICRS coordinate system" or "the FK5(J2000)" coordinate system?  However I am happy to defer to somebody who knows what they're talking about here.

   * "There may be other parameters ... , the service should must ignore that parameter":
      * Choose either "should" or "must".

   * "The basic MIME-type of the HTTP response should be text/xml.  The more specific form text/xml;x-votable may optionally be used.":
      * "text/xml;x-votable" is not a legal MIME type.  The generally agreed MIME type for VOTable is "application/x-votable+xml", though "text/x-votable+xml" would make sense as well (see RFC3023).

   * "Exactly one FIELD must have ucd="ID_MAIN", with the type string":
      * Technically, "string" is not a VOTable data type.  This should probably say something like "with a string type" or "with a character array type".

   * "In case of error, the service MUST respond with a VOTable that contains a single parameter called Error":
      * For definiteness, I'd reword as "a single PARAM with name='Error'", or "a single PARAM or INFO with name='Error'", depending on what best matches current practice.

   * Ref [VOTable v1.0]:
      * The target of this link is the VOTable 1.1 spec, not the 1.0 one.
-- IVOA.MarkTaylor - 28 Mar 2007

---

   * I suggest to add a parameter DATE (or any else wording) to the set of query constraints in order to permit queries with solar system objects. Without this parameter, the cone-search queries will exclude these celestial bodies.

-- IVOA.JeromeBerthier - 19 Avr 2007   

_add edits here_
<hr/>





<!-- ============ PLACE COMMENTS ABOVE THIS LINE ============= -->
<!--

---++ Comments from the Technical Coordination Group

TWG members should add their comments under their name.
The deadline for comments is ... [will begin after public review period].

<br/>
-->
Topic revision: r7 - 2007-04-19 - JeromeBerthier
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema