roadmap 2010-2011

[Paul Harrison]

On 2010-09 -14, at 17:51, Doug Tody wrote:

> Hi All -
> 
> I have some more general comments on SIAV2 inspired by Francois's
> mail below, all of which I agree with.
> 
> As Francois notes progress on SIA2 has been delayed in the past year
> mostly because our small DAL science team was diverted onto the higher
> priority ObsTAP project (long planned GDS query).  PQL was similarly
> delayed, however that directly depends upon ObsDM so this was probably
> just as well.  With ObsTAP/ObsDM soon to stabilize it is time to
> resume work on these two high priority and interlinked interfaces.

So was it not a good thing to have extracted PQL from the TAP standard where it originally was, as we would even now still be waiting for TAP.


> 
> Replacing a comprehensive SIA (or SSA etc.) specification by multiple
> documents is not necessarily such a great idea.  These are science
> software interfaces, used by data providers and client application
> writers who are often only cursorily familiar with VO technology.
> Expecting these folks to read 10 documents and divine how it all
> comes together in one specific interface is unrealistic and is not
> the way to go.  Rather, we should bring the most important bits
> together in one document describing the interface in question,
> and refer to these other documents for the details (VOTable, Char,
> DAL arch, etc. are examples).  

This is probably a religious argument and we will never agree. However it is generally good practice to factor out commonality into separate standards - It is actually a matter of degree, I think that we can all agree that it is sensible that VOTable is a separate standard rather than repeating all the details in each DAL document that uses VOTable. I think that the role of the overall DAL protocol document should be to be an overview referring to these other documents and detailing any special cases. In this age of short attention spans I think that we are more likely to grab someone by having them read one 10 page overview document and then have them read 10 more short documents once they have committed to the idea of implementing, rather than having one 100 page document for each DAL protocol, which is likely to put people off even attempting.

Also the win from strongly factoring the documents comes as soon as someone wants to implement two DAL protocols, as then they can be sure that say 60 pages worth of document is common to both that they would not be sure of if they have to read two 100 page documents and still not be precisely sure that the intention is that 60% is the same.

> Versioning would also be a serious
> problem with the splitting approach, as these documents are likely
> to evolve on different schedules.  I do agree however that some of
> the details can be left to these more general common documents.


It is true that versioning needs to be managed carefully, but as you say the real advantage for the standards process is that they can evolve on different schedules and so faster progress can be made overall, as it can be clear which parts are finalized and which are not, so people can build subcomponents of their overall systems with confidence.

There is an issue whether particular versions of a subsidiary standard are mandated, or whether a minimum version is specified and then it is allowable for updated versions of the subsidiary standards to be used by a service. The first approach favours stability, where the second allows new approaches and bug fixes to be introduced more easily. It should be noted that the problems really only occur for the client of the service (as a service implementation will use versions current at the time of implementation), and in any case the problems for the client are the same once there are two versions of a "monolithic" standard anyway, and we are reaching that point now. Taking VOTable as the canonical example in that case again, it is obviously sensible for a client to try to understand all the versions of VOTable that could be produced and deal with them sensibly if it wants to be a well used client. For this to be achieveable it is obviously necessary that the VOTable standard maintains backward compatibility and that clients are written in an "ignore what I don't understand" fashion.
 
Paul.