WG15 N694 IST/5/-/15 P330r UK Action Item Report to WG15, October 1996 9605-12 Member Bodies - respond to IDI to indicate interest, e-mail, and address for the HoD's interested in receiving access to the PASC electronic distribution of materials. The UK has responded and is receiving the email distribution. UK panel members have also been encouraged to join the IDI email distribution list. 9605-14 Members Bodies - provide comments to the convener on documents N633, and N634 regarding conformity assessment plans and interoperability before August 1 for input to the SC22 meeting. Done. UK P322 contained the following comments: "The UK MB comments to WG15 are that, while the aims of the JTC1 papers are to be applauded, we believe that sourcing and directing the required effort at SC and WG level will be problematic. "Experts are drawn to contribute to the standards process usually because they (or their employers) see a need for a document to clarify existing practice or to point a way for emerging technology. The experts are volunteers but the costs to their employers are not insubstantial. These 'technology' experts are not necessarily the same group of people with expertise in conformity assessment, and JTC1 will need to attract people from that group in order to achieve its goals. "This implies extra costs, not just in financial terms, but also in terms of the management of the standardisation process, where different groups of experts may need to be shepherded through the sequence necessary to create a single 'conforming' standard. "Management of the process will have to take account, from the very start of a project, whether conformity assessment is likely to be a requirement of that project, and if so whether the necessary effort is available. In some circumstances, where a project is deemed to be of critical importance but where conformity experts are not available for whatever reason, JTC1 may have to decide whether to proceed at all, and if so whether to attempt to 'buy in' the conformity expertise; the effects here could be very extensive indeed." 9605-17 Member Bodies - report to the convener if they have volunteers for representing SC22 in the GII working group. The UK had no volunteers to offer. 9605-19 Member Bodies - recommend people as project editors for the following areas: Ada, OSE, and Profiles. The UK has no volunteers to offer at this time. 9605-21 Member Bodies - look for a solution to the problem of extended identifiers in 1003.2 (from RIN issue 0) and report back. The UK understands that the C group (WG14) are currently discussing a solution to this type of problem using the trigraph notation. The UK believes it may be useful to await the outcome of WG14's deliberations. 9605-40 Member Bodies - communicate this information (on non width space and soft hyphen) to their internationalization experts to deal with. The UK accepts that there is an issue here for further discussion. The C standard does not address any characters outside ISO 646. Thus the definition of which characters outside ISO 646 belong in which specific category is left to the implementor. Looking at 8859, it appears that the only way to distinguish is by column; eg, anything in columns 9 and 10 appear to share similar characteristics to those of columns 1 & 2, ie they are characters: Column 9: /d128 PADDING CHARACTER (PAD) /d129 HIGH OCTET PRESET (HOP) /d130 BREAK PERMITTED HERE (BPH) /d131 NO BREAK HERE (NBH) /d132 INDEX (IND) /d133 NEXT LINE (NEL) /d134 START OF SELECTED AREA (SSA) /d135 END OF SELECTED AREA (ESA) /d136 CHARACTER TABULATION SET (HTS) /d137 CHARACTER TABULATION WITH JUSTIFICATION (HTJ) /d138 LINE TABULATION SET (VTS) /d139 PARTIAL LINE FORWARD (PLD) /d140 PARTIAL LINE BACKWARD (PLU) /d141 REVERSE LINE FEED (RI) /d142 SINGLE-SHIFT TWO (SS2) /d143 SINGLE-SHIFT THREE (SS3) Column 10: /d144 DEVICE CONTROL STRING (DCS) /d145 PRIVATE USE ONE (PU1) /d146 PRIVATE USE TWO (PU2) /d147 SET TRANSMIT STATE (STS) /d148 CANCEL CHARACTER (CCH) /d149 MESSAGE WAITING (MW) /d150 START OF GUARDED AREA (SPA) /d151 END OF GUARDED AREA (EPA) /d152 START OF STRING (SOS) /d153 SINGLE GRAPHIC CHARACTER INTRODUCER (SGCI) /d154 SINGLE CHARACTER INTRODUCER (SCI) /d155 CONTROL SEQUENCE INTRODUCER (CSI) /d156 STRING TERMINATOR (ST) /d157 OPERATING SYSTEM COMMAND (OSC) /d158 PRIVACY MESSAGE (PM) /d159 APPLICATION PROGRAM COMMAND (APC) > 1. What should be the classification of a > character in a LC_CTYPE definition? Neither POSIX nor ANSI can specify this, as the character does not belong to either character repertoire. Character classes could (and possibly should) be defined by code set standards. In the absence of any such standards, the 'consensus' (X/Open?) may be the right choice. We think that probably should be but not ; it is not a word delimiter. Certainly it is *NOT* a space character. > 2. what should be the classification of a character > in a LC_CTYPE definition? <--> /d173 SOFT HYPHEN See above. is used to signal word processors that a word can be hyphenated at this point. it is not a normal space character in the POSIX sense; it belongs in the category. > 3. What is the toupper character of an ? > . > There are two possibilities: or . > [The latter is a ] That's an easy one... as i and I are both members of the POSIX portable character set (and of the 'C' set), you have the classical definition. It may be illogical from a philologic viewpoint, but here tradition takes over. The and the are, outside an academic environment, strictly non-starters. 9605-43 Member Bodies - verify that normative reference to the new C Language Standard and Amendments does not cause any problems with 9945-1 and 9945-2. The UK does not believe that this will cause a problem with POSIX, although the definition of mbstate_t in MSE has been found to be problematic and very inefficient to implement on existing ISO POSIX implementations. Specifically, the problem occurs if a code set is being used such that mbstate_t needs to preserve multiple levels of reserved state - the MSE implies this will be unlimited amounts of reserved state, which for some codesets is very very expensive. There is also a section of the MSE on stream orientation where it is not apparently clear whether the text restricts applications or implementations. In checking with various experts it seems that the MSE text is an application contraint, not an implementation constraint. 9605-46 Member Bodies - have their technical experts identify any specific elements of the Single Unix Specification that should be included in POSIX. The UK has no proposals at this time. UK BSI IST/5/-/15 October-1996