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