From: Pat Hall
Sent: Wednesday, May 22, 2002 5:28 PM
Subject: What are standards for? What standards need developing?
Dear WG20 members,
I have been watching the discussions on this list, aiming to get some feeling for the group and the differences in opinion that guide WG20 decisions. I have seen a lot of very strongly expressed views where the strength of expression seemed unrelated to the particular point being debated, and was left wondering whether there was not some form of inter-cultural communication problem here.
On 25 Apr Ken Whistler seemed to put his finger on it, in a response to Keld Simonsen:
<< We have big disagreements because of the *standards* architecture you advocate -- the list of standards or TR's that should be developed, their content, their articulation with other standards, the concept and content of the international registry that you own, and the scope of work that you think appropriate for WG20 as a platform for pursuing this standards architecture.
This is a clash of standards culture, between people and organizations that have different ideas about how things should proceed and who should do what kind of work. Internationalization is not the only area in which disagreements of this sort come up -- it happens all the time in lots of forums dealing with standardization of all kinds of things. However, internationalization is on the hotseat in our particular case precisely because it is a difficult and diffuse topic where lots of people would *like* there to be clear standards, but because it deals with languages and cultural conventions, it is often very difficult to see how clear standards could even be articulated. Look at all the difficulty regarding language id's and language tagging, for instance -- which is not an area WG20 has even tried to dip into. >>
But in the debate that followed I really could not get any understanding of the different standards cultures that Ken had in mind. There was a fierce exchange about whether the US and larger companies were imposing their interests, and whether national delegations were being unduly influenced in their voting. But what were the principles at stake underlying the exchange?
I have been reading TR 11017:1997 which I am told was intended to frame the work of WG20, and also reading TR 10176:2001 which supposedly incorporated advice concerning internationalisation to guide the programming language committees of SC22. TR11017 in particular was disappointing for the errors around linguistics and writing systems, though these are not important here the key thing for me was Section 7 "Model and Services required for Internationalisation" summarised in Figure 11. I was looking for such a summary of the interfaces across which interoperation would take place and which could be the subject of standardisation. I was also looking for groupings of these that might guide us as to which SC within ISO particular standards might properly be pursued. I regret to say that the model presented was not much help, but maybe it could be made to be so.
In thinking about such an architectural model, we must also bear in mind that this assumes some related industrial model. The pieces of technology on each side of the interface can be created independently. There has been a continual debate between, maybe even battle between, the European Union and the major IT multi-nationals, to get internal interfaces properly specified so that companies in Europe could supply software to work to these interfaces. Many multinationals have been really good about doing this. But is it enough that these interfaces should be made public, should they not also be stabilised in some way, perhaps through standardisation? The discussion around ICU gave us an example of this.
Glen Seeds suggested: << The most effective standards are those that confirm industry practice, rather than inventing it.>> Maybe he is right, maybe it is this plus a little bit more. Do standards confer a wider benefit that is more than just endorsement?
Thus the voice of industrial concerns is very important, though the will of large organisations must not dominate. But the history of standardisation reassures us that this does not happen think of IBM and EBCDIC, Microsoft versus Sun with Java. However we must take note of the unheard voices of small companies, though these might find voice through regional and national governments. But there are also the unheard voices of small communities referred to in the recent discussion; my own concern here is mostly with respect to the creation of appropriate writing systems, but that is the business of SC2.
Where does this discussion take us? Well, firstly, maybe we do need to discuss the principles underpinning our standardisation activities. Surely this must have been debated many times, and even have been well documented, but that does not mean that we should not ourselves discuss it and reach a position of shared understanding, maybe even agreement. How about it, in Tromsų?
Having agreed what standardisation is about, could we then proceed to pick up the many issues raised in the email discussion?
Is there a need for a standard for an internationalisation APIs of the collection of services associated with locales? This is the domain of 14652 currently subject to vote and the now rejected 15435 - APIs for Internationalization. In the recent correspondence the ICU was suggested as meeting this need, and Keld even posed the question whether this should be standardised, to which Glen Seed give sensible caution that it would be premature. Of course it would not be the ICU that is standardised, but the set of interfaces. To me this seems highly desirable, on the basis that this would enable other software suppliers to produce conformant software for locales that ICU has no interest in serving.
However I do have some concerns with ICU and its intimate association with Java, C and C++. These are the same concerns that made me conflate 14652 and 15435, much to Keld's surprise. You see, I would expect to see interfaces defined at two levels of abstraction, a high level of abstraction independent of any programming language that spells out the essence of the interface, and the binding of the abstract services or facilities to particular programming languages. This is much the same as the separation of a character encoding from its rendition in a font. The standardisation of graphics interfaces was done at these two levels of function and language binding, and I believe that it is also done for SQL and CORBA's IDL but please correct me if I wrong there. Maybe this approach has been proven to be ineffective, TR 10176 has remarkably little to say about this. If this approach is appropriate, maybe it needs to be spelt out somewhere.
Should 14651 on string ordering be moved to SC2? String ordering is clearly contingent upon the community of use, the culture or locale, and could even vary within a community. Mostly we come across it in dictionaries and directories, it is part of the presentation of information to people, and does on that basis seem to be a matter for user interfaces and SC35. One small aspect of string ordering arises when there are alternative orthographies and we are concerned with string equivalence string equivalence is clearly a concern for SC2, and as such ordering seems to be associated with SC2's work, though my own reaction there is to suggest that SC2 should solve the problem of alternative orthographies, not to remove them, but to characterise them independently of ordering. I personally think that the approach being taken in W3C Character Model to pursue a single canonical form could be mistaken. So there could be strong reasons for NOT moving 14651 to SC2. Ordering can also be used within the internal mechanics of computing systems, but I would view that as an accidental rather than essential characteristic of orderings. So where is the 'proper' home for 14651? We need some further principles to guide us in this.
I look forward with enthusiasm to our discussion in Tromsų.
Professor Pat Hall, Computing Department, Open University, Milton Keynes MK7 6AA
tel: 01908 652694 (work at OU), 01825 71 2661 (home and work) 07813 603376 (mobile always on)