SODA gripes (3): Explanatory introduction

[James.Dempsey at csiro.au]

Hi,

I wanted to add support for having the explanatory text within the SODA document, rather than pushed off to a note. It was only after spending 6+ months implementing IVOA standards that I found the notes at all!

The descriptive sections in other IVOA specs have been very helpful when implementing those protocols. SODA is complex enough that I think the guidance is quite necessary to assist implementers in producing compliant services.

Cheers,
James 

________________________________________
From: dal-bounces at ivoa.net [dal-bounces at ivoa.net] on behalf of Markus Demleitner [msdemlei at ari.uni-heidelberg.de]
Sent: Thursday, 11 February 2016 6:06 PM
To: dal at ivoa.net
Subject: Re: SODA gripes (3): Explanatory introduction

Hi,

On Wed, Feb 10, 2016 at 05:48:24PM +0100, François Bonnarel wrote:
>      Sorry for not commenting this email earlier.
>      I also think Markus did a very usefull job, with that introduction.
>      I thought something like that was to be done but I would have opted for
> an implementation Note of ObsTAP_or_SIAV2+DataLink+SODA.
>      Because obviously this describes how these protocols work together to
> combine data discovery to access data facilities, more than SODA alone in
> itself. Next version of ObsTAP, SIAV2 and DataLink could refer to the same
> note.

Well, most people interested in the VO moan that there's so terribly
many different documents to read (there once was an impressive
collection sent around by Tom McGlynn on what he needed to parse to
implement TAP).  We should not lightly increase that number.

In that vein, I still feel SODA shouldn't have been ripped out of
Datalink in the first place.  It's been part the proposal of the
service descriptor part of Datalink from the start, and as we have
seen it cannot really be understood without it.

While that ship has sailed (or has it?  Couldn't Datalink 1.1
re-absorb SODA?), let's not make matters worse by further splitting
up the material.  Also, we're talking about two or three pages, and
they'd be required reading for SODA anyhow.

Our implementors will be grateful.

>       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?  If so: Why define a separate
endpoint (capability?) with essentially the same content as a
datalink document?  Even if you have no additional datalinks, telling
people to stereotypically prepend a one-line (or perhaps even empty)
datalink results table would seem much more economical to me.

Cheers,

           Markus