<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>From: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica">Tom McGlynn <<a href="mailto:Thomas.A.McGlynn@nasa.gov">Thomas.A.McGlynn@nasa.gov</a>></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>Date: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica">30 October 2009 13:45:47 GMT</font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>To: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica">"<a href="mailto:dal@ivoa.net">dal@ivoa.net</a>" <<a href="mailto:dal@ivoa.net">dal@ivoa.net</a>>, <a href="mailto:gws@ivoa.net">gws@ivoa.net</a></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>Subject: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica"><b>TAP Implementation issues (cont'd): UWS</b></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div> </div><div>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.<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>Tom McGlynn<br><br>-- UWS general questions --<br><br>- 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<br> {root}/tap/async?request=doQuery&query=...&phase=RUN<br>to both create and start a query? [Describe it as a POST if you prefer.]<br><br>- 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<br> ../jobid/phase?phase=RUN<br>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.<br><br>- 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.<br><br>- 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.<br><br>- What is supposed to happen if there is a problem in creating the job.<br>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.<br><br>- 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?<br><br>- Is is allowed to have an empty error document? E.g., can I have a URL<br> ".../jobid/error"<br>which exists but has no content (either as an actually zero length string, or as an empty VOTable)?<br><br><br><br>-- TAP specific questions. --<br><br>- 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<br> root/async/jobid/results/<br>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?<br><br>- 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<br><br> <results><br> <result id='someid' xlink:href='someurl' /><br> <result id='anotherid' xlink:href='anotherurl' /><br> </results><br><br>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<br> "When a protocol specifies standard results it must do so by<br> naming those results; the names appear in the Results list in<br> addition to the URI's. Not all results need to be named, sometimes<br> the meaning of the result is obvious from the context and the<br> name is omitted."<br>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.<br><br>- 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.<br></div></blockquote></div><br></body></html>