[om] a developer's perspective on CDs
Andrew Solomon
andrew at illywhacker.net
Sat Oct 28 10:36:30 CEST 2000
Dear All,
I was just visiting www.openmath.org and couldn't find any CDs no matter which
links I tried (I was looking for the CDs pertaining to polynomials).
Now I imagine that it's just an html programming error, but that isn't the point.
The point is, it reveals that OpenMath developers are not using www.openmath.org
as a forum to propose, discuss and disseminate their ideas for CDs. I strongly believe
that this is where we should all be floating CDs as RFCs and conducting dicussion about them.
This should be a place with visible OpenMath activity. At the moment it looks like we're all
dead.
Consider http://www.openmath.org/standard/cdacc.html
To me, the text on this page represents the view that getting the society
to accept a CD is the same type of activity as getting a journal's editors
to endorse a mathematical paper as correct. This is not surprising since we
are all mathematicians, however I strongly believe it is wrong. We are really
trying to obtain an *agreement* from a community that a certain CD is useful.
This is different to determining the correctness of a proof.
The standard and refereeing process promote a very rigid view of CD evolution
which makes people afraid to release something which might possibly contain an infelicity.
The standard reveals such an obsession with CD backward compatibility that it almost
defines the direction we are moving toward having a standard set of CDs.
Please don't take this as a criticism of the work that's been done on CDs. In
fact, the CDs I worked with within the ESPRIT consortium were really good,
but I doubt too many people outside the consortium have seen them.
We just need to be a bit more relaxed about
endorsing CDs *to some extent* and making them public.
It is not a solution to write private CDs and exchange them with your friends.
The whole point of using OpenMath is that you will be able to make unexpected
connections with other software/people/whatever down the track, so CDs should be
made as public as possible.
Moreover, a six week refereeing process doesn't inspire faith in the outcome.
Make CDs public quickly, then people can go ahead and WRITE SOME CODE,
being *reasonably* confident that they are heading in a similar direction to
at least *someone* else. We need to loosen up and let the CDs evolve under use. I don't
believe that referees can decide whether a CD is right or wrong in six weeks.
We need to *use* them and *discover* whether they're right or wrong.
In summary, the frustrating pace at which we're moving towards
having a known and well understood set of CDs to work from, is a
fundamental problem with the notions we've started with. The words "official", "public",
"endorsed" and "refereed" are really holding us back. IMHO the only way to move
forward is to "release early, release often" the CDs, not as official, but as RFCs.
Therefore, finally, some concrete proposals which don't require any changes
to the standard, or any "official" society position:
* A proceedure for submitting CDs to become visible on www.openmath.org,
somewhere close to the front page.
* An archived dicussion list - perhaps om at openmath.org - where CDs can be
discussed.
In conclusion, I'll quote from http://www.jargon.org
=======================================================================================
RFC /R-F-C/ n. [Request For Comment] One of a long-established series of numbered Internet informational documents and standards
widely followed by commercial software and freeware in the Internet and Unix communities. Perhaps the single most influential one has been
RFC-822 (the Internet mail-format standard). The RFCs are unusual in that they are floated by technical experts acting on their own initiative
and reviewed by the Internet at large, rather than formally promulgated through an institution such as ANSI. For this reason, they remain known
as RFCs even once adopted as standards.
The RFC tradition of pragmatic, experience-driven, after-the-fact standard writing done by individuals or small working groups has important
advantages over the more formal, committee-driven process typical of ANSI or ISO. Emblematic of some of these advantages is the existence
of a flourishing tradition of `joke' RFCs; usually at least one a year is published, usually on April 1st. Well-known joke RFCs have included 527
("ARPAWOCKY", R. Merryman, UCSD; 22 June 1973), 748 ("Telnet Randomly-Lose Option", Mark R. Crispin; 1 April 1978), and 1149 ("A
Standard for the Transmission of IP Datagrams on Avian Carriers", D. Waitzman, BBN STC; 1 April 1990). The first was a Lewis Carroll
pastiche; the second a parody of the TCP-IP documentation style, and the third a deadpan skewering of standards-document legalese,
describing protocols for transmitting Internet data packets by carrier pigeon.
The RFCs are most remarkable for how well they work -- they manage to have neither the ambiguities that are usually rife in informal
specifications, nor the committee-perpetrated misfeatures that often haunt formal standards, and they define a network that has grown to truly
worldwide proportions.
====================================================================================
Best wishes,
Andrew
--
om at openmath.org - general discussion on OpenMath
Post public announcements to om-announce at openmath.org
Automatic list maintenance software at majordomo at openmath.org
Mail om-owner at openmath.org for assistance with any problems
More information about the Om
mailing list