SODA gripes (3): Explanatory introduction

[Markus Demleitner]

Good Morning DAL,

On Thu, Feb 11, 2016 at 04:21:53PM +0100, François Bonnarel wrote:
> Hi Markus, all;
> On 11/02/2016 08:06, Markus Demleitner wrote:
> >>       On the content itself of this section/note , I would like
> >>                -   to propose a few changes on some details.
> >>                -  add a subsection on SODA self-description (which is
> >>allraedy in the spec. Editor's version)
> >Are you referring to 2.6.3 here?
> I was not joking. Services like SODA are the best placed to describe
> themselves in association with metadata for a single dataset which they
> know.
> Tommorrow we may imagine to use Links towards a new sort of service which
> you can query via loading json files insted of parameters. How will we
> describe this (or other completly different query methods) in the DataLink
> document ? It's better to say in this document that these services are
> autodescriptive.

But Datalink already contains the recipe for how to describe
service parameters; it's section 4 or that document.  The text in
SODA sect. 2.6.3 essentially reflects that, except that it leaves out
the parameter domains (which of course aren't strictly required by
datalink service descriptors, either, which is why we're quarrelling
here).

And thank god that's consistent so far: I'd be fairly annoyed if SODA
now said "We have this way to describe services in Datalink.  In
SODA, you do something else.". And I suspect as to the feelings of
our implementors "annoyed" wouldn't quite be an adequate description
if we really did that.

As to the question what happens when we have what in effect is some
other language to describe requests -- let's see what to do when we
have that language.  If it can do significantly more than the
parameter-based approach we currently have everywhere outside of TAP
(and only then should we even consider a new language), it'll take a
completely different mode of description (see, e.g., TAPRegExt's
langFeatures).  But let's not confuse the present discussion further
when we don't even know what this other thing might be and why we
might need it.

Cheers,

         Markus