97-226r1 Date: August 15, 1997 To: J3 From: Keith H. Bierman Subject: Standardization (of Interval Arithmetic) I would like to clarify our (Sun) position (as I understand it) on this subject; since it is both important for this topic, and for some general procedural implications. In addition, it seems that I haven't managed to explain it well enough verbally ;> The best outcome would be a quorum of vendors (e.g. sun, dec, ibm, hp) to agree that this is something that they will seriously implement (along with the already existing majority votes, especially at wg5 that mandated this work). In this case, settling for what we consider a potentially inferior specification is in the best interests of the community (vendors, users, standardization in general), would be appropriate and is part of the natural give and take of a standardization process. We'll return to this in a more general form below. Since it has become clear that no other vendor involved with the Standards process (nor others we could find) have any interest in interval arithmetic (other than self defense), the next best outcome is to stop working on it as a Standard. As we see it, one vendor does not need anti-trust protections to meet with its customers to design a facility. Furthermore, the process is almost certainly going to result in a Standard that is different from the only planned implementations. This is terrible for the standards process, is unhelpful to consumers and is a bit of an annoyance to the only interested vendor. I'll elaborate on what we feel the harm to Standardization in general, and these SDO's in particular are. I think it is feasible to have "peace with honor" if we continue to do some of the work of interval 2, and of topics such as ":=" (any spelling), I think we could somewhat honestly assert that the development body is acting on the original charge; but not completely and articulate why it is inappropriate to do the whole thing at this time. But assuming that we don't just stop work, and fight with wg5, the next best outcome is to make this work along the lines of paper 97-199, as part 4. But *not* accept the deadline set by wg5 and to allow time for the experimental evidence to come in, and in the end, find maximum harmony with the implementation(s) in existence at the point of our publication. There may well be other fine ways to implement this facility, but we don't do customers a favor by attempting to force the second through N vendors to be incompatible with whatever codes they do have. If the cynics are correct, there won't be any customer demand, and the project could (and should) be withdrawn when and if that is obvious to the committee(s). Or if not totally withdrawn, more in keeping with customary ISO practice, the result could be a TR (but not one destined to end up in the Standard). The next best choice, is to accept a deadline, but require it to be on the order of 3 years after f2k. This will both allow the results from experimental implementations and for f2k to stabilize. If both the experimental evidence and the improvements to the base language permit, perhaps some other approach (other than outlined in 199) would be appropriate. The worst choice, is to proceed to craft a specification which matches no implementation plans. Which leads us to the general topics. Over the last couple of years, I (khb) have spent an increased fraction of my time on worrying about Standards (suddenly other than Fortran, I've worried about this one for years ;>, C, C++, IEEE, X/Open, W3C misc others) as part of my "day job" at Sun. In addition, when I assumed the post of IR, I became more interested with ANSI/ISO matters. SDO's are often accused of a variety of sins: (1) too slow, (2) too innovative, (3) ignoring existing practice, (4) simply irrelevant (that is focused on standards for which there is no significant market need, (5) too many overlapping Standards. SDO credibility generally comes from doing successful work. While there are some Standards which are government mandates, even governments are often choosing to pick some de facto standard rather than the fruits of a formal SDO. The utility of a Standard is: To consumers: that it maximizes a consumers ability to switch vendors To suppliers: that it maximizes the ability to lure customers from other suppliers For the market as a whole: minimize costs In order to achieve these goals, it is necessary for there to be implementations. A Standard which exists only on the shelf does no good. Worse, it often does great long term harm to the SDO in question and to the quest of Standardization in general. Where the de jure standard is in disagreement with common practice, the result in diminished respect for the SDO, nearly immediately. Over the longer haul, it increases general perception that de jure standards are a waste of time and effort. That this is becoming a common perception may be inferred from new groups choosing to create their own ad hoc groups, consumer organizations not participating in standards processes, and perhaps from sales of standards documents (although the absurd pricing practices of many SDO's might be a better explanation for this particular metric). Where the de jure standard is simply ignored by consumers and suppliers alike, the harm is similar but not quite severe. However, there are many standards documents which seem to fall into this boat; and the cumulative result is very similar to the case of being out of touch with existing practice above. In order for a de jure Standard to be successful in the marketplace, it needs to address an area in which there is real commercial interest. It needs to actually be implemented on commercially important platforms. It needs to provide useful interoperability (unlike, for example, early SCSI specifications (circa mid 80's, 10% mandatory 90% optional, and any real device required one or more of the optional features; the situation has greatly improved since). Thus, it would behoove us to adopt a policy of not advancing projects which lack a quorum of supplier sponsors. While it might be best for ISO and ANSI to have this as a general policy; it is possible for us to be ahead of them. It is, for example, my understanding that the C committee has this as an unofficial policy.