new UWS 1.1 WD

[Grégory Mantelet]

On 01.10.2014 09:16, Paul Harrison wrote:
> Putting my REST hat on I would say that it should be possible to get  a and b above by doing an HTTP HEAD on the result URL and you could probably do b.bis with a custom HTTP header key on that HTTP HEAD response. That said,  I think that “size” in particular is so fundamental that it probably could be added to the result attribute schema definition - mime type is more subtle for the reasons below

Using HTTP HEAD sounds a good idea in the sense that it does not imply a 
modification of the XML schema. However it means that clients must do an 
additionnal request to get the type/mime and size of a result. Besides, 
if not described in the standard, clients must know which servers/UWS 
implementations provide such information with HTTP HEAD requests. And 
finally, if this way of retrieving type and size is proposed in addition 
of 2 new optional attributes in the 'result' item, clients will have 2 
methods to get them....2 methods that server must implement. I would say 
that one method is largelly enough, and particularly for optional 
attributes. Personnaly I prefer the "optional attributes" method, 
because much more intuitive for users who see directly all important 
information in one request (how many results, their id, access url, 
type/mime and size).

> On 2014-09 -30, at 20:11, Kristin Riebe <kriebe at aip.de> wrote:
>
>> Hi Grid,
>>
>> I would also very much like some kind of format or mime attribute to uws result, e.g. like this:
>>
>> <uws:result id="xxx" format="csv" ...>
>>
>> In our case we have a UWS service that returns results as csv-file, ascii-votable, votable binary I or II. Currently, we list all 4 possibilities with uws:results.
>> But a general client can't distinguish between a query that returns multiple results with *different content* and *different formats* of the same content.
>>
>> A format- or mime-attribute could help a lot here. I think in that case I would also prefer if the result id could be the same, if only the formats are different (though generally result ids should be unique).
>> Or is there any other mechanism already in place to handle this?
> the standard HTTP /REST way of achieving this is to use the ACCEPT header on the result URL http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html - which gives the client the mechanism to say which of the different forms that it would want - however, advertising what is available is not so clear - see for example the discussion on https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation.
>
> However, although there are standard mechanisms for getting this information, In both cases I think that it would make life easier if we were simply to allow a size and mime-type attribute on the result element. In fact given that the standard HTTP mechanisms are not that good for mime type advertising, having an attribute that listed the available mime types for a resource would be an improvement. I think that I would prefer a mime attribute that contained a comma separated list of available mime types rather than multiple result elements for the same logical result - then the ACCEPT header mechanism could be used on the single result URL.

I also think that listing available formats for a given logical result, 
and choosing a format using the ACCEPT header is a good idea.

> I think that they could be added to 1.1 - the only downside would be that requires a schema change officially and we come back to that tricky question of how strict old clients (and new ones) are about XML validation - if only we had not used XML schema define the XML structures and had an “ignore what you don’t understand” general rule in place it would be much easier to evolve these standards.

Yes, that's true. It would be interesting to see how many UWS clients 
expect a strict XML document. For instance, I think that the TAP 
interface (for asynchronous requests) of TOPCAT does not.

> Paul.
>
> p.s. I think that your b.bis is a step too far to include in the UWS standard!

Yes, I agree...that's why I put it in bis and inside parenthesis. But my 
goal was just to keep that use case in mind while modifying the 'result' 
item....particularly if a possibility of an open XML structure allows 
additionnal custom attributes for the 'result' item. I think that 
allowing more attributes could be a good idea: first, because it allows 
a 'rows' attribute in the context of TAP, and then, because it does not 
block old clients on a too strict XML schema (which is now our "problem" 
for 'mime' and 'size' attributes).

Regards,
Grégory