IVOA Document Standards RFC V1.2

[Mark Taylor]

On Fri, 3 Jul 2009, Robert Hanisch wrote:

> >Bob wrote:
> >> But making the implementations and the validator mandatory for promotion is
> >> where I, and Christophe and Francoise, feel it is necessary to pause.  For
> >> example, if right now we were to enforce this requirement on TAP, with the
> >> resource constraints we have in several of the major projects, we would be
> >> forced to stop the promotion process.  This would be an awful situation for
> >> IVOA, I think.  We want prototypes to inform the standards development
> >> process, for sure, we SHOULD have them, but from a management perspective I
> >> think we have to avoid boxing ourselves into a corner.
> >
> Mark wrote:
> > I agree with you that requiring the associated software would slow down
> > the promotion process.  However, as I tried to make clear in my previous
> > message, I don't believe that the date of publication of the
> > Recommendation is what we should be focussing on.
> > When a document reaches Recommendation status, yes it looks good on
> > Gantt charts, but all it means is we have a bit of paper to wave
> > in the air.  Nothing useful has been achieved until effective use of
> > that standard is made, which in most cases requires software to be
> > written.  I believe that attaining that second goal will actually
> > be accelerated rather than decelerated if the software is written
> > in tandem with the text (I tried to get you to agree or disagree with
> > this statement in my last message, but I still don't know your opinion).
> > Doing them in parallel will also lead to a better standard.
> > 
> > In any case: if you can't find anyone who is prepared to implement
> > the standard, there's probably a good reason; either it's too hard
> > to do, or it's not something that people need.  In either case
> > it's no great achievement to have published it.
> I disagree with you on this point, and perhaps that is the crux of the
> issue.  Many organizations will not even look at an IVOA standard until it
> has been finalized.  They say "why should I bother implementing something
> that is just going to change."  Plus, like it or not, just reaching
> agreement on the standard IS a major milestone for our development projects.
> I don't know what is faster overall ... you are probably right, that when
> the standard is accompanied by two or more implementations, it is more
> likely to be correct and implementable by others outside of the core
> development team.  But we also all work to external expectations (from our
> funding agencies), and I have heard many times now comments from people at
> data centers saying they are not going to code up an interface because it is
> still a WD.  Please keep in mind that many of the implementors of IVOA
> standards are not part of the VO development teams.

That's a fair point as stated.  However, my impression (not backed up
by evidence, and possibly incorrect - data welcomed) is that the first
implementations for the standards that we're talking about are in 
fact by VO/IVOA insiders.  Non-IVOA data centers in practice don't 
wait until the REC acceptance date and then start implementing; 
they wait until it looks like it's going to be a standard which
is actually being used, or going to get used, by other people 
and then start implementing.  This latter only happens after 
somebody else (most likely an IVOA insider) has provided an 
implementation of some kind.

> >> I would probably agree fully with you if, say, IVOA were a dues-based
> >> membership organization, with its own financial resources to build
> >> validators, or test those developed by others.  But I see a distinction,
> >> albeit a subtle one, between the projects' willingness to contribute to
> >> development of a standard and their ability to provide supporting software
> >> and validators on a timescale that does not jeopardize the promotion
> >> process.
> > 
> > Again - I believe that the timescale of the promotion process itself
> > is a red herring.  That given, I don't see the subtle difference here
> > (management is neither my enthusiasm nor my expertise, so I'm quite
> > prepared to believe there are issues over my head here) - could you
> > elaborate a bit?
> As above.  Agreement on these standards is a major milestone.  Read any of
> the NVO Quarterly Reports to NSF (all are on the NVO web page, in the
> document collection) and you can see how important these are in terms of
> deliverables.

To some extent, this is what I was goading you to say.  I do concede 
that there are political considerations here which will affect what 
decisions we take.  When I said above that nothing useful is achieved
by the standard publication per se, I should really have said nothing
*technically* useful has been achieved - I admit that there may be
some (maybe, a lot of) political advantage.  If we're going to determine 
the standards process on that basis however, I'd like to have
it out in the open amongst ourselves rather than to pretend that the 
StdDoc text is motivated purely by the considerations of technical 
excellence and technical pragmatism.  If we admit that, maybe there's 
another way forward: declare an intermediate document stage of 
"accepted in principle, no major changes expected, but revisions 
possible on the basis of implementation experience".  This stage 
could be sold as the one that counts to the funding agencies.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/