home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.19 / text0056.txt < prev    next >
Encoding:
Internet Message Format  |  1990-05-17  |  7.3 KB
  1. From: <jsh@usenix.org>
  2.  
  3.  
  4.             An Update on UNIX* and C Standards Activities
  5.  
  6.                              January 1990
  7.  
  8.                  USENIX Standards Watchdog Committee
  9.  
  10.                    Jeffrey S. Haemer, Report Editor
  11.  
  12. IEEE 1003.0: POSIX Guide Update
  13.  
  14. Charles Severance <crs@convex.cl.msu.edu> reports on the January 8-12,
  15. 1990 meeting in New Orleans, LA:
  16.  
  17. Dot zero is producing a guide to the POSIX Open System Environment
  18. (OSE).  The guide will bring existing and evolving standards together
  19. to provide specifications for all aspects of an OSE --  everything
  20. from application programming interfaces to user interfaces and system
  21. management.  It will give users an overview of the 1003, and other,
  22. related standards, describe their interrelationships, and help them
  23. select the subset of available standards necessary for any particular
  24. application.
  25.  
  26. Draft Six Review
  27.  
  28. This meeting, the group reviewed draft six.  Points of special
  29. interest were:
  30.  
  31.    + the formal definition of ``open system''
  32.  
  33.    + internationalization
  34.  
  35.    + an editorial review of the entire document to insure a consistent
  36.      style
  37.  
  38.    + a review of some high-level architecture diagrams, proposed to
  39.      make Chapter 3 (``Overall Architecture'') easier to understand,
  40.  
  41. The only one of these discussed by the entire group was the definition
  42. of ``Open System.'' To simplify the definition we created a definition
  43. for ``Open Standard'' which was used in the Open System definition.
  44. Here is the definition we finally agreed on:
  45.  
  46.      Open System: A system that implements sufficient Open
  47.      Specifications for interfaces, services, and supporting formats
  48.      which enable properly engineered applications software: a) to be
  49.  
  50. __________
  51.  
  52.   * UNIX is a registered trademark of AT&T in the U.S. and other
  53.     countries.
  54.  
  55. January 1990 Standards Update                 IEEE 1003.0: POSIX Guide
  56.  
  57.  
  58.                                 - 2 -
  59.  
  60.      ported across a wide range of systems with minimal changes, b) to
  61.      interoperate with other applications on local and remote systems,
  62.      and c) to interact with users in a style which facilitates user
  63.      portability.
  64.  
  65.      Open Specification: A public specification which is maintained by
  66.      an open, public, consensus process to accommodate new
  67.      technologies over time and consistent with international
  68.      standards.
  69.  
  70. The group won't define ``user portability'' until next meeting, but
  71. the idea is that users should see a consistent interface from
  72. application to application, both within and across systems.  Public
  73. user-interface standards should simplify both user training and vendor
  74. documentation.
  75.  
  76. The other issues were handled in small working groups.
  77.  
  78.   1.  Internationalization
  79.  
  80.       The internationalization group identified parts of the document
  81.       affected by internationalization and other ``cross-component''
  82.       issues, such as system management and security.  They promise to
  83.       present new, draft text for the internationalization sections by
  84.       the next meeting.
  85.  
  86.   2.  Editorial review
  87.  
  88.       The editorial review group tackled the no-fun jobs of reviewing
  89.       the entire draft for style and identifying areas that had too
  90.       much, or too little detail.  Along the way, they proposed a
  91.       style guide and template for sections of Chapter 4.
  92.  
  93.   3.  Architectural overview
  94.  
  95.       The architecture group continued work on Chapter 3 to complete
  96.       the text of the chapter.  Also the group worked to simplify the
  97.       chapter to make it easier to understand.  The CCTA (UK)
  98.       presented a high-level classification scheme called ``MUSIC''
  99.       (Management, User Interface, System Interface, Information
  100.       Interchange, and Communication) as a potential contribution to
  101.       chapter 3.  The chapter will have extensive modifications and
  102.       additions for the next meeting.
  103.  
  104. Application profiles
  105.  
  106. Next meeting we'll discuss exactly what must be in a POSIX Application
  107. Environment Profile (AEP).  Profiles will affect and generate
  108. procurement issues, so this will be a key discussion.
  109.  
  110. January 1990 Standards Update                 IEEE 1003.0: POSIX Guide
  111.  
  112.  
  113.                                 - 3 -
  114.  
  115. Profiles specify a set of standards for specific computing areas, such
  116. as supercomputing.  Not all standards will be required for all areas;
  117. a profile lists the subset of the standards necessary for a particular
  118. area.
  119.  
  120. The biggest point of contention in this discussion will probably be
  121. whether 1003.1 [Editor: the system interfaces set out in the Ugly
  122. Green Book] will be required for all profiles.  Should vendors be
  123. allowed to advertise compliance to, say, 1003.11 (transaction
  124. processing), if they've implemented that standard on an underlying
  125. system that doesn't support lower-level POSIX calls like fopen()?
  126. (There isn't a standard for 1003.11 yet, but you get the idea.)
  127.  
  128. One argument advanced for requiring 1003.1 is that it will force
  129. vendors to adopt it more quickly.  I don't think that 1003.1 needs any
  130. help in that area.  Another is that requiring compliance will insure
  131. that vendors who want to advertise POSIX-compliant systems are
  132. following the general POSIX direction and not just implementing the
  133. simplest standard so they can claim that their system implements
  134. ``some POSIX.''
  135.  
  136. An argument made against the requirement is that it may damage
  137. implementations.  For example, real-time systems may lack even a file
  138. system, and may want a very limited subset of the POSIX interface to
  139. keep the implementation as small as possible.  If all of 1003.1 is
  140. required, vendors may have to add costly and unnecessary features just
  141. to claim POSIX compatibility.
  142.  
  143. When the dust settles, I think 1003.1 will be strongly suggested but
  144. not required, because 1003.1 is a pretty arbitrary subset of any list
  145. of ``required system interfaces.''
  146.  
  147. [Editor: We disagree.  1003.1 is a set of applications programming
  148. interfaces carefully chosen to be necessary and sufficient to make an
  149. operating system UNIX-like for the C programmer.  Providing standards
  150. for a UNIX-like operating system should be the goal of the POSIX
  151. standards, and attempts by vendors uncomfortable with UNIX to dilute
  152. the effort should be cut off at the pass.]
  153.  
  154. [Author: POSIX must evolve a set of independent standards that have
  155. UNIX as their heritage. POSIX standards are all evolving as UNIX-like
  156. standards. Why discourage a vendor from implementing some subset of
  157. UNIX-like standards just because the vendor is not ready to provide a
  158. complete 1003.1 implementation? ]
  159.  
  160. January 1990 Standards Update                 IEEE 1003.0: POSIX Guide
  161.  
  162.  
  163.                                 - 4 -
  164.  
  165. Want to go to a POSIX meeting?
  166.  
  167. This was my first POSIX meeting.  In case you haven't been and are
  168. thinking of going, here are a couple of things you'll want to know.
  169.  
  170. New people and their new ideas, are welcomed.  As a practical matter,
  171. it helps to stick with a group for the entire week.  It's tough to
  172. understand much if you come into an advanced discussion, cold, It
  173. would help if each group summarized its purpose and listed the big
  174. issues at the beginning of each meeting, to get everyone in the proper
  175. frame of mind, but that doesn't always happen.  Still, you'll be
  176. granted a sort of first-time armor to protect you when you ask naive
  177. questions or need clarification.  For extra insurance, use the phrase
  178. ``I will take an action item...'' often.
  179.  
  180. January 1990 Standards Update                 IEEE 1003.0: POSIX Guide
  181.  
  182.  
  183. Volume-Number: Volume 19, Number 56
  184.  
  185.