From: Pat Hall
[p.a.v.hall@open.ac.uk]
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ų.
best wishes
Pat
------------------------------------------------------------------
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)
------------------------------------------------------------------