UWS 0.4

[Paul Harrison]

On 2008-06 -19, at 20:30, Patrick Dowler wrote:

> On 2008-6-16 05:58, Paul Harrison wrote:
>> Although the document might not make this explicit, the intention is
>> that the "minimum" requirement is that a UWS service return XML for
>> all of the job objects (excluding the individual results which may be
>> returned in their "natural" mime type). I.e. MUST support the Accept:
>> application/xml request header.
>>
>> The preliminary schema attached to the document would have the phase
>> returned as
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <uws:phase xmlns:uws="http://www.ivoa.net/xml/UWS/v0.9">COMPLETED
>> </uws:phase>
>>
>> Additionally if the client indicates that it can accept html then the
>> XHTML can be returned - as there is a strong desire to be able to
>> drive these UWS from standard browsers. I am currently a little  
>> unsure
>> how proscriptive we can attempt to be on the form that the XHTML
>> takes, but I think it would be nice if we could find a way of
>> guaranteeing that it works on as wide a range of browsers as possible
>> - i.e. don't be too fancy with the HTML interface, and try to use
>> browser specific features.
>
> Moving along with my UWS implementation, I have stumbled into a few  
> things:
>
> 1. redirect destination
>
> In the case of being driven by the browser, it seems that the best  
> response to
> a POST (modification of the job) is to redirect to the job rather  
> than to the
> modified resource, for a couple of reasons:
>
> - when I modify one resource or POST some new params while setting  
> up the job,
> it seems plausible that the service will modify other resources as  
> well, such
> as changing the quote, termination, or destruction as I specify  
> input files.
> Specifically, the quote and/or termination will likely go up if the  
> inputs
> are large, while a resource-constrained service may decrease the  
> amount of
> time until destruction... I can't see any way to prohibit POST from  
> having
> such side effects. So it seems better to show the user the new job  
> state.
>
> - if one did redirect to the specific resource (eg phase) the page  
> would need
> a link back to the job which the user would immediately click, or  
> the user
> would immediately hit the back button... to see the new job state  
> and/or to
> further modify (other) resources.
>
>
> - in the implementation, I need 3 pages: one with a "create job"  
> form, one
> that displays/edits the job, and one to display the result list. If  
> I also
> need to render pages with just one sub-resource, it adds work/ 
> complexity and
> additional page views and clicks with no apparent benefit

the thinking behind the original suggestion of returning a redirect to  
the subobject is that a "non-browser" client would immediately receive  
a response that shows what the subobject was set to. However, I can  
see that in the interactive use case this is not optimal.
>
>
> So the pattern would be to redirect to the job and always display  
> the job. In
> the XML output mode, I don't see any problem with the sub-resources  
> being
> addressable via GET (and returning the small XML document above);  
> this would
> be especially useful in polling the phase to watch for the  
> transition from
> EXECUTING to COMPLETED. But in general, the redirect-after-post  
> would go to
> the job.
>

I think that I am probably with you on this one - as long as the get  
to the job does always give a full representation of the sub-objects.  
I will change the next version of the spec accordingly unless anyone  
objects.


> 2. Accept header
>
> disclaimer: It seems quite likely that I do not understand the accept
> semantics :-)

and I suspect that you are not alone ;-)
>
>
> Ok, the rules for interpretting this are pretty odd and to get the  
> desired
> behaviour (from firefox) I have to not follow the rules.
>
> In the spec (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html),
> the client can specify multiple mimetypes, each with a "q" value that
> indicates priority. Highest priority is for the most specific type, so
>
>   Accept: text/*, text/html
>
> means the client can take any text type but prefers text/html (more  
> specific),
> while
>
>   Accept: text/plain; q=0.5, text/html
>
> means the client can take these two types but prefers txt/html over  
> text/plain
> (lower q value).
>
> Now, firefox (version 2 at least) sends this (formatted for clarity)
>
>   Accept:
>      text/xml,application/xml,application/xhtml+xml,
>      text/html;q=0.9,text/plain;q=0.8,
>      image/png,
>      */*;q=0.5
>
> which (for UWS) I interpret as:
>
> xml (preferred) -- server can pick from the 3 variants
> then text/html (q=0.9)
> then text/plain (q=0.8)
>
> Why firefox would prefer arbitrary XML to HTML is beyond me. Also,  
> the q=0.5
> on */* is completely redundant since it is also the least specific  
> type and
> hence automatically the lowest priority.
>

well firefox 3 seems a little more sensible

Accept=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8



> For now, I just look through there for text/html and if I find that  
> I write
> HTML. Otherwise, I write XML. Tools like curl just put Accept: */*  
> since they
> do not care (and hence get XML).

I have to admit that is the logic that I have used in the CEA UWS  
implementation that I did for Trieste - i.e. I ignored the q processing

Perhaps the UWS document should say that the server will only serve  
application/xml and application/xhtml+xml - then any client that asks  
for anything else will receive a 406. Note that I am saying that XHTML  
is the minimum acceptable, not just HTML....

>
Cheers,
	Paul.