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.