IEEE P1003.0 Draft 14 - November 1991 Copyright (c) 1991 by the Institute of Electrical and Electronics Engineers, Inc. 345 East 47th Street New York, NY 10017, USA All rights reserved as an unpublished work. This is an unapproved and unpublished IEEE Standards Draft, subject to change. The publication, distribution, or copying of this draft, as well as all derivative works based on this draft, is expressly prohibited except as set forth below. Permission is hereby granted for IEEE Standards Committee participants to reproduce this document for purposes of IEEE standardization activities only, and subject to the restrictions contained herein. Permission is hereby also granted for member bodies and technical committees of ISO and IEC to reproduce this document for purposes of developing a national position, subject to the restrictions contained herein. Permission is hereby also granted to the preceding entities to make limited copies of this document in an electronic form only for the stated activities. The following restrictions apply to reproducing or transmitting the document in any form: 1) all copies or portions thereof must identify the document's IEEE project number and draft number, and must be accompanied by this entire notice in a prominent location; 2) no portion of this document may be redistributed in any modified or abridged form without the prior approval of the IEEE Standards Department. Other entities seeking permission to reproduce this document, or any portion thereof, for standardization or other activities, must contact the IEEE Standards Department for the appropriate license. Use of information contained in this unapproved draft is at your own risk. IEEE Standards Department Copyright and Permissions 445 Hoes Lane, P.O. Box 1331 Piscataway, NJ 08855-1331, USA +1 (908) 562-3800 +1 (908) 562-1571 [FAX] ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 - The IEEE POSIX.4a: POSIX Pthreads extension; - The IEEE POSIX.6 POSIX security standard and POSIX.7 system administration standard; - The Ada language bindings (IEEE POSIX.5) and FORTRAN language bindings (IEEE POSIX.9) to POSIX; - The IEEE POSIX.10 Supercomputing Profile, POSIX.11 Transaction Processing Profile, and POSIX.13 Realtime Applications Profiles. As other standards emerge, they too will be incorporated in the Multiprocessing Systems profile. An annex of this document will deal with, and list, relevant emerging standards to provide an idea of the Multiprocessing Systems profile's direction. Multiprocessing-specific requirements identified by the POSIX.14 Multiprocessing working group include: - System administration tools for multiprocessors; - Parallelizing compilers; - Explicit parallelism; - Threads; - Thread-safe libraries; - Message-passing IPC; - Parallel utilities (e.g., find, grep, make, etc.); - Scheduler controls; - Processor allocation: mandatory/advisory; - Processor binding; - Degree of symmetry: I/O, computation, memory. Standards will be needed for many of these requirements. Many of these requirements will, therefore, become the subject of a POSIX.14 working group proposal for a new standardized function or an option in other Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 7.2 General Purpose POSIX SPs 241 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS standards. 7.2.3 Supercomputing 7.2.3.1 Rationale and Overview The Supercomputing Application Environment Profile (IEEE POSIX.10) is a profile designed to support application and programmer portability in POSIX-based supercomputer environments. The profile's goal is to allow supercomputer application code to be ported to other sites, reduce the learning curve of users, and encourage production of timely third-party applications. The need exists for such a profile because of the differences between supercomputing environments and traditional application environments. One difference is that supercomputing jobs are computationally intensive, very long running, and very demanding of resources. Another is that the cost of the supercomputer CPU and many of its peripheral resources is extremely high. Ordinary POSIX standards are not applicable in their entirety to supercomputer environments because the traditional UNIX-based POSIX functions are not adequate to meaningfully manage the use of, and accounting for, a supercomputer or its resources. Furthermore, supercomputers need much better tape handling, multiprocessing, and other capabilities than POSIX or UNIX specifications presently support. 7.2.3.2 Content of the Supercomputing Profile The Supercomputing Application Environment Profile identifies POSIX base standards and other relevant standards that support supercomputing requirements. Where none exist, the POSIX.10 working group will define the functionality itself, or instigate the formation of a new group to define it. In addition, the POSIX.10 working group is taking some of the traditional modifications built to allow UNIX systems to run on supercomputers, and making those modifications both consistent across supercomputers and portable to users, system administrators, and applications. Base computing standards specified by the supercomputing profile (or planned for specification when the standards are completed) include: Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 242 7 POSIX SP Profiling Efforts ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 - The IEEE POSIX.1 {2} core POSIX system, POSIX.2 POSIX Shell and Tools, and POSIX.2a User Portability Extensions (and the corresponding FIPS standards); - The IEEE POSIX.4 realtime work (particularly the use of its asynchronous I/O facility); - The IEEE POSIX.6 POSIX security standard and POSIX.7 system administration standard; - Several graphics standards, including ISO GKS, PHIGS, and CGM, ANSI IGES, and the X Consortium's PEX. - X3H2.6 (also called X11) for windowing; - Several programming languages, including ISO, ANSI, and the NIST's FIPS for C, FORTRAN-77, Pascal, Ada, Common LISP, and COBOL. - TCP/IP protocol stacks and network applications (e.g., file transfer and messaging) now and OSI in the long-term; - The IEEE POSIX.8 Transparent File Access standard for distributed file management; - The X3T5.5 Remote Procedure Call (RPC). The nonstandardized and nonavailable supercomputing functions identified in the POSIX.10 profile include: - Batch system scheduling, administration, and network definition; - Checkpoint recovery; - A resource manager; - A better tape management facility; - Better mass storage/archiving facilities. There are no existing standards for batch scheduling and administration facilities. Batch scheduling and administration extensions to POSIX base standards are currently being defined by the IEEE POSIX.15 working group- --a group spawned by the Supercomputing profile working group. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 7.2 General Purpose POSIX SPs 243 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS To meet recovery and archiving requirements, the POSIX.10 working group defined system interfaces for functions that perform ``checkpoint,'' ``restart,'' and better magnetic tape handling (e.g., to rewind a tape under program control). These interfaces have been submitted to the POSIX.1 working group for inclusion in the next POSIX.1 {2} revision. 7.2.4 Transaction Processing 7.2.4.1 Rationale and Overview The Transaction Processing Application Environment Profile (IEEE 1003.11) is intended to support the development of portable online transaction processing (OLTP) applications in POSIX environments. This profile is targeted at application developers and open system services suppliers. It is important because transaction processing is a major area of business for most large computer vendors and it plays a major role in the daily operations of most users. There are currently no existing POSIX functions that specifically address OLTP needs. 7.2.4.2 Content of the Transaction Processing Profile The Transaction Processing profile's goal is to identify the interfaces and standards relevant to OLTP, and optional functions in existing standards that must be made mandatory for OLTP applications. The profile will specify general-purpose standards, as well as standards unique to OLTP. The Transaction Processing Profile's specifications include or plan the following generic and transaction processing-specific standards: - The ISO/IEC 9945-1: 1990 (POSIX 1003.1) core POSIX system interfaces (including required options, minimum values for certain variables, and particular environment variables needed for OLTP applications); - The IEEE 1003.2 Shell and Utilities' software development utilities option, C language development utilities option, and C language bindings option; - The IEEE 1003.2 getconf utility; - The realtime files and asynchronous input and output features from the IEEE 1003.4 Realtime POSIX Extensions; Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 244 7 POSIX SP Profiling Efforts ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 - The IEEE 1003.6 POSIX security standard; - The ISO/IEC, ANSI, and FIPS C and COBOL programming languages; - TCP/IP networking in the short term and OSI in the long-term; - The X3T5.5 Remote Procedure Call (RPC) - The ISO SQL database language; - The ISO Distributed Transaction Processing 10026.1, .2, and .3 for communication of transaction information. The Transaction Processing profile also identifies extensions needed to existing standards to support distributed transaction processing. Important extensions that need to be defined include those related to the two-phase commit, as well as others related to making RPCs robust. The P1003.11 working group is working with the ISO RPC Group to add transaction semantics to the Networking working group's RPC specifications. These extensions will be incorporated in the Transaction Processing profile. Plans are also for the 1003.11 profile to draw on the transaction processing work being produced by the X/Open consortium, particularly on the XA interfaces (the interface between a Transaction Manager and a Resource Manager). 7.2.5 Realtime Application Profiles 7.2.5.1 Rationale and Overview Different types of realtime applications have different characteristics and diverse requirements. For example, embedded systems generally do not need the full functionality of an operating system, nor do they require all the IEEE POSIX.4 realtime extensions. Compliance with the entire realtime standard and/or POSIX operating system interfaces could reduce the embedded system's responsiveness and increase the amount of memory needed for systems that need to be embedded in limited space. High-end realtime systems, on the other hand, have softer realtime requirements. However, they need the full operating system and realtime functionality. Therefore, the POSIX.13 working group was formed to define profiles for various types of realtime applications. The realtime profiles defined will determine which interfaces must be implemented for a given type of Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 7.2 General Purpose POSIX SPs 245 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS realtime system to claim conformance to the realtime standard. 7.2.5.2 Targeted Realtime Application Profiles e The POSIX.13 working group is defining profiles to address several types e of realtime applications. These include: e - Low-end, embedded systems (often known as ``hard'' realtime systems); - Mid-range realtime systems with medium-level critical realtime constraints; - High-end realtime systems. 7.2.5.2.1 Embedded Realtime Systems e Embedded realtime systems are typically standalone systems used for robot controllers, automated systems controllers, instrumentation, high-speed data acquisition, satellite subsystem control, flight control, some e process control, and some testing. Time-critical responsiveness is a key e requirement of embedded systems. In the absence of a standard, the realtime functionality required for embedded systems is generally provided by a proprietary realtime kernel or a simple home-grown monitor using memory mapped I/O. Since low-end embedded systems need only minimal functionality, the POSIX.13 working group will select a relatively small number of POSIX.4 and POSIX.1 {2} functions that will be required for portable realtime embedded systems. These functions will be selected for several types of e embedded applications. e One type of embedded application is a minimal system, usually buried e deeply in the overall system electronics. Such minimal applications have e no requirements for a file system, multiple processes, or I/O via e specific device drivers. The minimal realtime profile, however, will e specify the POSIX.4a threads extension to support multiple flows of e control. e The second type of embedded application is often used in control systems. e Realtime controller applications require a file system and threads, but e not multiple processes. e Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 246 7 POSIX SP Profiling Efforts ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 7.2.5.2.2 Mid-Range Realtime Applications e Mid-range or intermediate-level realtime profiles are targeted at e compute-oriented applications that are typically used in avionics, radar e systems, submarines, and medical imaging equipment, as well as e controllers that control a group of robots or a subsystem on the factory e floor. These applications tend to run on platforms that are dedicated to e a single application set or mission mode. e The design complexity of such dedicated realtime applications varies from e simple to complex to accommodate a range of requirements. Such e requirements may include sophisticated signal processing capabilities, e but do not necessarily include a file system. A profile that satisfies e these requirements would likely specify most of the POSIX.4 functionality e (except for file system facilities), along with relevant options from the e POSIX.4 and POSIX.1 {2} standards and the POSIX.4a threads extension. e 7.2.5.2.3 High-End Realtime Applications e High-end realtime applications are applicable to complex, multipurpose e realtime systems. Such multipurpose realtime systems typically are used e in military command and control, in space station control systems, in e systems that control robot or factory subsystems, as the operating system e for high-end simulation systems, and at high-functionality realtime e application that are paced by operator interaction. e The current realtime, multipurpose profile is geared to full-function e realtime systems such as simulation applications and embodies most of the e existing practice in the simulator world. Since simulation systems have e a greater design complexity than embedded or mid-range systems, and need e much greater functionality, the multipurpose realtime profile will most e likely require all or most of the POSIX.4 and POSIX.1 {2} standards. e This profile does not require threads. It does, however, specify the X11 e window system as the basis for a human-computer interface. e Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 7.2 General Purpose POSIX SPs 247 __________ 4) Refer to the earlier footnote on _i_n_t_e_r_n_a_t_i_o_n_a_l _h_a_r_m_o_n_i_z_a_t_i_o_n. e P1003.0/D14 Annex A (informative) Considerations for Developers of POSIX SPs A.1 Introduction _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _B_o_b _G_a_m_b_r_e_l The contents of this Annex are illustrative of rules that might be developed for the submitters of POSIX Standardized Profiles (SPs). This Annex contains modifications and comments relating to the use of the _T_C_O_S-_S_S_C _P_O_S_I_X _S_t_a_n_d_a_r_d_s _S_t_y_l_e _G_u_i_d_e {B6} in POSIX SPs. A.2 Scope While Section 6 addressed profiles generally, this Annex addresses considerations for developers of formal POSIX Standardized Profiles. It builds directly upon the concepts, principles, and guidance of Section 6. _N_o_t_e _t_o _r_e_v_i_e_w_e_r_s: _T_h_i_s _A_n_n_e_x _i_s _n_o_t _c_o_m_p_l_e_t_e, _i_n _t_h_a_t _m_o_r_e _w_o_r_k _i_s _r_e_q_u_i_r_e_d _i_n _t_h_e _d_o_m_a_i_n _o_f _P_O_S_I_X _p_r_o_f_i_l_e_s. _F_u_t_u_r_e _w_o_r_k _i_n _t_h_e _a_r_e_a _o_f _p_r_o_f_i_l_i_n_g _w_i_l_l _b_e _d_o_n_e _b_y _I_E_E_E _a_n_d _t_h_e _s_t_a_n_d_a_r_d_s _c_o_m_m_u_n_i_t_y. _T_h_i_s _d_o_c_u_m_e_n_t, _a_n_d _t_h_e _g_u_i_d_a_n_c_e _i_t _p_r_o_v_i_d_e_s, _w_i_l_l _b_e _u_p_d_a_t_e_d _a_s _a_p_p_r_o_p_r_i_a_t_e. _T_h_e _m_a_j_o_r _a_r_e_a_s _e_x_p_e_c_t_e_d _t_o _b_e _a_d_d_r_e_s_s_e_d _a_r_e: - _I_n_t_e_r_n_a_t_i_o_n_a_l _s_t_a_n_d_a_r_d_i_z_a_t_i_o_n _c_o_n_s_i_d_e_r_a_t_i_o_n_s - _C_o_n_f_o_r_m_a_n_c_e _i_s_s_u_e_s - _T_a_x_o_n_o_m_y _o_f _P_O_S_I_X _S_P_s - _R_e_g_i_s_t_r_a_t_i_o_n _o_f _P_O_S_I_X _S_P_s - _D_e_l_e_g_a_t_i_o_n _o_f _a_u_t_h_o_r_i_t_y _t_o _c_a_l_l _s_o_m_e_t_h_i_n_g _a _P_O_S_I_X _S_P (_N_o_t_e: _C_u_r_r_e_n_t_l_y, _t_h_i_s _d_o_c_u_m_e_n_t _d_o_e_s _n_o_t _p_r_o_h_i_b_i_t _a_n_o_t_h_e_r _g_r_o_u_p _b_e_s_i_d_e _I_E_E_E _f_r_o_m _c_a_l_l_i_n_g _t_h_e_i_r _d_o_c_u_m_e_n_t _a _P_O_S_I_X _S_P.) Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. A.2 Scope 249 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS - _C_l_a_r_i_f_i_c_a_t_i_o_n _o_f _b_a_s_e _s_t_a_n_d_a_r_d_s _r_e_f_e_r_e_n_c_i_n_g _i_s_s_u_e_s _s_u_c_h _a_s _s_u_b_s_e_t_t_i_n_g _a_n_d _t_h_e _h_a_n_d_l_i_n_g _o_f _o_p_t_i_o_n_s - _E_d_i_t_o_r_i_a_l _i_s_s_u_e_s _s_u_c_h _a_s _g_u_i_d_a_n_c_e _o_n _t_h_e _c_o_r_r_e_c_t _l_e_v_e_l _o_f _d_e_t_a_i_l - _A_d_d_i_t_i_o_n_a_l _g_u_i_d_a_n_c_e _o_n _r_e_f_e_r_e_n_c_i_n_g _b_a_s_e _s_t_a_n_d_a_r_d_s _a_n_d ``_s_t_a_n_d_a_r_d_s _i_n _p_r_o_g_r_e_s_s'' A.3 The Role of POSIX SPs In 6.3.3.5, a classification scheme was given for profiles in which three different ``types'' were identified. That scheme is based, essentially, on the scope covered by the profile. Another useful classification scheme, based on scope and on who develops the profiles, is presented in this annex. Figure A-1 shows these classes of profiles and the relationships between them and base standards. _________________________________________________________________________ _________________________________________________________________________ Figure A-1 - Universe of Profiles and Standards Base standards cover a universe of diverse needs. POSIX base standards (e.g., POSIX.1 {2}, P1003.4, ...) cover a narrower set of needs related to ``POSIX.'' In the figure, the POSIX base standards are shown as a Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 250 A Considerations for Developers of POSIX SPs ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 small subset of the larger world of base standards. At the other end of the spectrum, organization-specific (e.g., company- specific) profiles are large in number and range even more widely in their coverage. (There are many more organizations procuring systems, and effectively writing profiles, than there are committees writing standards.) Industry-specific profiles are based on specific industry needs. From the point of view of the organization-specific profile writer, industry specific profiles are applicable to many organizations (in the same industry), and hence are possibly not precisely what any specific individual organization needs. They address the broad consensus of the industry, from which there is usually deviation when you look at individual organizations whose needs range further. Standardized Profiles are formal balloted documents. POSIX SPs are the subset of standardized profiles that pertain to the POSIX base standards. While not limited to just POSIX base standards, POSIX SPs nonetheless provide a distinctly POSIX-oriented view of the base standards. An organization wishing to procure a ``POSIX'' based system, then, could first develop its own organization-specific profile, which it could base on POSIX-oriented industry-specific profiles (if available), which in turn could be based on POSIX SPs, which of course are based on the various POSIX base standards. POSIX SPs provide an industry-neutral building block for creating industry specific profiles. The developers of POSIX SPs do not have to have knowledge of any particular industry. They furthermore help ensure coherence among the many base standards referenced, particularly among the various POSIX base standards. As such, probably, most POSIX SPs will be created by the IEEE POSIX working groups meeting concurrently with IEEE POSIX base standards working groups. Meeting concurrently at the same place helps ensure the coherence of the base standards and the harmony among the POSIX SPs. A.4 Special Rules for POSIX SPs While no rules have yet been developed by IEEE for POSIX SPs, the remainder of this annex gives examples of what such rules might say and identifies some issues for which rules might be drafted. The following criteria for calling a profile a POSIX SP were developed according to some general principles that have the aim of giving definite value to the word ``POSIX'' when used with regards to profiles. The general principles are: Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. A.4 Special Rules for POSIX SPs 251 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS (1) There is minimum content. Specifically, a POSIX SP must reference some part of the suite of POSIX base standards. (Which part specifically is contentious.) (2) The POSIX SP must follow a specific approach to conformance (specifically the P1003.3.1 test methodology.) (3) The POSIX SP must adhere to the POSIX Reference Model. (4) There is maximum content; i.e., some consideration must be given to how the POSIX SP goes beyond the POSIX OSE as described in this guide. (5) Exceptions to the previous principles are expected, requiring a rule-making and enforcement body to make those exception decisions. POSIX SPs are Standardized Profiles that are related to ``POSIX.'' This subclause specifies the rules that need to be followed that distinguish POSIX SPs from ``Non-POSIX SPs''. Each POSIX SP is based on, and shall include, one of the following two base standards sets: (1) POSIX.1 {2} or POSIX.2 (as verified by the P1003.3 methodology), or (2) A particular subset of POSIX.1 {2} and P1003.4 that is being specified for a Minimal Realtime profile (as verified by the P1003.3 methodology.) Additionally, each POSIX SP adheres to the structure defined by the POSIX OSE reference model. An approved POSIX SP shall make reference only to base standards identified in this guide (1003.0) as being part of the POSIX OSE. Two specific exceptions to this general rule are allowed for as described here: (1) Reference can be made to required base standards that are clearly outside of the scope of the POSIX OSE. Examples of the functionality that may require the use of this expedient are: - Physical connectors - Electrical characteristics - Safety requirements Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 252 A Considerations for Developers of POSIX SPs ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 Such reference to items outside the scope of the POSIX OSE shall be justified on a case-by-case basis. It shall be accompanied by details of the body responsible for the distribution and maintenance of the referenced base standard. (2) Reference can be made to required base standards that are being proposed for inclusion in a future version of the guide. Examples of this would be specification of a later version of a base standard that is already included within the POSIX OSE, or of an additional programming language base standard, not yet included within the POSIX OSE. In such cases, the POSIX SP should be identified as a POSIX Preliminary SP and the specific references should be clearly noted and justified on a case by case basis. A POSIX Preliminary Standardized Profile (POSIX Preliminary SP) is a POSIX SP that satisfies all requirements of a POSIX SP except that it is not a subset of the POSIX OSE. [It therefore contains at least one standard or profile that is outside the POSIX OSE. It is expected that application would be made to POSIX.0 to include the standard(s) or profile(s) in the POSIX OSE.] A further restriction of POSIX SPs is the necessity to (normatively) reference only standards that are recognized by the IEEE. This is limited to IEEE and ISO standards. Approval of a POSIX SP shall not change the status of any documents referenced by it. The development of a POSIX SP may indicate the need to modify or to add to the requirements specified in a base standard. In this case, it is necessary for the POSIX SP developer to liaise with the body responsible for that base standard so that the required changes may be made through established methods such as defect reporting, amendment procedures, or the introduction of new work. A.5 Other Issues A significant number of issues remain to be addressed concerning the management of POSIX SP development. Some of the issues and the concerns are summarized here. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. A.5 Other Issues 253 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS Coherence The insurance of coherence among the many base standards referenced by a profile has been found by profile writers to be an onerous task. The profile writer's burden could be eased significantly if base standards writers address coherence at the outset. Specifically, all the P1003.x base standards should be developed to maximize their coherence. This is seen as a management issue for TCOS-SEC, the sponsoring body of the P1003.x standards. Conformance The development of conformance statements and test methods for profiles is a significant challenge for profile writers. The challenge is most acute in the area of conformance of standards that are being developed outside of P1003. A premise for the profile writing rules associated with conformance must be that the profile writers are not really experts in the referenced standards. Profile writers (especially at this early period in their development) must not be overburdened with untested conformance writing rules. A possible solution is to create a new project under the auspices of P1003.3 to actually generate new test methods and actually write the necessary assertions for the first profile. (This approach was used also for the initial POSIX base standard.) Base Standards Working Groups Because profile writers are in some sense the customers of base standards, it is important for base standards writers to address with priority and urgency the gaps identified in the development of POSIX SPs. Scope and Number of POSIX SPs How many different POSIX SPs are appropriate and how broadly ranging should be their scope? Should POSIX SPs be rather narrowly focused, spanning just a few base standards, or should they address a large number of base standards? Issues Pertaining to Referencing Base Standards Many practical writing issues pertain to referencing, for instance, parts of base standards. This includes not only referencing options, but even the concept of subsetting, or reducing the functionality of a base standard. Also an issue is how to reference multiple versions of the same standard (e.g., two different COBOL standards.) Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 254 A Considerations for Developers of POSIX SPs ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 POSIX SP Procedures and Rules What does it mean to be a POSIX SP? Rule making for use of the word ``POSIX'' must address criteria for such use. Also, many issues remain to be resolved in the area of ballot procedures. Should IEEE delegate to others the ability to develop POSIX SPs? If so, should IEEE maintain a registry of such efforts? A.6 Conformance to a POSIX SP A POSIX SP must address test methods for itself. In the simplest case, testing the base standards referenced is sufficient. In more complex cases, additional test methods will be necessary. In the worst case (if a base standard is subsetted, for example), the test methods for the base standards may have to be rewritten or expanded within the POSIX SP. At the same time, P1003.3 will have to consider revisions to the _T_e_s_t _M_e_t_h_o_d_s _f_o_r _M_e_a_s_u_r_i_n_g _C_o_n_f_o_r_m_a_n_c_e _t_o _P_O_S_I_X to address test methods for POSIX SPs (e.g., additional assertion types, minimum requirements for testing POSIX SPs, ...) A.7 Structure of Documentation for POSIX SPs This clause gives specific format and content requirements to profile writers who are developing POSIX SPs. A.7.1 Principles The requirements for content and format of POSIX SPs are based on the following principles: (1) Profiles shall be directly related to base standards and conformance to profiles shall imply conformance to base standards. (2) POSIX SPs shall follow the rules for drafting and presentation of POSIX SPs detailed here. (3) POSIX SPs are intended to be concise documents that do not repeat the text of the base standards. (4) Profiles making identical use of particular base documents shall be consistent, down to the level of identical wording in the POSIX SPs for identical requirements. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. A.7 Structure of Documentation for POSIX SPs 255 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS A.7.2 Multipart POSIX SPs Many profiles will be documented and published as individual POSIX SPs. However, where close relationships exist between two or more profiles, a more appropriate technique can be used. Common text between related profiles is essential to ensure consistency, portability, and interworking, to avoid unnecessary duplication of text, and to aid writers and reviewers of POSIX SPs. A _s_i_n_g_l_e-_p_a_r_t _P_O_S_I_X _S_P shall not contain the definition of more than one profile. The following rules apply to _m_u_l_t_i_p_a_r_t _P_O_S_I_X _S_P_s: (1) A multipart POSIX SP shall contain the definition of a complete profile or of a related set of profiles. (2) A part of a multipart POSIX SP may contain a section of the definition of one or more profiles. (3) Where a multipart POSIX SP includes more than one profile, the part structure shall permit each profile to be the subject of a separate ballot; i.e., its constituent profiles shall be clearly identifiable, and the multipart structure shall ensure that this can be accomplished. (4) Wherever possible, the references made from one part to another should be to complete parts. However, controlled use of one-way references to sections of other parts is permitted in order to obtain a reasonable multipart structure. Because there may also be potential disadvantages from overuse of the multipart POSIX SP capability, such as difficulties in gaining approval for a complex linked set of parts, or reduction of the content of a part to a small amount of text, considerable care should be taken with its use. NOTES: (1) When a section of text appears in several profiles, possibilities exist for sharing the corresponding code (etc.) for the implementation of several profiles, and the tests applicable to the use of the referenced base standards will be applicable to the testing of several profiles. (2) It follows that it is in the interest of the implementors to promote the identification of common sections of text as parts of POSIX SPs, but even more to promote, in future standardization and profile work, the use of already defined Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 256 A Considerations for Developers of POSIX SPs ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 parts of POSIX SPs, so that profiles fall into a few ``common molds.'' In particular, this allows implementation of a part of a POSIX SP with confidence that it may be used in the implementation of profiles as yet undefined, so that products are open to future development. (3) Possibilities exist for a complete profile to be referenced from within the definition of another profile. A.8 Rules for Drafting and Presentation of POSIX SPs Throughout this Annex, which is concerned with documentation content and layout, reference is made to POSIX SPs. A POSIX SP, or part thereof, may contain a whole profile definition or part of one or more profile definitions. The wording of the Annex assumes that it is describing an undivided POSIX SP that defines one profile in its entirety. Its application to the other cases is easily deduced. Note, however, that each part of a Multipart POSIX SP shall use the same format as far as appropriate. A.8.1 General Arrangement The elements that together form a POSIX SP are classified into three groups: (1) Preliminary elements are those elements that identify the POSIX SP, introduce its content, and explain its background, its development, and its relationship with other standards and POSIX SPs. (2) Normative elements are those elements setting out the provisions with which it is necessary to comply in order to be able to claim conformity with the POSIX SP. (3) Supplementary elements are those elements that provide additional information intended to assist the understanding or use of the POSIX SP. These groups of elements are described in the following clauses. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. A.8 Rules for Drafting and Presentation of POSIX SPs 257 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS A.8.2 Preliminary Elements A.8.2.1 Foreword The foreword shall appear in every POSIX SP. It consists of a general part giving information relating to the organization responsible and a specific part giving as many of the following as are appropriate: - An identification of the organization or committee that prepared the POSIX SP; information regarding the approval of the POSIX SP - A statement that the POSIX SP cancels or replaces other documents in whole or in part - A statement of significant technical changes from the previous edition - A statement of which annexes are normative and which are informative A.8.2.2 Introduction The introduction shall appear in every POSIX SP. It gives specific information about the process used to draft the POSIX SP and about the degree of international harmonization that it has received. A.8.3 General Normative Elements A.8.3.1 Title The title shall be composed of the following three elements: (1) An introductory element: _S_t_a_n_d_a_r_d _f_o_r _I_n_f_o_r_m_a_t_i_o_n _T_e_c_h_n_o_l_o_g_y (2) An identification element: _P_O_S_I_X _S_t_a_n_d_a_r_d_i_z_e_d _P_r_o_f_i_l_e (3) A main element indicating the subject matter of the POSIX SP. For a Multipart POSIX SP, this element shall be subdivided into a general title element common to all parts, and a specific title element for each part; where necessary, this specific element may include the identifier of an individual profile. The first word of this element should be the word ``POSIX''. Example: Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 258 A Considerations for Developers of POSIX SPs ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 Standard for Information Technology -- POSIX Standardized Profile -- POSIX Transaction Processing A.8.3.2 Scope This element contains two subclauses as follows: (1) General This element shall appear at the beginning of the POSIX SP or POSIX SP part to define without ambiguity the purpose and subject matter of the document, thereby indicating the limits of its applicability. It shall not contain requirements. (2) Scenario If the POSIX SP or POSIX SP part defines a profile, it shall include (where appropriate) the ``scenario'' of the profile; i.e., an illustration of the environment within which it is applicable. This may show in a simplified graphic form how this fits within the POSIX Reference Model. A profile should first introduce the functional area being addressed and the applications activities within that area. The requirements that have been addressed should be delineated, as well as those areas outside of the scope of the profile. A.8.3.3 Normative References This element shall give a list of normative documents (base standards), with their titles and publication dates, to which reference is made in the text in such a way as to make them indispensable for the application of the POSIX SP. Where published amendments or technical errata to base standards are relevant to the definition of the profile in such a way as to have a potential impact on interworking or portability, they shall be explicitly referenced here. Reference shall also be made to this guide. A.8.4 Technical Normative Elements A.8.4.1 Requirements This element includes clauses relating to the use made of each of the main base standards referenced in the profile definition. The content and layout of these clauses are not defined, but can be tailored to the type of material that has to be specified in each case. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. A.8 Rules for Drafting and Presentation of POSIX SPs 259 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS The information given shall not repeat the text of the base standards, but shall define the choices made in the profile of classes, subsets, options and ranges of parameter values. It shall be in the form of conformance requirements and may, where appropriate, be given in tabular form. See 6.3.3 for more detail concerning the nature of the content required in this element of a POSIX SP. A.8.4.2 Normative Annexes Normative annexes are integral sections of the POSIX SP that, for reasons of convenience, are placed after all other normative elements. The fact that an annex is normative (as opposed to informative) shall be made clear by the way in which it is referred to in the text, by a statement to this effect in the foreword, and by an indication at the head of the annex itself. A.8.5 Supplementary Elements A.8.5.1 Informative Annexes Informative annexes give additional information and are placed after the normative elements of a POSIX SP. They shall not contain requirements. The fact that an annex is informative (as opposed to normative) shall be made clear by the way in which it is referred to in the text, by a statement to this effect in the foreword, and by an indication at the head of the annex itself. Informative annexes provide a point for documenting useful information for the users of a profile that poses no requirements. Such annexes can include: (1) Specification of additional standards or options that will make the profile useful for specific locales (character sets, etc.) (2) Pointers to the referenced standards and information on ordering these (3) Pointers to related specifications that may provide additional insight or potentially serve to fill gaps in the profile (4) Comments and concepts in using the profile for various target readers. This could include use in procurements (perhaps cross referencing related procurement standards like the FIPS in the US). The annex may be used to provide recommendations for use that are not warranted in the standard (e.g., ``Algol is not recommended for new applications development''). Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 260 A Considerations for Developers of POSIX SPs