TAP Implementation issues (cont'd): UWS

[Tom McGlynn]

I've had a few questions with the implementation of the asynchronous 
access for TAP.  Most of these are relevant to UWS document generally 
rather than just TAP so I've copied the GWS group in this mail.

	Tom McGlynn

-- UWS general questions --

- As defined a user needs to always do two web actions to start the 
service.  Is there some reason that the user cannot simply request the 
service to start running immediately?  I suspect that that is what the 
user wants to do in 99% of the cases.  It would be much easier for 
clients too.  The example given in the UWS document of starting a job 
omits the error checking that the a user presumably should do after 
starting the job.  Why not allow
      {root}/tap/async?request=doQuery&query=...&phase=RUN
to both create and start a query?  [Describe it as a POST if you prefer.]

- I'm continue to be confused by the benefits conferred by various 
practices.  Why do we require POSTs specifically in a number of 
intances?  E.g., what would be wrong with using
     ../jobid/phase?phase=RUN
as an HTTP GET rather than an HTTP POST.  Since my code cannot tell the 
difference between these I certainly will be supporting both, but, other 
than bowing to the mantra REST, I'm not sure why it's supposed to matter.

- Similarly I don't think that there should be a strict limitation of 
the coding used in sending requests.  There may be a requirement that a 
given encoding be supported but there should not be a requirement that 
it be used.  As with POST/GET this level of HTTP detail is handled below 
the UWS logic in our implementation, so for services that the HEASARC 
supports we'll be allowing multipart/form encoding as well unless 
someone can tell us why we should reject such requests.

- From what states is a user allowed to start a job?  E.g., can a user 
attempt to restart a job that has previously had an error or aborted? 
Could the user change the parameters and then rerun the same job?  I'm 
guessing this isn't supposed to happen, but I didn't see where it was 
forbidden.

- What is supposed to happen if there is a problem in creating the job.
Should a job be created with an immediate status of ERROR?  Is there any 
way of flagging an error if the system cannot create even an error job? 
  E.g., we're going to use the database to store all job information. 
What are we supposed to do if the database is down?  It would be nice to 
be able to inform the user of an error in a standard way.

- Is there supposed to be a one-one mapping between there being an error 
resource and the job failing with error or aborted.  I.e., if I have a 
job with phase COMPLETED can it still have an error document?  Can I 
have phase ABORTED without an error document?

- Is is allowed to have an empty error document?  E.g., can I have a URL
   ".../jobid/error"
which exists but has no content (either as an actually zero length 
string, or as an empty VOTable)?



-- TAP specific questions. --

- The description of where to get the TAP result in an async request is 
not given (as far as I can see) in what is described as the normative 
parts of the document.  There it says that result will be in
    root/async/jobid/results/
but this is the list of results and can, in principle, contain a number 
of results. Only in section 5.2 which is described as informative does 
it say that the result document is .../results/result.  Is this actually 
  a requirement or can the result be named anything?

- The UWS standard discusses the naming of results.  Does TAP require a 
specific name for the result?  In fact it looks like the way UWS is 
supposed to be used the jobid/results returns a document that looks like

     <results>
        <result id='someid' xlink:href='someurl' />
        <result id='anotherid' xlink:href='anotherurl' />
     </results>

and the user is supposed to find the id of the desired result and use 
whatever URL is given there, not use a specifically defined URL.  I'm 
guessing the the ID attributes of the <result> fields is the UWS name. 
The UWS standard says
   "When a protocol specifies standard results it must do so by
    naming those results; the names appear in the Results list in
    addition to the URI's.  Not all results need to be named, sometimes
    the meaning of the result is obvious from the context and the
    name is omitted."
Since the second sentence here seems to contradict the first it's a bit 
hard to follow, but my reading of this is that it would be better for 
TAP to specify a name for the output result rather than a specific URL.

- The TAP RFC document still links to the June version of the document. 
  While there is a comment before the TCG review section indicating that 
there is a new document, this should probably be noted and linked to at 
the very top of the document.