domo@tsa.co.uk (Dominic Dunlop) (02/16/91)
[Note that I'm making an attempt to divert this discussion into comp.std.internat] In article <ENAG.91Feb13234959@holmenkollen.ifi.uio.no> enag@ifi.uio.no (Erik Naggum) writes: > This concerns the ANSI C standard. The localeconv function has some > examples on page 111. I'm concerned with the specific entry on line 4 > of that page. It says something about Norway. I live in Norway. > > According to this example, Norwegians write "kr1234,56" when they mean > 1,234.56 units of local currency. According to this example, they > also write "kr1234,56-" when they mean -1,234.56 units of local > currency. > > I wonder how this managed to get into a standard in the year 1989. > After spending a few days asking friends, and them their fathers, I my > friends in the Norwegian Standards Association, the uniform reply is > "that went out of recommended use more than 20 years ago". In 1968 NS > 4133 (Norwegian Standard for Letters and other Documents, Writing and > Layout), the international currency code "NOK" is recommended... > international trade and communication, and is preferred for domestic > [and so on] > > I'm not impressed. One is led to believe that whatever else they say > on localization is also grossly out of date, and subsequently that the > whole locale stuff is bugridden at its core, never really tested. Well, yes. It is fair to say that internationalization issues were introduced to both the X3J11 and the POSIX working groups rather late in the day, with the result that ANSI X3-159 (C) and ANSI/IEEE 1003.1 (POSIX operating system interface) are rather light on internationalization-related content. This lightness is likely to be redressed in two forthcoming standards, the X3J16 C++ work, and the POSIX 1003.2 standard (shell and utilities): the internationalization lobby was able to get at these projects sufficiently early in their development to ensure that internationalization issues are considered at every turn. Well, most turns. Well, a good proportion of turns. It is also the case that the 1990 version of 1003.1 (which is the same thing as ISO 9945-1:1990) says a bit more about internationalization than the 1988 edition, and that the next edition of the C standard will also pay more attention to the issue, thanks to much work by Japan and Nordic countries, among others. (Sadly, ISO 9899:1990, the first edition of the international standard for C, has the same technical content as ANSI X3-159.) As for testing, where do you get things tested? In the marketplace, that's where. Unfortunately, there was very little prior art for X3J11 and POSIX workers to standardize, and what prior art there was had known shortcomings -- for example in the handling (or lack of handling) of wide characters. As a result, much of what the standardizers did was to try to make sure that practical fixes to known problems were not precluded in the future, rather than trying to come up with fixes at once. I believe POSIX did fairly well in this respect. I'm not so sure about C. A word of praise here for X/Open, which has thrown a lot of resource at the issue. But X/Open has to learn that standards working groups do not respond well to being told that a proposal must be accepted unchanged or not at all. > My direct questions are: > > Where did X3J11 get the input for these examples? > The point is that X3J11 set out to create an American National Standard. Should they be expected to know about Norway? Probably not. It's just rather a shame that they claimed to, because it creates a very bad impression with those who know better. It happens that the working group rules would have allowed participation by Norweigian companies, but what Norweigian company would want to spend money on the creation of an American standard? Try selling that idea to your management. In general, I wish more people around the world in general, and in America in particular, knew about such things as ISO 4217, Codes for the representation of currencies and funds. But they don't. People may, if you're lucky, know about their local conventions (don't rely on it though -- how many Norweigians know of the existence of NS 4133, I wonder?) This means that the right place for the definition of such things is in their target market (or ``locale'' as standards people have it). The 1990 edition of the POSIX.1 standard has annexes addressing this issue -- including a Danish example created by the Danish standards body. The internationalization rapporteur group of the ISO POSIX working group is trying to make sure that POSIX internationalization facilities do not preclude the definition of any locale that anybody, anywhere might reasonably require. The more people who get in touch with us and tell us what we're doing wrong, the happier we'll be. (Yes, I'm the UK rapporteur, but take this posting as individual comment.) > Are they didactic only, or are they intended to show real use > of the localization features? Obviously, didactic only -- intended as an example, since the text says ``may well be used'', rather than ``shall be used''. A dangerous example, though: implementors are inclined to take anthing that appears in a standard as gospel. Let me know as soon as someone tries to sell you a compiler with this example cast into its libraries... > > I would appreciate pointers to how this can be updated, as well. > Personally, I would not bother trying to fix the ANSI standard. Get in touch with your national standards body, obtain pointers to those associated with ISO/IEC JTC1/SC22/WG14 (C language), and take it up with them so as to make sure that the problem, if it exists in the current edition (I'm told it's out) of ISO 9899, is fixed in the next, or in an corrigendum or addendum. -- Dominic Dunlop
gwyn@smoke.brl.mil (Doug Gwyn) (02/19/91)
In article <1991Feb16.140510.22226@tsa.co.uk> domo@ukc.ac.uk (Dominic Dunlop) writes: >Well, yes. It is fair to say that internationalization issues were >introduced to both the X3J11 and the POSIX working groups rather late in >the day, with the result that ANSI X3-159 (C) and ANSI/IEEE 1003.1 >(POSIX operating system interface) are rather light on >internationalization-related content. This lightness is likely to be >redressed in two forthcoming standards, the X3J16 C++ work, and the >POSIX 1003.2 standard (shell and utilities): the internationalization >lobby was able to get at these projects sufficiently early in their >development to ensure that internationalization issues are considered at >every turn. Well, most turns. Well, a good proportion of turns. It is >also the case that the 1990 version of 1003.1 (which is the same thing >as ISO 9945-1:1990) says a bit more about internationalization than the >1988 edition, and that the next edition of the C standard will also pay >more attention to the issue, thanks to much work by Japan and Nordic >countries, among others. (Sadly, ISO 9899:1990, the first edition of the >international standard for C, has the same technical content as ANSI >X3-159.) I take strong exception to what Dominic has posted on this issue. In fact, approval of the final C standard for ratification was delayed for quite a long time due to the additional work by X3J11 necessary to accommodate legitimate concerns for "internationalization" issues. Coordination with various internationalization working groups was part of this process. So far as I am aware, the C standard was the first major programming language standard to specifically address these issues. It is not "sad", but rather encouraging, that ISO 9899 adopted the internationalization mechanisms (wide character and localization) that had been jointly worked out for ANS X3.159. It was recognized that these mechanisms form the basis for extensions to better address specific international localization concerns, and that it was neither necessary nor desirable for X3.159 to attempt to further address these. It is appropriate for WG14, however, and indeed work is in progress to prepare normative addenda to ISO 9899 that may further address these issues. Note that the input from "Japan and Nordic countries" started with participation in the preparation of the joint ANSI/ISO C standard, contrary to the impression that one might get from Dominic's posting that this input was missing during preparation of ANS X3.159-1989 and IS 9899:1990. I know that as an X3J11 member I personally spent a SIGNIFICANT amount of my time working on these issues. Any implication that they were slighted therefore really annoys me. >but what Norweigian company would want to spend money on the creation >of an American standard? X3.159 is certainly more than "an American standard", as is demonstrated by the adoption of its technical content unchanged as the international standard. It was generally considered by the X3J11 membership that we were working toward a SINGLE technical specification for C for EVERYONE. There was active participation in X3J11 by many individuals from non- American institutions, and during the public reviews of drafts of the proposed standard we received considerable commentary from many nations. P.S. I am not speaking on behalf of X3J11 or ANSI here, although I tend to think they would agree with me on this.
thorinn@diku.dk (Lars Henrik Mathiesen) (02/21/91)
domo@tsa.co.uk (Dominic Dunlop) writes: >the current edition (I'm told it's out) of ISO 9899 It's out; reference number "ISO/IEC 9899 : 1990 (E)", dated 1990-12-15. Typographically and contents-wise almost identical to the ANSI one --- but they ADDED 3 TO ALL THE CHAPTER NUMBERS (he screamed). It seems that ISO/IEC standards needs to have separate ``clauses'' on Scope, Normative references, Definitions and conventions, and Compliance; so the first four clause numbers cover four pages between them, and the next three (Environment, Language, and Library) are 172 pages. It seems a little silly. But I suppose the ISO/IEC style would rather have made the next level of the standard into chapters, giving a total of 28; less incongruous, maybe, but even more confusing when compared to the ANSI edition. -- Lars Mathiesen, DIKU, U of Copenhagen, Denmark [uunet!]mcsun!diku!thorinn Institute of Datalogy -- we're scientists, not engineers. thorinn@diku.dk