Simple Cone Search Proposed Recommendation: Request for Comments

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

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 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

-- DougTody - 2007-03-21

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

-- 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.

add edits here