<div dir="ltr"><div>Dear GWS,</div><div><br></div><div>Aside from some minor details and editing tasks, I think there is general agreement with this 1.1 version of the VOSI working draft. I plan on starting the RFC period of a proposed recommendation four weeks from now.</div><div><br></div><div>Cheers,</div><div>Brian</div><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 17, 2016 at 2:06 AM, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<span class=""><br>
On Tue, Feb 16, 2016 at 05:02:36PM +0000, Mark Taylor wrote:<br>
> 303 Redirect:<br>
> I can sort of see the point of issuing a 303 redirect to the<br>
> ?detail=min endpoint in the case of refusing the full dataset;<br>
> it gives clients a way to determine whether they have been<br>
</span>[...]<br>
<span class="">> So I'd be inclined to suggest dropping this part of the proposal,<br>
> since it complicates matters without adding much.<br>
<br>
</span>+1 from me. Make that +2. Actually, I never liked the whole<br>
?detail=min thing anyway -- only the service knows if it's wise to<br>
dump the whole thing or return it in small bits, and the client needs<br>
to be prepared for both ways, too. As Mark says, it's easy for the<br>
client to figure out which way the service chose by looking at<br>
whether or not the table definitions are empty.<br>
<br>
The only advantage detail=min might buy could be backwards<br>
compatibility, and that we cannot fix -- VizieR won't output their<br>
full table schema ever (and shouldn't), and in that case it's still<br>
better if they at least return their table names to the legacy<br>
client.<br>
<span class=""><br>
> I would suggest instead:<br>
><br>
> tap_url/tables?detail=min - service must not include detail<br>
> tap_url/tables?detail=max - service decides, but client would like detail<br>
> tap_url/tables - service decides, client has no preference<br>
><br>
> The service remains free to implement detail=max in the same way<br>
> as for no detail argument.<br>
><br>
> Having written that ... maybe it's not such a great idea, since it's<br>
> not intuitively obvious that detail=max should be able to decay to<br>
<br>
</span>...and there's no point introducing client control here since clients<br>
will have to implement both ways anyway.<br>
<br>
Unless we're willing to go for two-step throughout (and I don't think<br>
that's a good idea since it would break a lot of services), let's<br>
just leave it to the service and tell the clients "If it's an empty<br>
table, retrieve the full table definition from ...tables/<tablename>."<br>
<br>
[where I have a slight preference for keeping things in the path part<br>
rather than introducing a parameter, but I really don't care much]<br>
<br>
Cheers,<br>
<br>
Markus<br>
</blockquote></div><br></div></div>