ISO/IEC JTC1/SC22/WG20 N722

Title: Issues list number 3 for ISO/IEC 15435: i18n API.

Source: Keld Simonsen, project editor

Date: 1999-11-10

Open issues:

11. Word breaks

Should we have hyphenation APIs?

Recommendation: to be investigated. Ken Whistler will provide input on word break.

12. Composite sequences

Should we have composite sequences support?

Recommendation: we should look at it. Khaled will provide input.

14. implementabilty

How can we check inplementability?

Proposal: ask implementers.

15. Spelling

Shall we address spelling?

Closed issues:

1. LIS

1.1 The APIs will be written in language independent specification,

(LIS) so as many as possible bindings can be done. The LIS specification method is chosen as a simple technique only giving parameters and return values but type binding is done with each language.

1.2 different bindings.

Traditionally there would only be one language independent specification for each functionality but it is proposed to make more specifications for bindings to be better suited for binding to classes of languages. For example there could be one binding for languages having object oriented support, and another for languages without this support. A binding is then required to bind to at least one of these APIs to conform.

2. character set

2.1 Should the APIs run in one character set, 10646 or should it run in an abstract character set where the underlying encoding is unknown?

Resolution: use abstract character set. 10646 would then be a good way of implementing this data type.

2.2 Should the encoding of the internal character representation be dependent of locale (as in C and C++) or should it be uniform across all locales?

Resolution: it should be locale-independent.

3. monetary

Should Euro-issues be addressed:

Resolution: yes, euro-related issues like displaying conditionally two monetary amounts should be addressed.

4. strings

Many APIs operate on strings.

Should strings be null-terminated, or should they be determined by a specific length?

Resolution: to do both, when the length is specified, terminating bytes are allowed.

5. coverage

What should the APIs cover?

Resolution: that it covers all of the data in 14652, actually that it can address all of 14652 via a registry. It can then also address specific other issues, within the scope of the project. There are limits form the NP on what can be done.

6. thread-safe

Resolution: the APIs should be possible to be thread-safe.

7. functionality

Which style will the APIs be?

Resolution: there will be at least a set of APIs in C and POSIX style, like the str*() functions and the locale handling stuff. The APIs should be designed so that it is easy to migrate from existing C/POSIX APIs to this standard. Inspiration from C++ should also be taken.

8. Type of objects

Should the string, locale, encoding, and repertoire be a datatype, a "struct" or a class?

Resolution: "struct".

9. Rationale

A rationale for why this standard is required should be included.

Recommendation: included in the introduction.

10. C++ binding

Should we do a C++ binding?

Resolution: yes

13. localedef

Should we have a localedef-like utility?

Resolution: yes.