<div dir="ltr">Hi Markus and all,<div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 7, 2016 at 6:26 AM, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(5) Sect 3.4 still has the "detail" parameter. I still claim this<br>
should be removed. It doesn't help the client (at least until all VOSI<br>
1.0 services are dead, it would still have to be prepared to process<br>
in-root table metadata, and even after they'd probably want the<br>
one-document form if possible). It also doesn't help the service, as it<br>
will have to implement the split form even if it doesn't need it.<br>
<br>
No, I still claim we can simply say:<br>
<br>
In the REST binding, the tableset metadata may be a hierarchical web<br>
resource with a registered URL. In this case, a request to the tables<br>
endpoint returns a document without \xmlel{Column} or<br>
\xmlel{ForeignKey} elements. This signals to a client that detailed<br>
table metadata is available from child resources of the table<br>
resource, named with the fully-qualified table name. For example:<br>
<br>
GET <a href="http://example.net/srv/tables/ivoa.ObsCore" rel="noreferrer" target="_blank">http://example.net/srv/tables/ivoa.ObsCore</a><br>
<br>
would return a Table document describing the ivoa.ObsCore table.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Brian</div></div></div></div></div>