SCS-1.03 NextThis 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). | ||||||||
Changed: | ||||||||
< < | DALI/VOSI endpoints | |||||||
> > | Changes | |||||||
Changed: | ||||||||
< < | Trying to move SCS to a better DALI compliance, at least the capabilities endpoint should be provided. | |||||||
> > | Error Response | |||||||
Added: | ||||||||
> > | Changed to conform DALI, letting heritage as allowed but deprecated. | |||||||
Changed: | ||||||||
< < | 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. | |||||||
> > | Resource Registration | |||||||
Added: | ||||||||
> > | Dropped SCS-1.03 section and appendixes related to metadata mapping and imported SimpleDALRegExt SCS-related content. | |||||||
Changed: | ||||||||
< < | VOTable versioning and RESPONSEFORMAT | |||||||
> > | RA and Dec datatype | |||||||
Added: | ||||||||
> > | Relaxed to allow float alongside double | |||||||
Changed: | ||||||||
< < | Relaxing VOTable requirement: currently mandating versions 1.0 or 1.1. | |||||||
> > | MAXREC and RESPONSEFORMAT | |||||||
Added: | ||||||||
> > | Added to follow DALI, but without outlawing SR=0 and mandatory VOTable response. [Possible next change: suggest usage of RESPONSEFORMAT for BINARY VOTable output] | |||||||
Changed: | ||||||||
< < | Allowing for other optional RESPONSEFORMATs (as per DALI). | |||||||
> > | DALI/VOSI endpoints | |||||||
Added: | ||||||||
> > | Added support for capabilities and availability, but check discussion about this referring to GET/POST ARGS | |||||||
Changed: | ||||||||
< < | Error response | |||||||
> > | VOTable response version | |||||||
Added: | ||||||||
> > | Relaxed to allow any (but discussion on back-compatibility still in place) | |||||||
Changed: | ||||||||
< < | Try to move error responses into a DALI-like shape. | |||||||
> > | Metadata discovery | |||||||
Added: | ||||||||
> > | Moved to MAXREC=0 usage, but not removing the SR=0 alternative. | |||||||
Changed: | ||||||||
< < | §2.3b INFO element error validation | |||||||
> > | HTTP methods | |||||||
Added: | ||||||||
> > | Allowing HTTP POST actions, but see discussion on GET args | |||||||
Changed: | ||||||||
< < | Most SCS-1.03 service fail validation due to a controversial interpretation of the "single INFO element" to be used to report error responses. | |||||||
> > | Discussion Topics | |||||||
Deleted: | ||||||||
< < | Should this be matter for an Erratum to SCS-1.03 (and then be cleaned up in SCS-1.1)? | |||||||
Changed: | ||||||||
< < | UCD update | |||||||
> > | Minor vs. Major revision | |||||||
Added: | ||||||||
> > | 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. | |||||||
Changed: | ||||||||
< < | SCS-1.03 requires UCD 1.0 annotations. Is there a way to make UCD1+ cope with back compatibility? | |||||||
> > | RESOURCE type="results" and its TABLE | |||||||
Added: | ||||||||
> > | 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. | |||||||
Changed: | ||||||||
< < | Metadata discovery | |||||||
> > | ReST versus query-param interface | |||||||
Added: | ||||||||
> > | 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:
| |||||||
Changed: | ||||||||
< < | 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. | |||||||
> > | §2.3b INFO element error validation | |||||||
Changed: | ||||||||
< < | Registry extension inclusion | |||||||
> > | Most SCS-1.03 service fail validation due to a controversial interpretation of the "single INFO element" to be used to report error responses. | |||||||
Added: | ||||||||
> > | Should this be matter for an Erratum to SCS-1.03 (and then be cleaned up in SCS-1.1)? | |||||||
Changed: | ||||||||
< < | Move SimpleDALRegExt cone search content into SCS-1.1 while removing current section 3 and appendix B (SCS-1.03).
Allowing HTTP POST | |||||||
> > | UCD updateSCS-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. | |||||||
Deleted: | ||||||||
< < |
DALI allows indifferently HTTP GET or POST on synchronous endpoints.
Allowing optional POST from SCS-1.1 opens two issues at least
| |||||||
<--
|
SCS-1.03 NextThis 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 endpointsTrying 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 RESPONSEFORMATRelaxing VOTable requirement: currently mandating versions 1.0 or 1.1. Allowing for other optional RESPONSEFORMATs (as per DALI).Error responseTry to move error responses into a DALI-like shape.§2.3b INFO element error validationMost 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 updateSCS-1.03 requires UCD 1.0 annotations. Is there a way to make UCD1+ cope with back compatibility?Metadata discoverySCS-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 inclusionMove SimpleDALRegExt cone search content into SCS-1.1 while removing current section 3 and appendix B (SCS-1.03).Allowing HTTP POSTDALI allows indifferently HTTP GET or POST on synchronous endpoints. Allowing optional POST from SCS-1.1 opens two issues at least
<--
|