UWS 0.4

[Guy Rixon]

Hi folks,

the thing with the accept header only matters if the UWS produces  
XHTML directly. If it always produces application/xml with a  
stylesheet link, then we don't care about accept. This was used in  
UWS 0.2 and I thought we agreeed, in Trieste, to go back to it. So  
far as I'm concerned, the variable MIME-type was an interesting  
experiment but not a good result.

Cheers,
Guy

On 20 Jun 2008, at 14:29, Paul Harrison wrote:

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3006 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/grid/attachments/20080623/207a9afb/attachment-0003.bin>