TAP-1.0 Erratum 2: Multiple UPLOAD PostsAuthor: DAL WG Date last changed: 2014-12-22 Date accepted: 2017-05-14RationaleThis 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 ContentThe 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:
Impact AssessmentConsidering 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.NoteThis Erratum was previously part of the TAP1Err1 Note still available on volute. The content reflects §3 of that Note at svn revision 2800. |
TAP-1.0 Erratum 2: Multiple UPLOAD PostsAuthor: DAL WG Date last changed: 2014-12-22 Date accepted: 2017-05-14Rationale | ||||||||
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 ContentThe 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:
Impact AssessmentConsidering 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.NoteThis Erratum was previously part of the TAP1Err1 Note still available on volute. The content reflects §3 of that Note at svn revision 2800.<--
|
TAP-1.0 Erratum 2: Multiple UPLOAD PostsAuthor: DAL WG Date last changed: 2014-12-22 Date accepted: 2017-05-14RationaleThis 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 ContentThe 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:
Impact AssessmentConsidering 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.NoteThis Erratum was previously part of the TAP1Err1 Note still available on volute. The content reflects §3 of that Note at svn revision 2800.<--
|