TAP Implementation issues (cont'd): UWS

[Matthew Graham]

Hi Tom,

Firstly as UWS is currently under RFC, could you please post these  
comments to the RFC page:

http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/UWSV1RFC

On Oct 30, 2009, at 6:48 AM, Tom McGlynn wrote:

> 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 believe that this is possible.

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

Your code might not be able to tell the difference between these but  
one is meant to be idempotent (HTTP GET) and the other not (HTTP  
POST). Although this is fundamental to the uniform interface semantics  
of REST, it is actually defined in the HTTP specification (RFC2616  
Sect. 9.1.2). The classic no-no is doing something like: ./jobid/phase? 
phase=ABORT with HTTP GET since the "side-effects of N>0 identical  
requests" will not be the same as for a single request.

I'll leave it to others to respond to the more specific UWS and TAP  
questions below.

	Cheers,

	Matthew


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