- Email: [email protected]
Problems of software standardisation
39
Commentary
Problems of Software Standardisation Brian L. M E E K
1. Approach
Director of Information Technology, Goldsmiths' College, London SE14 6NW, UK
While all standardisation efforts are likely to encounter problems, software standardisation faces particular problems because of the abstract and flexible nature of software. This has a number of consequences, including pressures to include options, and difficulty in finding a stable foundation on which to begin standardisation. In the case of software, stability may have to come from the establishment of standards, rather than the standards coming from the technology achieving stability. A later paper will discuss the possible future of software standardisation, in the light of the problems described here.
Keywords: Softwarestandardisation,
Brian L. Meek began his computing career in 1956 as a King's College London mathematics graduate and continued as a computer user while a lecturer in mathematics at King's, Leeds University and Queen Elizabeth College (QEC) London. He began full-time involvement in 1970 on becoming Director of the Computer Unit at QEC. When King's, QEC and Chelsea Colleges merged he became an Assistant Director of the combined Computing Centre, from which post he is currently on secondment to Goldsmiths' College in his present capacity. He has published books and numerous articles on computing topics with a particular emphasis on programming languages and standardisation. A member of the British Computer Society since 1961, he was elected a Fellow in 1983 and represents the Society on the main information technology committee at the British Standards Institution; in addition he has been a member of the BSI programming languages subcommittee since 1976 and was its chairman for four years, as well as being convertor of an ISO working group on guidelines for the preparation of programming language standards, whose Technical Report is expected to be published soon. He is particularly interested in quality issues, both for standards themselves and the products conforming to them, and is a strong advocate of greater user involvement in standards making, North-Holland Computer Standards & Interfaces 10 (1990) 39-43
T h o u g h this paper is concerned with problems of software standardisation, there are many problems that are common to all kinds of standardisation - political, economic, and human problems. These will be dealt with first.
l.]. Political Problems
Political problems c a n o c c u r especially internationally, where one country perceives that its interest is best served by adopting a particular form of standard from a selection of possible standards, e.g. because this is believed to give that country a technical lead over others. Other countries oppose because they have a similar perception. Such attitudes ignore the fact that agreeing a worldwide standard generally benefits everyone, but though the fears on which such attitudes are based may be imaginary, the problems are real enough. They arise because of the occupational hazard of politicians (and others) that they too often think in t e r m s only of short-term tactical advantage. T h e problems get worse when national pride and "loss of face" enter the argument as well. 1.2. Economic Problems
Economic problems tend to arise at the supplier level though they can arise at the c u s t o m e r level as well. They mainly relate to the cost of conversion to making or using products which conform to the standard, though in some areas, including IT, the cost of deciding on what the standard should be can become a factor. Again the problems can mostly be traced to short-term attitudes among those who control industry (whether privately or publicly owned) with s o m e times an element of "company prestige" c o r r e sponding to "national pride" in the case of political problems.
0920-5489/90/$03.50 © 1990 - Elsevier Science Publishers B.V. (North-Holland)
40
B.L. Meek / Software Standardisation
The problems caused by short-term attitudes have come up both in this subsection and the preceding one. How to deal with such attitudes is an issue discussed in another paper [1]. 1.3. Human Problems
Human problems arise when people involved in standardisation have a personal involvement in the issues. This can be observed in the attachment that some people have to particular programming languages, or a liking for a particular word processing package or a particular style of user interface. Whether a user thinks a system is userfriendly often depends as much on the user as on the system. This can make it difficult to achieve consensus. The examples cited have come from information technology (IT) but can be expected to occur generally, 1.4. Problems Particular to 1T
This paper therefore does not spend much further time on problems such as that, which are inherent in all standardisation, except where they are particularly acute in the case of software, IT standardisation generally (hardware, communications etc. as well as software) share particular problems, some of them of the general kind but especially acute - mainly because of the high economic and political importance of IT - and others because of the all-pervasive and highly complex and interconnected nature of the field. Though vigorously denied by some, there is a widespread feeling that existing standards-making machinery is inadequate to cope with standards of such complexity. As far as software is concerned such problems are even greater than for other aspects of IT, because of its adaptability and expandability, which is the next question for discussion,
2. Soft, not 1-1ard The special problems of software standardisation stem from the very fact that it is soft and not hard. Software standards have to deal with abstract rather than concrete entities (though some make matters worse for themselves by muddling up abstractions and realisations on actual hard-
ware). Possibilities are infinitely variable, limited only by the range of inventiveness of those concerned. So there are problems of: - endless variety, difficult to contain and pin down in standardised form; - abstract nature making incompatibilities less obvious than, say, a plug not fitting a socket; - flexibility making general agreement on what is "standard practice" very difficult.
3. Flexibility The flexibility of software encourages customised solutions and attitudes opposed to the idea of standardisation. The apparent freedom from limitations makes it harder for people to accept that some self-discipline is desirable. Arguments against standardisation are advanced such as that standards impose constraints when there is no need, that standards inhibit progress, that standards are extremely expensive to develop and implement all based on the idea that this limits the benefits of adaptability without compensating benefits in return. For example, arguments have been made that there is no need to standardise Fourth Generation Languages because it is so easy to write in them. Similar things were said about Fortran and Cobol in the 1960s. Some of the greatest poetry has been written by poets who voluntarily constrained themselves to a s t a n d a r d form: Shakespeare's sonnets are an example. As for inhibiting progress, good standards actually encourage progress because they reduce the need to think about those areas, and frees energy, effort, resources and inventiveness to concentrate on new things. The best standards are those that are so taken for granted that people are hardly aware of them. (The industry would not exist at all were it not for the firm basis of previous standards on which it depends, and which those who argue against standards take for granted). Of course, absence of standards can also be taken for granted. Many people routinely spend time, effort and resources on dealing with incompatibilities e.g. between word processing systems, that they take for granted though often there is no justification for them. As for the cost of standardisation, it is very expensive, but the cost of lack of standardisation is enormous. The difficulty in countering this
B.L. Meek / Software Standardisation argument is that the first cost is fairly easy to estimate whereas the second is not. It is hard enough anyway, but the nature of software makes it especially so.
4. Options When standardisation is started, a new problem appears, though still stemming from the flexibility of software. Where agreement is hard to reach, for any of the general reasons listed earlier, it is easy - dangerously easy - to resolve disputes by inclusion of options. These can be of two kinds supplier options or user options, and both create problems,
4.1. Supplier Options Here the supplier has a choice of paths to follow. Such options are usually included to satisfy vendor vested interests, and undermine the very concept of standards. Where the options are built into the same standard it can mean that two different products both conforming to the same standard are incompatible. Particular forms of the options concept are "levels" (i.e. subsetting or modules) and - even worse - options by omission, by things being left system defined, or system dependent (worse) or not mentioned at all (worst, because it is easy to overlook their absence). In extreme cases there can be more than one standard for the same area. Of course, compatibility between different options or different standards can be achieved by providing automatic converters, and standards can require their presence (regrettably they do not always do so). However, this adds to the size and complexity and hence the cost of products, and there is a hidden cost in using the converters whenever they are invoked. The cost of lack of standardisation is hard to estimate, and tends to be spread thinly over the user community. But it is paid for by the users over and over again. Similarly the costs of bad standards are paid by the users, over and over again - and it does not take m a n y options to make a standard a bad standard, An analogy from everyday life is the cost of currency conversion when moving from one standard unit of exchange to another on crossing a border. It is not simply the cost of servicing the
41
conversions that needs to be considered - it is the human time and effort spent in having to think about it at all. When national economies were mostly self-contained and foreign travel a rarity, this was not a major problem, but in modern conditions of trade and communications in the developed world it becomes very significant. It has been estimated that the cost to the European C o m m u n i t y alone, simply of internal currency conversions, exceeds the cost of the C o m m o n Agricultural Policy, by far the most expensive of the Community's programmes. The one cost is highly visible and has given rise to much dissension and concern; the other has long been taken for granted and is only now becoming visible as moves are proposed to do something about it. The analogy with information technology and software is clear enough, especially since currencies are now essentially abstractions rather than physically existing in lumps of metal. Included in the analogy are the existence of vested interests who make a living, sometimes a very lucrative one, out of lack of standardisation, and of course the element of national pride.
4.2. User Options On the face of it, user options are better. Any conforming product must offer the choice to the user. However, as with converters, providing the options increases the size, complexity and cost of products. Also, to balance the work improvement when users can adjust the options to their needs, there is cost to set against the benefit, when users need to collaborate. Anyone who has edited a multi-author document, even when the writers are all using the same word processor, will recognise the problems here. Converters may be provided, but however automatic they are, they still add to size, complexity and cost. However, just as suppliers often seem to have the attitude " a standard is O K provided it is mine", so users, when an attempt is made to reduce options, will say "reducing options is fine provided my preferred options are there". Userselected options are therefore probably unavoidable; the trick is to find the right balance between flexibility and uniformity - and then convince everyone that it is the right balance! There is need for a research programme into IT standardisation - which the relevant authorities
42
B.L. Meek / Software Standardisation
have partially though not yet adequately addressed, a point returned to below - and this is one area that needs it.
acter-based i n p u t / o u t p u t or literal values referred to in program source text.
6. Levels of Abstraction 5. Lack of F i n n Foundations
Another aspect of the flexibility of software is that trying to build standards on firm foundations of agreed commonahty is almost impossible - to build something that will last, it is necessary to have a base of something solid, not fluid. The term "software engineering" is in common use but objectively has to be seen more as something the industry is working towards, rather than having yet fully achieved. The word "engineering" implies standards, of various kinds - standards of professionalism, standards of quality, standard practices, the use of standard tools and components. Software engineering is not totally lacking in such standards but has to be recognised as still having some way to go before it can stand cornparison with older-established engineering disciplines. In most engineering disciplines the technology stabilises and then the standards get stabilised too. The abstract and infinitely variable nature of software suggests that it is likely to take a long time to stabilise without the standards developing along with the technology, This may be regarded as accusing the software engineering industry of being immature, but it surely cannot be expected to be anything else. It is too young. The concern expressed here is not that it is immature but that there is not enough indication that it wishes to become mature - and that applies both to suppliers and to users. A sign of maturity is taking standards seriously, and there is so far insufficient of that. Another sign of lack of maturity is inability to think clearly about issues and separate out different levels of abstraction. For example, those concerned with looking at data types from a l a n guage-independent point of view have found that people often find it difficult to distinguish clearly between an abstraction of such a language independent type (such as integer), an instantiation of such a type in a particular language, an implementation of that instantiation in an actual compiler or other language processor, and (most important) the representation of values of the type for purposes of data storage, data transmission, and char-
It is sufficient for the purpose of this discussion to pursue the argument only for the case of textual characters, without bringing in graphics. Character sets (part, but only part, of "internationalisation" of software)have been the subject of much discussion in the late 1980s, and the impression has been left of attempted dialogues between those who think of characters mostly in representation, coding, and display terms, and those that think of them at higher levels of abstraction - though not always the same one. The attempts do not seem yet to have been very successful, because perceptions are at different levels. If people are mixing up different levels then there may be some overlap - which makes matters worse because there is the impression of actually talking about the same thing, which is actually deceptive. This question of identifying and separating different levels of abstraction seems to me to be crucial to many of the problems of software standardisation. The OSI reference model built an edifice of seven layers, for intercommunication purposes, but the distinction which this paper is making is between different levels of abstraction all existing mostly at the application level. One problem to be faced is that existing software standards (such as for programming languages) tend to incorporate different levels of abstraction, sometimes without clearly distinguishing them. This is particularly true of character sets and data though it occurs with other data as well. The conclusion is that there is need for research to identify clearly different levels of abstraction in terms of what standards should cover - to do for software what the OSI model did for interconnection. In a way, I S O / I E C JTC1 T S G / 1 , the ISO study group on interfaces for application portability, and some of the working groups of some JTC1 committees could be regarded as looking at parts of this, but is not realistic to assume that an ISO committee is an adequate, let alone very effective, research mechanism, despite the excellent work that has undoubtedly been done. Much preferable would be a properly funded research project, though retaining the ISO committee as a useful
B.L Meek / Software Standardisation
forum for the exchange of ideas and as a means of monitoring the progress of the research,
7. Aims Turning finally to what the aims of software standardisation should be, as remarked earlier the best standards are the ones which can be so taken for granted that people do not have to think about them. People sometimes complain that all airports worldwide, at least the international ones, are much the same. That, surely, is all to the good: it saves time and relieves worry for millions of air travellers every year. (Incidentally, like all good "standards" there is ample scope for imaginative realisation, which is one reason why some airports are so much better than others.) Staying with the theme of travel, a traveller can take a camera round the world without even having to think about whether it will be possible to buy a film for it. Similarly, a audio cassette tape can be taken, in the sure knowledge that there will be no trouble in playing it. N o t all standards are that good - it is not possible to take a cassette tape recorder and be sure that it can be plugged in and used - unless of course it is a battery recorder, A traveller taking a floppy disk, however, containing something as simple as a text document, cannot be sure that there will be a machine that can physically accept the disk at all, or if it does that it can actually read it, and that if it does that the text will appear ungarbled, and that if it does the available word processing package will accept it, and that if it does I will not have to do a major re-edit - - using, of course, an unfamiliar set of commands, Millions of hours of people's time are wasted each year because of such problems. The aim should surely be to ensure that a time will come when the following might be possible. Dr Smith is sitting at a personal computer, working on a document or a spreadsheet or a graphical image, and the telephone rings. " D r o p everything, pack a
43
suitcase for a few days, you have to go to (somewhere - Tampere, Adelaide, Montevideo, Vladivostok or wherever), your flight is booked, there will be a car to collect you in half an hour." So Dr Smith saves the piece of work she was doing onto a floppy disk, and puts it in the suitcase along with the other things (including a camera, of course!). At the destination, Tampere or Adelaide or wherever, she deals with whatever it was the panic was about, and when she finally has some time for herself before she has to leave for home, she borrows a workstation - of completely unfamiliar make. She switches it on, puts in the floppy disk, calls up the file, and carries on the piece of work she had been doing. The borrowed system has recognised what she had been doing, and her preferred user interface and set of defaults, and it has provided them - without her having to think about it. This may sound Utopian, but there is nothing in what has been described that is not achievable now with current technology. The problem is not the technology, but persuading all concerned that it is a worthwhile goal, and that universal standards raise the level of the market for everyone, and releases large amounts of time and effort, on the part of users and suppliers alike, for more productive purposes than having to cope with incompatibilities.
Acknowledgement This paper is based on a presentation given to the SoftProd 89 seminar at Tampere, Finland in October 1989. The author is grateful to the Finnish Information Processing Association both for inviting him to make the presentation and for giving permission for a paper based on it to be submitted for publication. Reference [1] B.L. Meek, Changing people's attitudes: personal views, Computer StandardsandInterfaces, thisissue.
Commentary
Problems of Software Standardisation Brian L. M E E K
1. Approach
Director of Information Technology, Goldsmiths' College, London SE14 6NW, UK
While all standardisation efforts are likely to encounter problems, software standardisation faces particular problems because of the abstract and flexible nature of software. This has a number of consequences, including pressures to include options, and difficulty in finding a stable foundation on which to begin standardisation. In the case of software, stability may have to come from the establishment of standards, rather than the standards coming from the technology achieving stability. A later paper will discuss the possible future of software standardisation, in the light of the problems described here.
Keywords: Softwarestandardisation,
Brian L. Meek began his computing career in 1956 as a King's College London mathematics graduate and continued as a computer user while a lecturer in mathematics at King's, Leeds University and Queen Elizabeth College (QEC) London. He began full-time involvement in 1970 on becoming Director of the Computer Unit at QEC. When King's, QEC and Chelsea Colleges merged he became an Assistant Director of the combined Computing Centre, from which post he is currently on secondment to Goldsmiths' College in his present capacity. He has published books and numerous articles on computing topics with a particular emphasis on programming languages and standardisation. A member of the British Computer Society since 1961, he was elected a Fellow in 1983 and represents the Society on the main information technology committee at the British Standards Institution; in addition he has been a member of the BSI programming languages subcommittee since 1976 and was its chairman for four years, as well as being convertor of an ISO working group on guidelines for the preparation of programming language standards, whose Technical Report is expected to be published soon. He is particularly interested in quality issues, both for standards themselves and the products conforming to them, and is a strong advocate of greater user involvement in standards making, North-Holland Computer Standards & Interfaces 10 (1990) 39-43
T h o u g h this paper is concerned with problems of software standardisation, there are many problems that are common to all kinds of standardisation - political, economic, and human problems. These will be dealt with first.
l.]. Political Problems
Political problems c a n o c c u r especially internationally, where one country perceives that its interest is best served by adopting a particular form of standard from a selection of possible standards, e.g. because this is believed to give that country a technical lead over others. Other countries oppose because they have a similar perception. Such attitudes ignore the fact that agreeing a worldwide standard generally benefits everyone, but though the fears on which such attitudes are based may be imaginary, the problems are real enough. They arise because of the occupational hazard of politicians (and others) that they too often think in t e r m s only of short-term tactical advantage. T h e problems get worse when national pride and "loss of face" enter the argument as well. 1.2. Economic Problems
Economic problems tend to arise at the supplier level though they can arise at the c u s t o m e r level as well. They mainly relate to the cost of conversion to making or using products which conform to the standard, though in some areas, including IT, the cost of deciding on what the standard should be can become a factor. Again the problems can mostly be traced to short-term attitudes among those who control industry (whether privately or publicly owned) with s o m e times an element of "company prestige" c o r r e sponding to "national pride" in the case of political problems.
0920-5489/90/$03.50 © 1990 - Elsevier Science Publishers B.V. (North-Holland)
40
B.L. Meek / Software Standardisation
The problems caused by short-term attitudes have come up both in this subsection and the preceding one. How to deal with such attitudes is an issue discussed in another paper [1]. 1.3. Human Problems
Human problems arise when people involved in standardisation have a personal involvement in the issues. This can be observed in the attachment that some people have to particular programming languages, or a liking for a particular word processing package or a particular style of user interface. Whether a user thinks a system is userfriendly often depends as much on the user as on the system. This can make it difficult to achieve consensus. The examples cited have come from information technology (IT) but can be expected to occur generally, 1.4. Problems Particular to 1T
This paper therefore does not spend much further time on problems such as that, which are inherent in all standardisation, except where they are particularly acute in the case of software, IT standardisation generally (hardware, communications etc. as well as software) share particular problems, some of them of the general kind but especially acute - mainly because of the high economic and political importance of IT - and others because of the all-pervasive and highly complex and interconnected nature of the field. Though vigorously denied by some, there is a widespread feeling that existing standards-making machinery is inadequate to cope with standards of such complexity. As far as software is concerned such problems are even greater than for other aspects of IT, because of its adaptability and expandability, which is the next question for discussion,
2. Soft, not 1-1ard The special problems of software standardisation stem from the very fact that it is soft and not hard. Software standards have to deal with abstract rather than concrete entities (though some make matters worse for themselves by muddling up abstractions and realisations on actual hard-
ware). Possibilities are infinitely variable, limited only by the range of inventiveness of those concerned. So there are problems of: - endless variety, difficult to contain and pin down in standardised form; - abstract nature making incompatibilities less obvious than, say, a plug not fitting a socket; - flexibility making general agreement on what is "standard practice" very difficult.
3. Flexibility The flexibility of software encourages customised solutions and attitudes opposed to the idea of standardisation. The apparent freedom from limitations makes it harder for people to accept that some self-discipline is desirable. Arguments against standardisation are advanced such as that standards impose constraints when there is no need, that standards inhibit progress, that standards are extremely expensive to develop and implement all based on the idea that this limits the benefits of adaptability without compensating benefits in return. For example, arguments have been made that there is no need to standardise Fourth Generation Languages because it is so easy to write in them. Similar things were said about Fortran and Cobol in the 1960s. Some of the greatest poetry has been written by poets who voluntarily constrained themselves to a s t a n d a r d form: Shakespeare's sonnets are an example. As for inhibiting progress, good standards actually encourage progress because they reduce the need to think about those areas, and frees energy, effort, resources and inventiveness to concentrate on new things. The best standards are those that are so taken for granted that people are hardly aware of them. (The industry would not exist at all were it not for the firm basis of previous standards on which it depends, and which those who argue against standards take for granted). Of course, absence of standards can also be taken for granted. Many people routinely spend time, effort and resources on dealing with incompatibilities e.g. between word processing systems, that they take for granted though often there is no justification for them. As for the cost of standardisation, it is very expensive, but the cost of lack of standardisation is enormous. The difficulty in countering this
B.L. Meek / Software Standardisation argument is that the first cost is fairly easy to estimate whereas the second is not. It is hard enough anyway, but the nature of software makes it especially so.
4. Options When standardisation is started, a new problem appears, though still stemming from the flexibility of software. Where agreement is hard to reach, for any of the general reasons listed earlier, it is easy - dangerously easy - to resolve disputes by inclusion of options. These can be of two kinds supplier options or user options, and both create problems,
4.1. Supplier Options Here the supplier has a choice of paths to follow. Such options are usually included to satisfy vendor vested interests, and undermine the very concept of standards. Where the options are built into the same standard it can mean that two different products both conforming to the same standard are incompatible. Particular forms of the options concept are "levels" (i.e. subsetting or modules) and - even worse - options by omission, by things being left system defined, or system dependent (worse) or not mentioned at all (worst, because it is easy to overlook their absence). In extreme cases there can be more than one standard for the same area. Of course, compatibility between different options or different standards can be achieved by providing automatic converters, and standards can require their presence (regrettably they do not always do so). However, this adds to the size and complexity and hence the cost of products, and there is a hidden cost in using the converters whenever they are invoked. The cost of lack of standardisation is hard to estimate, and tends to be spread thinly over the user community. But it is paid for by the users over and over again. Similarly the costs of bad standards are paid by the users, over and over again - and it does not take m a n y options to make a standard a bad standard, An analogy from everyday life is the cost of currency conversion when moving from one standard unit of exchange to another on crossing a border. It is not simply the cost of servicing the
41
conversions that needs to be considered - it is the human time and effort spent in having to think about it at all. When national economies were mostly self-contained and foreign travel a rarity, this was not a major problem, but in modern conditions of trade and communications in the developed world it becomes very significant. It has been estimated that the cost to the European C o m m u n i t y alone, simply of internal currency conversions, exceeds the cost of the C o m m o n Agricultural Policy, by far the most expensive of the Community's programmes. The one cost is highly visible and has given rise to much dissension and concern; the other has long been taken for granted and is only now becoming visible as moves are proposed to do something about it. The analogy with information technology and software is clear enough, especially since currencies are now essentially abstractions rather than physically existing in lumps of metal. Included in the analogy are the existence of vested interests who make a living, sometimes a very lucrative one, out of lack of standardisation, and of course the element of national pride.
4.2. User Options On the face of it, user options are better. Any conforming product must offer the choice to the user. However, as with converters, providing the options increases the size, complexity and cost of products. Also, to balance the work improvement when users can adjust the options to their needs, there is cost to set against the benefit, when users need to collaborate. Anyone who has edited a multi-author document, even when the writers are all using the same word processor, will recognise the problems here. Converters may be provided, but however automatic they are, they still add to size, complexity and cost. However, just as suppliers often seem to have the attitude " a standard is O K provided it is mine", so users, when an attempt is made to reduce options, will say "reducing options is fine provided my preferred options are there". Userselected options are therefore probably unavoidable; the trick is to find the right balance between flexibility and uniformity - and then convince everyone that it is the right balance! There is need for a research programme into IT standardisation - which the relevant authorities
42
B.L. Meek / Software Standardisation
have partially though not yet adequately addressed, a point returned to below - and this is one area that needs it.
acter-based i n p u t / o u t p u t or literal values referred to in program source text.
6. Levels of Abstraction 5. Lack of F i n n Foundations
Another aspect of the flexibility of software is that trying to build standards on firm foundations of agreed commonahty is almost impossible - to build something that will last, it is necessary to have a base of something solid, not fluid. The term "software engineering" is in common use but objectively has to be seen more as something the industry is working towards, rather than having yet fully achieved. The word "engineering" implies standards, of various kinds - standards of professionalism, standards of quality, standard practices, the use of standard tools and components. Software engineering is not totally lacking in such standards but has to be recognised as still having some way to go before it can stand cornparison with older-established engineering disciplines. In most engineering disciplines the technology stabilises and then the standards get stabilised too. The abstract and infinitely variable nature of software suggests that it is likely to take a long time to stabilise without the standards developing along with the technology, This may be regarded as accusing the software engineering industry of being immature, but it surely cannot be expected to be anything else. It is too young. The concern expressed here is not that it is immature but that there is not enough indication that it wishes to become mature - and that applies both to suppliers and to users. A sign of maturity is taking standards seriously, and there is so far insufficient of that. Another sign of lack of maturity is inability to think clearly about issues and separate out different levels of abstraction. For example, those concerned with looking at data types from a l a n guage-independent point of view have found that people often find it difficult to distinguish clearly between an abstraction of such a language independent type (such as integer), an instantiation of such a type in a particular language, an implementation of that instantiation in an actual compiler or other language processor, and (most important) the representation of values of the type for purposes of data storage, data transmission, and char-
It is sufficient for the purpose of this discussion to pursue the argument only for the case of textual characters, without bringing in graphics. Character sets (part, but only part, of "internationalisation" of software)have been the subject of much discussion in the late 1980s, and the impression has been left of attempted dialogues between those who think of characters mostly in representation, coding, and display terms, and those that think of them at higher levels of abstraction - though not always the same one. The attempts do not seem yet to have been very successful, because perceptions are at different levels. If people are mixing up different levels then there may be some overlap - which makes matters worse because there is the impression of actually talking about the same thing, which is actually deceptive. This question of identifying and separating different levels of abstraction seems to me to be crucial to many of the problems of software standardisation. The OSI reference model built an edifice of seven layers, for intercommunication purposes, but the distinction which this paper is making is between different levels of abstraction all existing mostly at the application level. One problem to be faced is that existing software standards (such as for programming languages) tend to incorporate different levels of abstraction, sometimes without clearly distinguishing them. This is particularly true of character sets and data though it occurs with other data as well. The conclusion is that there is need for research to identify clearly different levels of abstraction in terms of what standards should cover - to do for software what the OSI model did for interconnection. In a way, I S O / I E C JTC1 T S G / 1 , the ISO study group on interfaces for application portability, and some of the working groups of some JTC1 committees could be regarded as looking at parts of this, but is not realistic to assume that an ISO committee is an adequate, let alone very effective, research mechanism, despite the excellent work that has undoubtedly been done. Much preferable would be a properly funded research project, though retaining the ISO committee as a useful
B.L Meek / Software Standardisation
forum for the exchange of ideas and as a means of monitoring the progress of the research,
7. Aims Turning finally to what the aims of software standardisation should be, as remarked earlier the best standards are the ones which can be so taken for granted that people do not have to think about them. People sometimes complain that all airports worldwide, at least the international ones, are much the same. That, surely, is all to the good: it saves time and relieves worry for millions of air travellers every year. (Incidentally, like all good "standards" there is ample scope for imaginative realisation, which is one reason why some airports are so much better than others.) Staying with the theme of travel, a traveller can take a camera round the world without even having to think about whether it will be possible to buy a film for it. Similarly, a audio cassette tape can be taken, in the sure knowledge that there will be no trouble in playing it. N o t all standards are that good - it is not possible to take a cassette tape recorder and be sure that it can be plugged in and used - unless of course it is a battery recorder, A traveller taking a floppy disk, however, containing something as simple as a text document, cannot be sure that there will be a machine that can physically accept the disk at all, or if it does that it can actually read it, and that if it does that the text will appear ungarbled, and that if it does the available word processing package will accept it, and that if it does I will not have to do a major re-edit - - using, of course, an unfamiliar set of commands, Millions of hours of people's time are wasted each year because of such problems. The aim should surely be to ensure that a time will come when the following might be possible. Dr Smith is sitting at a personal computer, working on a document or a spreadsheet or a graphical image, and the telephone rings. " D r o p everything, pack a
43
suitcase for a few days, you have to go to (somewhere - Tampere, Adelaide, Montevideo, Vladivostok or wherever), your flight is booked, there will be a car to collect you in half an hour." So Dr Smith saves the piece of work she was doing onto a floppy disk, and puts it in the suitcase along with the other things (including a camera, of course!). At the destination, Tampere or Adelaide or wherever, she deals with whatever it was the panic was about, and when she finally has some time for herself before she has to leave for home, she borrows a workstation - of completely unfamiliar make. She switches it on, puts in the floppy disk, calls up the file, and carries on the piece of work she had been doing. The borrowed system has recognised what she had been doing, and her preferred user interface and set of defaults, and it has provided them - without her having to think about it. This may sound Utopian, but there is nothing in what has been described that is not achievable now with current technology. The problem is not the technology, but persuading all concerned that it is a worthwhile goal, and that universal standards raise the level of the market for everyone, and releases large amounts of time and effort, on the part of users and suppliers alike, for more productive purposes than having to cope with incompatibilities.
Acknowledgement This paper is based on a presentation given to the SoftProd 89 seminar at Tampere, Finland in October 1989. The author is grateful to the Finnish Information Processing Association both for inviting him to make the presentation and for giving permission for a paper based on it to be submitted for publication. Reference [1] B.L. Meek, Changing people's attitudes: personal views, Computer StandardsandInterfaces, thisissue.