Fwd: TAP Implementation issues (cont'd): UWS

[Guy Rixon]

Begin forwarded message:

> From: Tom McGlynn <Thomas.A.McGlynn at nasa.gov>
> Date: 30 October 2009 13:45:47 GMT
> To: "dal at ivoa.net" <dal at ivoa.net>, gws at ivoa.net
> Subject: TAP Implementation issues (cont'd): UWS
>
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/grid/attachments/20091030/c6b80b29/attachment-0003.html>