VOSI 1.1 initial working draft

[Brian Major]

Dear GWS,

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.

Cheers,
Brian


On Wed, Feb 17, 2016 at 2:06 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Hi all,
>
> On Tue, Feb 16, 2016 at 05:02:36PM +0000, Mark Taylor wrote:
> > 303 Redirect:
> >    I can sort of see the point of issuing a 303 redirect to the
> >    ?detail=min endpoint in the case of refusing the full dataset;
> >    it gives clients a way to determine whether they have been
> [...]
> >    So I'd be inclined to suggest dropping this part of the proposal,
> >    since it complicates matters without adding much.
>
> +1 from me.  Make that +2.  Actually, I never liked the whole
> ?detail=min thing anyway -- only the service knows if it's wise to
> dump the whole thing or return it in small bits, and the client needs
> to be prepared for both ways, too.  As Mark says, it's easy for the
> client to figure out which way the service chose by looking at
> whether or not the table definitions are empty.
>
> The only advantage detail=min might buy could be backwards
> compatibility, and that we cannot fix -- VizieR won't output their
> full table schema ever (and shouldn't), and in that case it's still
> better if they at least return their table names to the legacy
> client.
>
> >    I would suggest instead:
> >
> >       tap_url/tables?detail=min  - service must not include detail
> >       tap_url/tables?detail=max  - service decides, but client would
> like detail
> >       tap_url/tables             - service decides, client has no
> preference
> >
> >    The service remains free to implement detail=max in the same way
> >    as for no detail argument.
> >
> >    Having written that ... maybe it's not such a great idea, since it's
> >    not intuitively obvious that detail=max should be able to decay to
>
> ...and there's no point introducing client control here since clients
> will have to implement both ways anyway.
>
> Unless we're willing to go for two-step throughout (and I don't think
> that's a good idea since it would break a lot of services), let's
> just leave it to the service and tell the clients "If it's an empty
> table, retrieve the full table definition from ...tables/<tablename>."
>
> [where I have a slight preference for keeping things in the path part
> rather than introducing a parameter, but I really don't care much]
>
> Cheers,
>
>          Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20160311/58ea975b/attachment.html>