UWS 0.4

[Patrick Dowler]

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

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. 

2. Accept header

disclaimer: It seems quite likely that I do not understand the accept 
semantics :-)

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. 

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

Any thoughts on either issue?

-- 

Patrick Dowler
Tel/Tél: (250) 363-6914                  | fax/télécopieur: (250) 363-0045
Canadian Astronomy Data Centre   | Centre canadien de donnees astronomiques
National Research Council Canada | Conseil national de recherches Canada
Government of Canada                  | Gouvernement du Canada
5071 West Saanich Road               | 5071, chemin West Saanich
Victoria, BC                                  | Victoria (C.-B.)