home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.28 / text0031.txt < prev    next >
Encoding:
Text File  |  1992-08-17  |  4.9 KB  |  110 lines
  1. Submitted-by: stephe@usenix.org (Stephen R. Walli)
  2.  
  3. Peter Collinson <pc@hillside.co.uk> reports on the April 8- 12, 1992
  4. meeting in Dallas, TX:
  5.  
  6. [Ed. - Peter is the USENIX Institutional Representative to TCOS-SS,
  7. the IEEE group responsible for drafting the POSIX family of standards.]
  8.  
  9. Overview
  10.  
  11. Theoretically, I spent most of the week in POSIX.1, the working group
  12. for the ``original'' system interface standard. It's still meeting
  13. because it has several extant projects:
  14.  
  15.    - POSIX.1LIS, programming language independent POSIX.1;
  16.  
  17.    - POSIX.16, the C binding to POSIX.1LIS;
  18.  
  19.    - POSIX.1a, the place where bug fixes and new features
  20.      for POSIX.1 are being put while the language
  21.      independence work is being done;
  22.  
  23.    - POSIX.18, the POSIX Environment Profile. It's a
  24.      profile (or list of other standards) intended to
  25.      describe something close to a complete UNIX system.
  26.  
  27. I tend only to attend the work for the first of these because I also
  28. go to many other steering committee meetings. Here's an idea of what
  29. happened in the bits that I managed to get to ....
  30.  
  31. The Report...
  32.  
  33. The ISO standards working group on POSIX, WG15, requires that the IEEE
  34. POSIX working groups produce a programming language independent
  35. version of the existing POSIX.1 standard (ISO 9945-1). This language
  36. independent specification (LIS) is referred to as POSIX.1LIS.
  37.  
  38. The POSIX.1 standard has been re-cast in two sections: the language
  39. independent specification and a C language binding (POSIX.16). The
  40. idea is that these two should ballot together, so that balloters can
  41. compare the original standard with the new pairing.
  42.  
  43. It's planned now that the two standards will go to ballot on July
  44. 7th. This has been made possible because:
  45.  
  46.    - the documents are close to being ready, have been mock balloted
  47.      and finally preened by the working group,
  48.  
  49.    - the Steering Committee on Conformance Testing (SCCT) has agreed
  50.      that the documents do not need a completely new set of test
  51.      methods written for them. They can use the already existing test
  52.      methods for POSIX.1, contained in POSIX.3.1, which has nearly
  53.      completed balloting.
  54.  
  55. Not needing new test methods is a great concession because it avoids
  56. the rules that insists on test methods being available for all new
  57. standards before they go to ballot. In my opinion, someone will need
  58. to find some funding to get the new test methods written. There is no
  59. enthusiasm for doing this in the working group. This is also the
  60. consensus of the group, when asked just that question.
  61.  
  62. What are test methods?  That's a little hard to explain. Basically,
  63. they are terse English statements that assert facts about the
  64. standard. The idea is that these are easier to convert into programs
  65. that actually test the interfaces. Each assertion is classified as
  66. ``testable'' or ``not testable'', and whether or not it applies to
  67. optional behaviour. It's a little more complex than this. Look at
  68. POSIX.3, (IEEE Std. 1003.3-1991,) the standard for test methodologies
  69. for POSIX, for more information.
  70.  
  71. The current document drafts are based on the ordering in 9945-1. This
  72. is good because sections in all the documents refer to the same
  73. material. If you are looking at Section 3.2.1 in 9945-1:1990, then
  74. the same material will be found in the same numbered section in
  75. POSIX.1LIS and POSIX.16.
  76.  
  77. A small group of people who are close to the document: the editor (Hal
  78. Jesperson), the person really running the LIS project (Paul Rabin from
  79. the OSF) and the chair of the POSIX.1 Working Group (Donn Terry) have
  80. realised that this is POSITIVELY THE LAST CHANCE to change the
  81. ordering of the document. [Ed. - the close() and open() functions are
  82. in different chapters of the standard, as an example.]
  83.  
  84. Donn has come up with a potential re-ordering and this will be applied
  85. to the new documents. I was concerned that this would make balloting
  86. difficult, because we lose the ability to easily cross reference. The
  87. idea is to print a re- ordered version of 9945-1 (without rationale)
  88. to act as a balloter's aid.
  89.  
  90. The two new documents will also contain ``other editorial changes''.
  91. The adoption of the LIS has meant that the original text has been
  92. inspected very closely indeed, and has been found wanting in many
  93. places. It's often ambiguous with unclear wording. The text has been
  94. tightened up in these places. One of the tasks of the working group
  95. this week has been to examine a list of lines containing ``may'',
  96. ``can'', ``cannot'', ``system defined'' and some other words to ensure
  97. that they are all used consistently throughout the documents. Where
  98. ambiguities exist the wording has been repaired.
  99.  
  100. Now, you may argue that this will change the sense of the document and
  101. it might. It will be up to the balloting group to worry about that.
  102. There are NO conscious changes.
  103.  
  104. New functionality and real bug fixes have been held over in POSIX.1a.
  105. There was no discussion on this during the week, because the person
  106. driving that, Roy McKean from X/Open, was unable to be in Dallas.
  107.  
  108. Volume-Number: Volume 28, Number 33
  109.  
  110.