VOSI 1.1 review

[Mark Taylor]

Great.  I'd hope to have client support (prototype at least) in
topcat on a similar timescale.

On Wed, 6 Jul 2016, Patrick Dowler wrote:

> I plan to implement this VOSI-tables behaviour in  or TAP services
> sometime soon (weeks at most).
> 
> On 5 July 2016 at 16:42, Brian Major <major.brian at gmail.com> wrote:
> > 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
> 
> 
> 
> -- 
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/