new UWS 1.1 WD

[Paul Harrison]

On 2014-09 -30, at 16:32, Grégory Mantelet <gmantele at ari.uni-heidelberg.de> wrote:

> Hello Grid,
> 
> I may have a suggestion of modification of the current UWS standard. I probably show up a little late, but what I am suggesting is, according to me, a minor modification and should not impact at all any existing UWS implementation (including in the TAP protocol).
> 
> So, I am wondering whether it would be possible to add (or at least to allow) the 2 following optional attributes for the 'result' item?
> 
>    a/ 'mime', or any other name that would suggest an attribute informing about the type of result. I think a MIME type as value of this attribute would be a good idea.
> 
>    b/ 'size' which will give the size in bytes of the document proposed as result. I think users could be interested in a such piece of information ; they would know how big is the result they have to download. But I think it is particularly useful when several results are available.
> 
>    (b.bis/ In TAP, I think the information about the number of rows contained in the result would be also interesting for some clients. But I do not know how to provide this information in the 'result' item. Probably an attribute "rows", but it would be probably too much in relation with the TAP protocol rather than applying to every kinds of UWS implement ion.

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

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

Paul.

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