SODA gripes (3): Explanatory introduction

[François Bonnarel]

Hi James, all
On 11/02/2016 08:36, James.Dempsey at csiro.au wrote:
> 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!
I understand fairly well the need you express. I KNew it had to be done 
and I am gratefull to Markus to have made a very good start. But when 
you look to what he as actually done it is more a text on how Discovery 
services, DataLink and SODA services work together than a SODA 
implementation note stricto sensu.

I agree some pure SODA implementation section is usefull in the Spec, 
however let me explain why I think it could be  better to have a global 
implementation note in addition.
A couple of days ago I tried to explain why DAL WG had strong reasons to 
make the development of specifications more modular. I don't think we 
can avoid that. But the drawback is cross-referencing of protocols specs 
and none of these giving the full view of how it could work. I think we 
need this independant document explaining how ObsTap , SIAV2, DataLink, 
and SODA can work together. This will give a global view for 
implementers of N-D dataset discovery and access services without 
looking for explanations in other specs all the time.

    If it is an implementation note another benefit will be that it can 
be upgraded each time an individual protocol is upgraded without an 
heavy procedure. If we change DataLink or SIAV2c in one year, and SODA 
Spec is allready a rec, the implementation section may be a little bit 
incomplete, not to say obsolete in some respects.

    So let's discuss a little bit more what we want. I will propose a 
note integrating what Markus did.

Cheers
François
> 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