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

DALI/VOSI endpoints

Trying to move SCS to a better DALI compliance, at least the capabilities endpoint should be provided.

One problem to do so is that SCS-1.03 defines the base URL as http://server/path?query with the query part being a set of optional fixed params to be set before the cone search constraint params.

VOTable versioning and RESPONSEFORMAT

Relaxing VOTable requirement: currently mandating versions 1.0 or 1.1.

Allowing for other optional RESPONSEFORMATs (as per DALI).

Error response

Try to move error responses into a DALI-like shape.

§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)?

UCD update

SCS-1.03 requires UCD 1.0 annotations. Is there a way to make UCD1+ cope with back compatibility?

Metadata discovery

SCS-1.03 suggests usage of SR=0 queries to have service metadata discovery. The idea is to back it up with the DALI MAXREC solution for this purpose.

Registry extension inclusion

Move SimpleDALRegExt cone search content into SCS-1.1 while removing current section 3 and appendix B (SCS-1.03).

Allowing HTTP POST

DALI allows indifferently HTTP GET or POST on synchronous endpoints.

Allowing optional POST from SCS-1.1 opens two issues at least

• the extra query params in the base URL: should they go into POST data or should we allow mixed content or both?
• how to alert clients properly if we don't put a strict choice for POSTing with extra args in place?