Difference: TAP-1_0-Err-2 (1 vs. 3)

Revision 32017-06-06 - MarcoMolinaro

 
META TOPICPARENT name="TAP-1_0-Errata"

TAP-1.0 Erratum 2: Multiple UPLOAD Posts

Author: DAL WG

Date last changed: 2014-12-22

Date accepted: 2017-05-14

Rationale

This erratum is related to the upload mechanism in TAP referred to TAP-1.0 specification at §2.5.1. Table upload can happen at job creation time, but the UWS-1.0 recommendation allows parameter posting also after the job creation phase. This means that it should be clarified what should happen when an UPLOAD parameter is posted to a job that has already one or more uploads in place. The proposal is to consider UPLOAD posts as accumulating, i.e. each UPLOAD parameter will trigger the creation of one or more tables. What will be left unspecified is the behaviour of uploading multiple tables having the same name.

Erratum Content

The behaviour of a TAP service when an UPLOAD parameter is posted to it after job creation and when uploaded tables are already present is unspecified. Since UWS allows posting parameters after job creation (see §2.1.11 of UWS), §2.5.1 of TAP-1.0 needs to specify what happens when the UPLOAD parameter is posted into a job that already has one or more uploads.

This Erratum fixes this unspecified behaviour by adding at the end of the TAP-1.0 §2.5.1 the following paragraph:

UPLOAD parameters are accumulating, i.e., each UPLOAD parameter posted to a job will create one or more tables in the TAP_UPLOAD schema. When the table names from two or more upload items agree after case folding, the service behaviour is unspecified. Clients thus cannot reliably overwrite uploaded tables; to correct errors, they have to tear down the existing job and create a new one.

Impact Assessment

Considering that the multiple upload behaviour here described and set as normative was not specified in the recommendation, the change may only affect server side implementations of the TAP specification whether they had chosen a different behaviour before this Erratum was issued.

Note

This Erratum was previously part of the TAP1Err1 Note still available on volute. The content reflects §3 of that Note at svn revision 2800.

Revision 22017-05-26 - MarcoMolinaro

 
META TOPICPARENT name="TAP-1_0-Errata"

TAP-1.0 Erratum 2: Multiple UPLOAD Posts

Author: DAL WG

Date last changed: 2014-12-22

Date accepted: 2017-05-14

Rationale

Changed:
<
<
This erratum is related to the upload mechanism in TAP referred to TAP-1.0 specification at §2.5.1. Table upload can happen at job creation time, but the UWS-1.0 recommendation allows parameter posting also after the job creation phase. This means that it should be clarified what should happen when an UPLOAD parameter is posted to a job that has already one or more uploads in place.
>
>
This erratum is related to the upload mechanism in TAP referred to TAP-1.0 specification at §2.5.1. Table upload can happen at job creation time, but the UWS-1.0 recommendation allows parameter posting also after the job creation phase. This means that it should be clarified what should happen when an UPLOAD parameter is posted to a job that has already one or more uploads in place.
 The proposal is to consider UPLOAD posts as accumulating, i.e. each UPLOAD parameter will trigger the creation of one or more tables. What will be left unspecified is the behaviour of uploading multiple tables having the same name.

Erratum Content

The behaviour of a TAP service when an UPLOAD parameter is posted to it after job creation and when uploaded tables are already present is unspecified. Since UWS allows posting parameters after job creation (see §2.1.11 of UWS), §2.5.1 of TAP-1.0 needs to specify what happens when the UPLOAD parameter is posted into a job that already has one or more uploads.

This Erratum fixes this unspecified behaviour by adding at the end of the TAP-1.0 §2.5.1 the following paragraph:

UPLOAD parameters are accumulating, i.e., each UPLOAD parameter posted to a job will create one or more tables in the TAP_UPLOAD schema. When the table names from two or more upload items agree after case folding, the service behaviour is unspecified. Clients thus cannot reliably overwrite uploaded tables; to correct errors, they have to tear down the existing job and create a new one.

Impact Assessment

Considering that the multiple upload behaviour here described and set as normative was not specified in the recommendation, the change may only affect server side implementations of the TAP specification whether they had chosen a different behaviour before this Erratum was issued.

Note

This Erratum was previously part of the TAP1Err1 Note still available on volute. The content reflects §3 of that Note at svn revision 2800.

<--  
-->

Revision 12017-05-26 - MarcoMolinaro

 
META TOPICPARENT name="TAP-1_0-Errata"

TAP-1.0 Erratum 2: Multiple UPLOAD Posts

Author: DAL WG

Date last changed: 2014-12-22

Date accepted: 2017-05-14

Rationale

This erratum is related to the upload mechanism in TAP referred to TAP-1.0 specification at §2.5.1. Table upload can happen at job creation time, but the UWS-1.0 recommendation allows parameter posting also after the job creation phase. This means that it should be clarified what should happen when an UPLOAD parameter is posted to a job that has already one or more uploads in place. The proposal is to consider UPLOAD posts as accumulating, i.e. each UPLOAD parameter will trigger the creation of one or more tables. What will be left unspecified is the behaviour of uploading multiple tables having the same name.

Erratum Content

The behaviour of a TAP service when an UPLOAD parameter is posted to it after job creation and when uploaded tables are already present is unspecified. Since UWS allows posting parameters after job creation (see §2.1.11 of UWS), §2.5.1 of TAP-1.0 needs to specify what happens when the UPLOAD parameter is posted into a job that already has one or more uploads.

This Erratum fixes this unspecified behaviour by adding at the end of the TAP-1.0 §2.5.1 the following paragraph:

UPLOAD parameters are accumulating, i.e., each UPLOAD parameter posted to a job will create one or more tables in the TAP_UPLOAD schema. When the table names from two or more upload items agree after case folding, the service behaviour is unspecified. Clients thus cannot reliably overwrite uploaded tables; to correct errors, they have to tear down the existing job and create a new one.

Impact Assessment

Considering that the multiple upload behaviour here described and set as normative was not specified in the recommendation, the change may only affect server side implementations of the TAP specification whether they had chosen a different behaviour before this Erratum was issued.

Note

This Erratum was previously part of the TAP1Err1 Note still available on volute. The content reflects §3 of that Note at svn revision 2800.

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