Simple Cone Search 1.03 Next

This page collects ideas and features to bring Simple Cone Search to revision 1.1 (or, possibly further). Items collected here can be directly discussed within their sections or on the DAL mailing list. Remember to sign your comments using your wikiname (and date).

Changes

Error Response

Changed to conform DALI, letting heritage as allowed but deprecated.

Resource Registration

Dropped SCS-1.03 section and appendixes related to metadata mapping and imported SimpleDALRegExt SCS-related content.

RA and Dec datatype

Relaxed to allow float alongside double

MAXREC and RESPONSEFORMAT

Added to follow DALI, but without outlawing SR=0 and mandatory VOTable response. [Possible next change: suggest usage of RESPONSEFORMAT for BINARY VOTable output]

DALI/VOSI endpoints

Added support for capabilities and availability, but check discussion about this referring to GET/POST ARGS

VOTable response version

Relaxed to allow any (but discussion on back-compatibility still in place)

Metadata discovery

Moved to MAXREC=0 usage, but not removing the SR=0 alternative.

HTTP methods

Allowing HTTP POST actions, but see discussion on GET args

Discussion Topics

Minor vs. Major revision

Especially with reference to the VOTable output version and UCD usage. Major version would solve issues, but it can be a problem for recommendation takeup time. Minor version may face an impossibility, depending on the 1.0 and 1.1 server and client software requirements.

RESOURCE type="results" and its TABLE

Currently most 1.0 services do not set the @type for RESOURCE. Also 1.1 should relax a bit on the number of RESOURCES/TABLES allowed in response, e.g. with respect to Datalink needs.

ReST versus query-param interface

Most services use fixed parameters in the SCS base URL. SCS-1.1 will allow this but deprecate it. Allowing it there's a clear constraint on:

• allowing POST actions (where do you put existing GET args?)
• how to deal with /capabilities (sibling to {query} resource and not meant to allow query parameterization

§2.3b INFO element error validation

Most SCS-1.03 service fail validation due to a controversial interpretation of the "single INFO element" to be used to report error responses. Should this be matter for an Erratum to SCS-1.03 (and then be cleaned up in SCS-1.1)?

An Erratum has been issued to solve this point -- MarcoMolinaro - 2017-10-09

UCD update

SCS-1.03 requires UCD 1.0 annotations. Is there a way to make UCD1+ cope with back compatibility? Seems there's not this chance for minor revision. We can probably live with 3 UCD-1.0 elements.

EPOCH query parameter

For correct searches on sky positions stored at different epochs server-side.