From keld@dkuug.dk Thu Apr 9 00:43:43 1992 Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8) id AA25072; Thu, 9 Apr 92 00:43:43 +0200 Date: Thu, 9 Apr 92 00:43:43 +0200 From: Keld J|rn Simonsen Message-Id: <9204082243.AA25072@dkuug.dk> To: sc22wg15@dkuug.dk, sc22wg20@dkuug.dk Subject: X'Open locale registry proposal X-Charset: ASCII X-Char-Esc: 29 Forwarded for comment /Keld Subject: (XoJIG 517) Locale Registry proposal for comment Date: Thu, 2 Apr 92 12:31:25 BST From: Dean Adams To: Joint Internationalisation Group Cc: From: Dean Adams Subject: Locale Registry proposal for comment Date: 2 Apr 1992 Hi all, Here is my poor effort at producing a proposal for a Locale Registry, which is the job that I somehow got stuck with. Please excuse the delay, but I have been trying to solicit comments from my colleagues within X/Open before going public. I am sure that there are many mistakes which need to be corrected, although I have tried where possible to base the proposal on the suggestions made by Keld at our Taipei meeting. The document actually was created on a wordprocessor, and so will have lost some of the formatting in translation to a simple text format. I hope that it is still able to be understood. The document also refers to Figure 1. This is contained in the wordprocessed version, and is just the diagram that we have drawn on the board at our two previous meetings, and have agreed-to. The diagram is effectively expained in a step-by-step fashion in the section entitled "Establishing a Locale Registry". Please could I have your comments as soon as possible, so that I can fix the document in plenty of time before the next meeting. Thanks Dean -------------------------------------------------------------------- Proposal for a Locale Registry Version 1.0 18 March 1992 Dean Adams Rationale C and POSIX define a "locale" where a variety of culture dependent data is defined, including language-dependent specifications for date and time, collating sequences, and numeric and monetary conventions. Many standard utilities in POSIX use these specifications to provide localized versions of the utility. There is currently no way generally to portably specify which locale a user wants to use with these standard utilities. Only one, non-internationalized, locale is standard: the C/POSIX locale. A registry which could uniquely name all locales, and also conveniently distribute such information to users would be desirable. This is especially the case when one considers distributed applications, or applications which otherwise make locale-sensitive demands on the resources of another system. A locale registry, which both defines unique names and the contents of locales is highly desirable in order that distributed applications can be supported, to the extent that behaviour on different systems with respect to locale-sensitive operations, can be guaranteed to be the same. Further, in a distributed software (such as that using RPC), it is imperative that the semantics of given locale on one system are identical to the same locale on a different system. Goals 1.To guarantee the same behaviour (of APIs and utilities) across different systems, with respect to locale sensitive operations. 2.To resolve the name-space collisions that can currently occur with respect to the naming of locales by different suppliers. 3.To provide an initial set of locale definitions that will support the above two goals. 4.To promote the migration of this registry and its administration, into an appropriate authority, like ISO, and to encourage the careful growth of the registry through consensus. Non-Goals 1. To force suppliers to support any particular locale. 2. To register all locales from all suppliers, user- organisations, etc.. Establishing a Locale Registry The aim is to try to settle on one locale per language/territory for inclusion in the registry. Since there is only one standard locale at the moment; the C/POSIX locale, various suppliers and other organisations have their own versions of locales for particular languages/territories. This situation poses a problem of selection through consensus for X/Open. In common with other aspects of X/Open's technical work, the first edition of the the locale registry will have X/Open Snapshot status. It is expected that the registry will then proceed through Preliminary Specification status to eventual CAE Specification which can be used to support verification and branding of implementations. For a full definition of these terms, please refer to the glossary in Appendix A. 1.Initially, X/Open will establish a period in which submissions will be solicited for the Snapshot locale registry from important industry organisations, national standards bodies, and ISO. 2.There will follow a period in which an attempt is made to define the initial Snapshot locale registry from the received submissions. X/Open will apply the following algorithm in making decisions on the adoption of individual locales: 3.Where a clear preference for a locale definition is received from that language/territory's national standards body, it will become the automatic choice without further debate. 4.In the absence of such an indication, the opinion of ISO will be solicited. Where ISO express a clear preference for a particular locale definition, that one will be adopted without further debate. 5.In the absence of clear indications from either the relevant national standards body or from ISO, X/Open voting members will go to ballot on the candidate submissions. This may result in the outright selection of one of the submitted locales, or the adoption of a single locale definition resulting from change requests having been applied to one or more of the candidates. 6.After the specified period of submission and selection has elapsed, the X/Open Snapshot Locale Registry will be published. This will be publicly and internationally available to anyone as is the case with all other X/Open documents. 7.The Snapshot will be circulated to national standards bodies and to ISO for further opportunities to review, comment, suggest changes and to suggest new locales for languages/territories not yet covered. 8.Following the same process employed earlier for the Snapshot, X/Open will progress the registry through Preliminary Specification status to CAE Specification status, and will at that time, provide verification suites to support the registry. Figure 1., depicts the process of establishing a locale registry. Acceptance Criteria For locale submissions to be acceptable to X/Open as candidates for the locale registry, they must satisfy the following criteria: 1.The locales shall be submitted in source form. 2.The format of the locale sources shall be conformant to the latest version of ISO/IEC 9945-2 3.The locale shall define all standard categories - for example by copying categories of a standard locale. 4.The sources shall be encoded in the invariant portion of ISO/IEC 646:1991 International Reference Version coded character set. Comments should be primarily in the English language, so that they can be widely understood. 5.The locales shall be sent to the following collection point: X/Open Locale Registry X/Open Company Limited Apex Plaza Forbury Road Reading RG1 1AX Berkshire England Tel: +44 (0)734 508311 Email: Xolocale@xopen.co.uk 6.The sources must be delivered electronically, either via electronic mail to the above mentioned email address, or on a DOS diskette to the above postal address. 7.A written application releasing copyrights of the submitted sources underwritten by authorised personnel on behalf of the contributing organisation must be sent to the above mentioned address. Any organisation is eligible to submit. 8.The written application must also contain the following information 1.Organisation name 2.Organisation Postal Address 3.Name of responsible contact person 4.Email address of responsible contact person 5.Telephone and FAX number of responsible contact person, in international format 6.Natural language, as two-letter form of ISO 639:1988 "Codes for the representation of names of languages (Bilingual Edition)" 7.Territory, as two-letter form of ISO 3166:1988 "Codes for the representation of names of countries" 9.Locale sources must be specified in a coded character set independent way, using wherever possible the symbolic names for characters specified in the latest version of ISO/IEC 9945-2 Annex F. 10. For each character not specified in Annex F of ISO/IEC 9945-2, the symbolic names for characters specified in ISO 10646 shall be used. 11. There may be a fee associated with each locale submission, to cover administrative costs. Selection Criteria The selection of locales to be included in the initial X/Open Snapshot locale registry will be determined by the process outlined earlier . In line with X/Open's standards policy however, (Appendix B), when standard locales are eventually created by the relevant national standards bodies, X/Open will defer to those standards where there are differences. Eventually therefore, there should be no difference between the locale definitions used by X/Open and standardised locales where they are defined. Passing Control to Standards Bodies It is hoped that the reponsibility for managing the locale registry will eventually be taken-on by ISO. In that event X/Open would still be willing to act as a distributor of the locale registry via media such as CD-ROM. Verification The approach to be taken with respect to verification of products claiming to support a particular locale will be that the product will be tested independently for each combination of locale and codeset that it claims to support. Thus it is expected that a brand will be available which explicitly states which locales are supported with which codesets. Appendix A. X/Open is an independent, worldwide, open systems organisation supported by most of the world's largest information systems suppliers, user organisations and software companies. Its mission is to bring to users greater value from computing, through the practical implementation of open systems. X/Open's strategy for achieving this goal is to combine existing and emerging standards into a comprehensive, integrated, high-value and usable system environment, called the Common Applications Environment (CAE). This environment covers the standards, above the hardware level, that are needed to support open systems. It provides for portability and interoperability of applications, and allows users to move between systems with a minimum of retraining. The components of the Common Applications Environment are defined in X/Open CAE Specifications. These contain, among other things, an evolving portfolio of practical application programming interfaces (APIs), which significantly enhance portability of application programs at the source code level, and definitions of, and references to, protocols and protocol profiles, which significantly enhance the interoperability of applications. The X/Open CAE Specifications are supported by an extensive set of conformance tests and a distinct X/Open trademark - the XPG brand - that is licensed by X/Open and may be carried only on products that comply with the X/Open CAE Specifications. The XPG brand, when associated with a vendor's product, communicates clearly and unambiguously to a procurer that the software bearing the brand correctly implements the corresponding X/Open CAE Specifications. Users specifying XPG-conformance in their procurements are therefore certain that the branded products they buy conform to the CAE Specifications. X/Open is primarily concerned with the selection and adoption of standards. The policy is to use formal approved de jure standards, where they exist, and to adopt widely supported de facto standards in other cases. Where formal standards do not exist, it is X/Open policy to work closely with standards development organisations to assist in the creation of formal standards covering the needed functions, and to make its own work freely available to such organisations. Additionally, X/Open has a commitment to align its definitions with formal approved standards. X/Open Specifications There are two types of X/Open specification: CAE Specifications CAE (Common Applications Environment) Specifications are the long-life specifications that form the basis for conformant and branded X/Open systems. They are intended to be used widely within the industry for product development and procurement purposes. Developers who base their products on a current CAE Specification can be sure that either the current specification or an upwards-compatible version of it will be referenced by a future XPG brand (if not referenced already), and that a variety of compatible, XPG-branded systems capable of hosting their products will be available, either immediately or in the near future. CAE Specifications are not published to coincide with the launch of a particular XPG brand, but are published as soon as they are developed. By providing access to its specifications in this way, X/Open makes it possible for products that conform to the CAE (and hence are eligible for a future XPG brand) to be developed as soon as practicable, enhancing the value of the XPG brand as a procurement aid to users. Preliminary Specifications These are specifications, usually addressing an emerging area of technology, and consequently not yet supported by a base of conformant product implementations, that are released in a controlled manner for the purpose of validation through practical implementation or prototyping. A Preliminary Specification is not a ``draft'' specification. Indeed, it is as stable as X/Open can make it, and on publication has gone through the same rigorous X/Open development and review procedures as a CAE Specification. Preliminary Specifications are analogous with the ``trial- use'' standards issued by formal standards organisations, and product development teams are intended to develop products on the basis of them. However, because of the nature of the technology that a Preliminary Specification is addressing, it is untried in practice and may therefore change before being published as a CAE Specification. In such a case the CAE Specification will be made as upwards- compatible as possible with the corresponding Preliminary Specification, but complete upwards-compatibility in all cases is not guaranteed. In addition, X/Open periodically publishes: Snapshots Snapshots are ``draft'' documents, which provide a mechanism for X/Open to disseminate information on its current direction and thinking to an interested audience, in advance of formal publication, with a view to soliciting feedback and comment. A Snapshot represents the interim results of an X/Open technical activity. Although at the time of publication X/Open intends to progress the activity towards publication of an X/Open Preliminary or CAE Specification, X/Open is a consensus organisation, and makes no commitment regarding publication. Similarly, a Snapshot does not represent any commitment by any X/Open member to make any specific products available. X/Open Guides X/Open Guides provide information that X/Open believes is useful in the evaluation, procurement, development or management of open systems, particularly those that are X/Open-compliant. X/Open Guides are not normative, and should not be referenced for purposes of specifying or claiming X/Open- conformance. Appendix B X/Open Standards Policy X/Open shall cooperate with formal standards bodies to bring standards-based Open Systems to the market in a timely and effective manner. It shall make its work available to standards bodies with such release of copyright as is required to permit material to be incorporated into formal standards. Where de jure standards exist, X/Open shall conform to them. Wherever possible, X/Open shall use International Standards approved by ISO/IEC or Recommendations approved by CCITT. In their absence it may adopt Regional or National standards which are likely to become internationally adopted. Where de jure standards are under development, X/Open shall ensure that its specifications are aligned with them. Where the results of X/Open work extend beyond that covered by the development of de jure standards, X/Open shall, in situations where formal ratification is appropriate, and where resources permit, submit its work to the standardization process. Where there is no de jure standard, X/Open may use de facto standards if they are broadly acceptable in the market place. X/Open, and its Technical Working Groups, shall observe the rules of the standards bodies with which they work and shall offer reciprocal liaison as required. Approved by the X/Open Board on 17th July 1991 ---------------------------------------------------------------------------- Dean Adams X/Open Company Limited Applications Portability Manager Apex Plaza, Forbury Road Reading, Berkshire. RG1 1AX England email: d.adams@xopen.co.uk Tel: +(44) 734 508311 ext 2242 or: uunet!xopen!d.adams FAX: +(44) 734 500110 ----------------------------------------------------------------------------