SCS-1.1 internal draft available
Mark Taylor
m.b.taylor at bristol.ac.uk
Mon Jul 17 11:17:21 CEST 2017
On Mon, 17 Jul 2017, Markus Demleitner wrote:
> Hi Walter,
>
> On Fri, Jul 14, 2017 at 11:50:57AM -0700, Walter Landry wrote:
> > Marco Molinaro <molinaro at oats.inaf.it> wrote:
> > > Dear all,
> > > I drafted a first version of the SCS-1.1
> > > as an internal draft for the DAL WG.
> > * Do current cone services use this attribute? (talking about type="results")
> >
> > I set it. I think the question is more whether other tools use it.
>
> It's a service to clients; I'd suspect right now almost all of them
> will just just the first table they find. But as soon as you can
> have more than one resource, it's certainly a good idea to be
> explicit, and of course, it's what DALI says. Consistency is always
> good.
FWIW I think[*] that topcat/stilts do actually require the result
table for Cone Search and other relevant DAL services
to be inside a unique RESOURCE/@type="results" element.
If not, no result is reported.
> > * should we relax on the number of tables?
> >
> > How would that work? Would you specify multiple tables to search at once?
>
> The immediate use case is to allow datalink descriptors in cone
> search results. There are many uses for that, most typically related
> to provenance ("these object properties were derived from these
> spectra"), but lots others are conceivable.
>
> Further down the road, if we tell clients to look at the
> @type="results" resource already now, I suppose we'll have less
> growing pains if we move SCS to actually return object-relational
> material ("Source DM"), for which multi-table (resource?)
> serialisations will be the rule rather than the exception.
... so TOPCAT/STILTS would already be OK with Cone Search services
returning multiple tables, as long as only one is in
RESOURCE/@type="results".
But I can't speak for other clients.
[*] from a look at the code and my recollection. But I can't
easily test it unless somebody out there has a service that
doesn't mark the tables in this way.
--
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/
More information about the dal
mailing list