VOSI 1.1 review

[Brian Major]

Hi Markus and all,

On Sat, May 7, 2016 at 6:26 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:
>
>

(5) Sect 3.4 still has the "detail" parameter.  I still claim this
> should be removed.  It doesn't help the client (at least until all VOSI
> 1.0 services are dead, it would still have to be prepared to process
> in-root table metadata, and even after they'd probably want the
> one-document form if possible).  It also doesn't help the service, as it
> will have to implement the split form even if it doesn't need it.
>
> No, I still claim we can simply say:
>
>   In the REST binding, the tableset metadata may be a hierarchical web
>   resource with a registered URL.  In this case, a request to the tables
>   endpoint returns a document without \xmlel{Column} or
>   \xmlel{ForeignKey} elements.  This signals to a client that detailed
>   table metadata is available from child resources of the table
>   resource, named with the fully-qualified table name.  For example:
>
>     GET http://example.net/srv/tables/ivoa.ObsCore
>
>   would return a Table document describing the ivoa.ObsCore table.
>

I've made a revision to the document to clarify the role of the detail
parameter based on our conversations in Stellenbosch.   Essentially, the
presence of the detail parameter with a value of 'min' or 'max' is a
suggestion to the service as to what level of table detail to provide (with
or without Column and ForeignKey elements), but the service may choose
whichever.  If the detail parameter is not provided, the service may again
choose whichever level of detail.  This ensures full backwards
compatibility with 1.0 and allows services with a lot of table metadata to
always return the minimum level of detail.

Cheers,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20160705/5b6aa700/attachment.html>