Difference: SCS-1_03-Next (1 vs. 5)

Revision 52020-05-06 - MarcoMolinaro

 
META TOPICPARENT name="ConeSearch"
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).
 

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.

<--  
-->

Revision 42017-10-11 - MarcoMolinaro

 
META TOPICPARENT name="ConeSearch"

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

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.

Added:
>
>

EPOCH query parameter

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

 
<--  
-->

Revision 32017-10-09 - MarcoMolinaro

 
META TOPICPARENT name="ConeSearch"

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

Changes

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

Minor 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:
 
  • 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

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

Revision 22017-07-20 - MarcoMolinaro

 
META TOPICPARENT name="ConeSearch"

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

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:
  • 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
 
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 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.
Deleted:
<
<
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?
 
<--  
-->

Revision 12017-07-11 - MarcoMolinaro

 
META TOPICPARENT name="ConeSearch"

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?

<--  
-->
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback