| ||||||||
Changed: | ||||||||
< < | SCS-1.03 Next | |||||||
> > | Simple Cone Search 1.03 Next | |||||||
| ||||||||
Changed: | ||||||||
< < | 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). | |||||||
> > | 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. | |||||||
Added: | ||||||||
> > | Remember to sign your comments using your wikiname (and date). | |||||||
ChangesError ResponseChanged to conform DALI, letting heritage as allowed but deprecated.Resource RegistrationDropped SCS-1.03 section and appendixes related to metadata mapping and imported SimpleDALRegExt SCS-related content.RA and Dec datatypeRelaxed to allow float alongside doubleMAXREC and RESPONSEFORMATAdded 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 endpointsAdded support for capabilities and availability, but check discussion about this referring to GET/POST ARGSVOTable response versionRelaxed to allow any (but discussion on back-compatibility still in place)Metadata discoveryMoved to MAXREC=0 usage, but not removing the SR=0 alternative.HTTP methodsAllowing HTTP POST actions, but see discussion on GET argsDiscussion TopicsMinor vs. Major revisionEspecially 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 TABLECurrently 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 interfaceMost 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:
§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)? An Erratum has been issued to solve this point -- MarcoMolinaro - 2017-10-09UCD 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.EPOCH query parameterFor correct searches on sky positions stored at different epochs server-side.<--
|
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). ChangesError ResponseChanged to conform DALI, letting heritage as allowed but deprecated.Resource RegistrationDropped SCS-1.03 section and appendixes related to metadata mapping and imported SimpleDALRegExt SCS-related content.RA and Dec datatypeRelaxed to allow float alongside doubleMAXREC and RESPONSEFORMATAdded 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 endpointsAdded support for capabilities and availability, but check discussion about this referring to GET/POST ARGSVOTable response versionRelaxed to allow any (but discussion on back-compatibility still in place)Metadata discoveryMoved to MAXREC=0 usage, but not removing the SR=0 alternative.HTTP methodsAllowing HTTP POST actions, but see discussion on GET argsDiscussion TopicsMinor vs. Major revisionEspecially 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 TABLECurrently 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 interfaceMost 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:
§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)? An Erratum has been issued to solve this point -- MarcoMolinaro - 2017-10-09UCD 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. | ||||||||
Added: | ||||||||
> > |
EPOCH query parameterFor correct searches on sky positions stored at different epochs server-side. | |||||||
<--
|
SCS-1.03 Next | ||||||||
Changed: | ||||||||
< < | ||||||||
> > | ||||||||
Added: | ||||||||
> > | ||||||||
Changed: | ||||||||
< < | ||||||||
> > | ||||||||
Changed: | ||||||||
< < | This page collects ideas and features to bring Simple Cone Search to revision 1.1 (or, possibly further). | |||||||
> > | 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). | |||||||
Deleted: | ||||||||
< < | 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). | |||||||
ChangesError Response | ||||||||
Added: | ||||||||
> > | ||||||||
Changed to conform DALI, letting heritage as allowed but deprecated.
Resource Registration | ||||||||
Added: | ||||||||
> > | ||||||||
Dropped SCS-1.03 section and appendixes related to metadata mapping and imported SimpleDALRegExt SCS-related content.
RA and Dec datatype | ||||||||
Added: | ||||||||
> > | ||||||||
Relaxed to allow float alongside double
MAXREC and RESPONSEFORMAT | ||||||||
Deleted: | ||||||||
< < | Added to follow DALI, but without outlawing SR=0 and mandatory VOTable response. [Possible next change: suggest usage of RESPONSEFORMAT for BINARY VOTable output] | |||||||
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] | |||||||
DALI/VOSI endpoints | ||||||||
Added: | ||||||||
> > | ||||||||
Added support for capabilities and availability, but check discussion about this referring to GET/POST ARGS
VOTable response version | ||||||||
Added: | ||||||||
> > | ||||||||
Relaxed to allow any (but discussion on back-compatibility still in place)
Metadata discovery | ||||||||
Added: | ||||||||
> > | ||||||||
Moved to MAXREC=0 usage, but not removing the SR=0 alternative.
HTTP methods | ||||||||
Added: | ||||||||
> > | ||||||||
Allowing HTTP POST actions, but see discussion on GET args
Discussion TopicsMinor vs. Major revision | ||||||||
Deleted: | ||||||||
< < | 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. | |||||||
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. | |||||||
RESOURCE type="results" and its TABLE | ||||||||
Deleted: | ||||||||
< < | 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. | |||||||
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. | |||||||
ReST versus query-param interface | ||||||||
Changed: | ||||||||
< < | Most services use fixed parameters in the SCS base URL. SCS-1.1 will allow this but deprecate it. | |||||||
> > | 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: | |||||||
Deleted: | ||||||||
< < | Allowing it there's a clear constraint on: | |||||||
§2.3b INFO element error validation | ||||||||
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. | |||||||
> > | 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)? | |||||||
Deleted: | ||||||||
< < | Should this be matter for an Erratum to SCS-1.03 (and then be cleaned up in SCS-1.1)? | |||||||
Added: | ||||||||
> > | An Erratum has been issued to solve this point -- MarcoMolinaro - 2017-10-09 | |||||||
UCD update | ||||||||
Changed: | ||||||||
< < | 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. | |||||||
> > | 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. | |||||||
<--
|
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
<--
|