IVOA Document Standards RFC V1.2

[Robert Hanisch]

> 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 don't have very complete information on this -- mostly anecdotal evidence.
Most developers like to start with something already existing; others eschew
what's been done and start from scratch.

>>>> 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.

It was understood from the beginning of IVOA that standards would evolve and
that first versions would likely need to change.  I found something I wrote
back in March 2004, concerning the registry standards, that I think remains
relevant today:

We need to reach agreements quickly, build to them, and iterate to improve
them.  We need to be willing to build and revise, or even in some cases
throw away and start again.  We have set up a standards process that
recognizes change, and is intended to be responsive to change. I do not
believe we can afford to set 2-3 year schedules for reaching consensus. If
it takes this long, the community upon which we will utimately depend for
support will see us as purveyors of snake-oil, and will blow us off.

- - - - -

All this said, I think we will update the document to make the
implementations and validator strongly/highly recommended, with some reason
needing to be provided if these have not been done in order to move the
standard ahead.  I still think we do not want to go with mandatory, for the
reasons explained in the past several messages.

Off now for our independence holiday (which started today, actually).

cheers,
Bob