home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / volume.23 / text0094.txt < prev    next >
Encoding:
Text File  |  1991-06-15  |  13.4 KB  |  266 lines

  1. Submitted-by: pc@hillside.co.uk (Peter Collinson)
  2.  
  3. An Update on UNIX-Related Standards Activities
  4. USENIX Standards Watchdog Committee
  5. Stephen R. Walli <stephe@usenix.org>, Report Editor
  6.  
  7.  
  8. April in Chicago
  9.  
  10. The April IEEE POSIX working groups was significant. The newly formed
  11. Project Management Committee enjoyed its first full working meeting. A
  12. new steering committee was formed to manage the thornier issues
  13. surrounding POSIX profiles. The long awaited first draft of a language
  14. independent specification of IEEE 1003.1-1990 was delivered for review
  15. and comment by interested working group members.  And of course the
  16. week was dominated with Sun MicroSystems's and UNIX Systems Labs's
  17. (USL) Open Look project request being put up against the Open Software
  18. Foundation OSF/Motif project request.
  19.  
  20. Project Management Committee
  21.  
  22. Chicago was the first working meeting of the newly formed Project
  23. Management Committee (PMC). The PMC monitors existing TCOS-SS projects
  24. and reviews new PARs (Project Authorization Requests). They use a
  25. mentoring process, whereby a member of the committee is assigned to
  26. each new PAR and each current working group. Each PMC member has
  27. several to track, because of the current number of projects.
  28.  
  29. Once a mentor is assigned a new PAR, they aid the PAR presenter in
  30. making sure it is properly formatted, and that all supporting
  31. documentation is present and complete. The point is to ensure that no
  32. PAR fails to be accepted by the TCOS-SS Sponsor Executive Committee
  33. (SEC) for documentation problems.
  34.  
  35. If the PAR is accepted, the mentor continues to monitor the project to
  36. ensure that it is on track.  A project that loses focus on the current
  37. scope would receive help to bring it back in line with its stated
  38. purpose. The PMC has no direct authority to mandate anything, however
  39. they can recommend that the SEC take certain actions.
  40.  
  41. Members of the PMC include: Jason Zions, Shane McCarron, Lorraine
  42. Kevra, Roger Martin, Derek Kaufman, Robert Bismuth, Don Cragun and Tim
  43. Baker.
  44.  
  45. The PMC covered a lot of ground in its first week, starting on Sunday
  46. afternoon. The competing project authorization requests (PARs) to
  47. create standards for the two major X interfaces were discussed.
  48. (Discussion of the competing PARs follows.)
  49.  
  50. The POSIX.2 (Shell and Utilities) working group had a new PAR
  51. proposed, POSIX.2b, which covered the reformatting of the POSIX.2 and
  52. POSIX.2a (User Portability Extension) documents, and the incorporation
  53. of new utilities. The new POSIX.2b PAR was changed so that only new
  54. extensions would be part of the PAR, and the document reformatting was
  55. left out. This means we won't have a two thousand page document
  56. arriving for ballot as POSIX.2b!  POSIX.7 (System Administration) was
  57. reviewed and recommendations made to separate it into several PARs
  58. under the same working group.  An additional PAR for 1224 to cover the
  59. Object Management API for X.400 and X.500 was recommended. The POSIX.4,
  60. POSIX.6 and POSIX.11 projects were also reviewed during the first week.
  61.  
  62. This committee will likely begin to have more and more effect on the
  63. building of POSIX as it becomes comfortable with its role. Its members
  64. are long-time POSIX people with considerable experience and I look
  65. forward to what they bring to the overall process with all of its
  66. current problems of co-ordination and synchronization.
  67.  
  68.  
  69. Par Wars
  70.  
  71. Competing X Window PARs dominated the Chicago meeting. A month before
  72. the Chicago meeting, the Open Software Foundation (OSF) submitted a
  73. PAR to the TCOS-SS SEC proposing a direct ballot of the OSF/Motif API
  74. Document and Style Guide.
  75.  
  76. These documents would be reformatted according to TCOS style guides if
  77. the PAR was accepted. Test assertions and Language Independent
  78. Specifications would be written at the OSF's expense if required. The
  79. legal copyright issues were arranged with the IEEE Standards Office.
  80. Sufficient industry acceptance and experience to make Motif a standard
  81. was claimed.
  82.  
  83. This forced the backers of Open Look to rush forward with a similar
  84. PAR, championed by Sun Microsystems and UNIX Systems Labs.  Similar
  85. claims of industry acceptance and experience were made, and similar
  86. reformatting, test assertions and LIS were promised. So the battle was
  87. joined once again.
  88.  
  89. There is significance to a direct ballot. POSIX standards are usually
  90. drafted by a working group who take base documents and create a new
  91. revised document.  This revised document is balloted, reviewed and
  92. made into a standard.
  93.  
  94. With a direct ballot, there is no working group formed to build a
  95. document through a consensus process, but a balloting group is formed
  96. directly.  In theory the document is ready to be shipped to balloters,
  97. which was not the case for either of these PARs. TCOS-SS has rules for
  98. creating standards this way, but no one has ever done it before.  The
  99. stage was set for a week of theatrics.
  100.  
  101. The first people to have to deal with the duel was the PMC.  They
  102. stuck to the letter of their mandate, and reviewed these PARs to
  103. ensure they were correctly formatted.  They also recommended that
  104. certain steering committees review them. The Steering Committee on
  105. Windowing User Interfaces (SCWUI) was an obvious reviewer.  (Yes, it's
  106. pronounced ``scwewy'', you wascally wabbit.) SCWUI stated that it did
  107. not want these PARs accepted because of the overlap with the current
  108. P1201.1 (Windowing Toolkit API) work.
  109.  
  110. The Steering Committee on Conformance testing (SCCT) was also asked
  111. for comment, and reported they had no concerns with either of them as
  112. stated.
  113.  
  114. One SC that was missed was the Distributed Services Steering Committee
  115. (DSSC) which came to light in the SEC discussions of the PARs.  The
  116. Sun/USL PAR characterizes Open Look as a distributed desktop paradigm,
  117. so DSSC should have an opportunity to comment on it.
  118.  
  119. The P1201.2 working group is building a Recommended Practice document
  120. for driving window based applications. The chair of this working group
  121. raised concerns that if either of these documents became standards
  122. before P1201.2 completes its work, it may conflict with it.
  123.  
  124. People discussed and debated all week in the hallways as to what would
  125. and should happen.  Many felt that both PARs should be accepted,
  126. pointing to the IEEE 802 LAN standards as an example.  Fortunately,
  127. many of the Europeans present were able to point out the problems with
  128. this, since they are currently living in a situation where many
  129. conforming implementations of OSI protocols cannot talk to one another
  130. because of such differences.  This destroys any hope of building very
  131. portable applications which have windowed interfaces, unless one is
  132. willing to only be portable within windowing environment ``A''.
  133.  
  134. Others felt that neither PAR should be accepted, pointing out that if
  135. P1201.1 (Windowing Toolkit API) has been deadlocked over this type of
  136. API for so long, perhaps there isn't sufficient industry consensus to
  137. create a standard.  This is extremely important. On a few occasions
  138. during the week I heard different people refer to the original POSIX
  139. work to build POSIX.1. These references came about during completely
  140. seperate discussions on conformance for language independent
  141. specifications and profiles. People talked about the way that the
  142. working group members laid aside their preferences for their
  143. particular flavours of UNIX in favour of building the standard. This
  144. does not appear to be happening in this arena.
  145.  
  146. Neither PAR could be accepted alone, since this would have disastrous
  147. commercial effects on the ``loser.'' This points out some of the
  148. problems of allowing vendors and vendor consortia to produce such
  149. documents for standardization. It has been successfully done in the
  150. past in other areas of technology, but it needs to be done with great
  151. care, and not in an environment of direct and blatant commercial
  152. competition.
  153.  
  154. The membership of the balloting groups for these PARs would be
  155. interesting to see. The IEEE has rules about the percentage of
  156. balloting group content that is vendor related, user related or
  157. ``general interest''. This has never been contested in the past.
  158. Likewise, ballot resolution of comments and objections would also be
  159. interesting, as the PAR presenters would be responsible for
  160. administering their own ballot resolution according to the PAR's
  161. scope. Somewhat like handing a pit bull terrier its own leash and
  162. telling it to walk itself without getting into a fight.
  163.  
  164. The SEC was forced into a painful discussion for a few hours on these
  165. PARs.  During part of the discussion, PAR presenters pointed out that
  166. if the TCOS-SS SEC refused the issue, there was still a court of final
  167. appeal, being the IEEE Standards Board itself.
  168.  
  169. Fortunately, Paul Borrill was present. Paul is the vice-president for
  170. standards in the IEEE Computer Society, and a member of the IEEE
  171. Standards Board.  Paul didn't have a lot to say, but his points were
  172. clearly made. First, he encouraged the groups to fix their own
  173. problems.  Second, he reminded them who sets the rules, if people
  174. chose to bend or abuse them. (The IEEE Standards Board!) Points taken.
  175.  
  176. In the end, the discussion was halted with a flurry of Robert's Rules
  177. procedural magic.  The Rules are used as a way to ensure that work is
  178. accomplished in a committee forum and that all participants have fair
  179. opportunity to be heard.  The SEC resolved that it ``does not feel at
  180. this time that it should sponsor either the Modular Toolkit
  181. Environment PAR (Motif) or the Open Toolkit Environment PAR.  (Open
  182. Look)''
  183.  
  184. The PARs are in procedural limbo, By that hour, the SEC was only too
  185. happy to kill discussion of the PARs.  The PARs have not been
  186. ``tabled'', ``withdrawn'', or ``postponed''.  They are still very real
  187. and I fear that the Santa Clara meeting will have these PAR presenters
  188. haunting the hallways, singing ``weee're baaaack....''
  189.  
  190. Profiles! Get your Profiles!
  191.  
  192. For quite some time now, profiles have been a great source of
  193. confusion in the POSIX world. Ask ten different people from ten
  194. different areas what a POSIX profile is, and you will indeed receive
  195. ten different answers. There is a list of serious outstanding issues
  196. on defining, co-ordinating and standardizing POSIX profiles, which has
  197. been built up by the working group on the POSIX Guide (P1003.0) and
  198. current profile writing groups.
  199.  
  200. They have long felt that some form of managing group needed to take
  201. charge of these issues.  After much (circular) discussion as to the
  202. nature of this committee (is it a rapporteur group, an ad hoc group or
  203. a steering committee) it was finally decided that a steering committee
  204. was required to deal with the management issues of profiles. The SEC
  205. ratified this decision and the Profiles Steering Committee was born.
  206.  
  207. Bob Gambrel is the chair of the Profiles Steering Committee, and each
  208. working group with a profile project also has representation.  The
  209. group held its first organizational meeting the next day and by the
  210. time Santa Clara rolls around, the committee's work will be well
  211. underway.
  212.  
  213. LIS POSIX.1
  214.  
  215. A first draft language independent specification of POSIX.1 (System
  216. Application Program Interface) was delivered this week. Language
  217. Independence is an issue raised by ISO who wish standards to be
  218. unrelated to a particular programming language.
  219.  
  220. In January, the SEC formed a subcommittee to solicit and evaluate
  221. submissions to produce a complete POSIX.1 language independent
  222. specification (LIS).  Monies were put forward by the IEEE Computer
  223. Society, the contract was awarded and the work was done.
  224.  
  225. The completed first draft language independent specification of
  226. POSIX.1 (to IEEE 1003.1-1990) and a near complete draft C language
  227. binding (POSIX.16) were presented at the LIS BOF on Monday afternoon.
  228. BOF attendees raised concerns that input on certain language
  229. indendence issues raised over the last few working group meetings may
  230. not be completely reflected in the drafts, but the drafts were
  231. generally well received.  Copies were in such high demand that the
  232. rules for making document copies at meetings had to be changed to
  233. prevent further drafts from being produced.
  234.  
  235. This work is significant. A concrete example of a near complete LIS of
  236. POSIX.1 now exists. Other working groups can use it as an example in
  237. much the same way that POSIX.3.1 (Test Methods for POSIX.1) is an
  238. example of how to construct and structure test assertions.  Many
  239. working groups point to the functionality described in POSIX.1, and it
  240. was unclear how their LIS would need to be structured to point to an
  241. LIS version of POSIX.1. These issues can now be addressed and the
  242. language indendence requirements on the POSIX standards process can
  243. move forward with more confidence.
  244.  
  245. ISO's working group 15 (WG15) on POSIX requested that language
  246. bindings to the POSIX standards come forward as ``thin'' bindings to
  247. the LIS documents. Thin bindings indicate that there is no significant
  248. duplication of semantic content between the LIS and the language
  249. binding.  Because of this request, the POSIX.5 (Ada Binding) and
  250. POSIX.9 (FORTRAN-77 Binding) working groups are not proceeding at the
  251. international level at this time.
  252.  
  253. Both of these groups are balloting their documents at the IEEE level
  254. and are busy resolving ballot objections. Both of these groups have
  255. language standards groups reviewing their respective programming
  256. languages, with a view to significantly changing them.  The groups
  257. feel they can better serve the industry by waiting until the POSIX.1
  258. LIS and the changing language standards stabilize, and then produce
  259. the documents which will be forwarded to the international level for
  260. standardization.  In the meantime, IEEE standard bindings will exist
  261. for Ada and FORTRAN-77 to the C based POSIX.1 standard.
  262.  
  263.  
  264. Volume-Number: Volume 23, Number 94
  265.  
  266.