home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: pc@hillside.co.uk (Peter Collinson)
-
- An Update on UNIX-Related Standards Activities
- USENIX Standards Watchdog Committee
- Stephen R. Walli <stephe@usenix.org>, Report Editor
-
-
- April in Chicago
-
- The April IEEE POSIX working groups was significant. The newly formed
- Project Management Committee enjoyed its first full working meeting. A
- new steering committee was formed to manage the thornier issues
- surrounding POSIX profiles. The long awaited first draft of a language
- independent specification of IEEE 1003.1-1990 was delivered for review
- and comment by interested working group members. And of course the
- week was dominated with Sun MicroSystems's and UNIX Systems Labs's
- (USL) Open Look project request being put up against the Open Software
- Foundation OSF/Motif project request.
-
- Project Management Committee
-
- Chicago was the first working meeting of the newly formed Project
- Management Committee (PMC). The PMC monitors existing TCOS-SS projects
- and reviews new PARs (Project Authorization Requests). They use a
- mentoring process, whereby a member of the committee is assigned to
- each new PAR and each current working group. Each PMC member has
- several to track, because of the current number of projects.
-
- Once a mentor is assigned a new PAR, they aid the PAR presenter in
- making sure it is properly formatted, and that all supporting
- documentation is present and complete. The point is to ensure that no
- PAR fails to be accepted by the TCOS-SS Sponsor Executive Committee
- (SEC) for documentation problems.
-
- If the PAR is accepted, the mentor continues to monitor the project to
- ensure that it is on track. A project that loses focus on the current
- scope would receive help to bring it back in line with its stated
- purpose. The PMC has no direct authority to mandate anything, however
- they can recommend that the SEC take certain actions.
-
- Members of the PMC include: Jason Zions, Shane McCarron, Lorraine
- Kevra, Roger Martin, Derek Kaufman, Robert Bismuth, Don Cragun and Tim
- Baker.
-
- The PMC covered a lot of ground in its first week, starting on Sunday
- afternoon. The competing project authorization requests (PARs) to
- create standards for the two major X interfaces were discussed.
- (Discussion of the competing PARs follows.)
-
- The POSIX.2 (Shell and Utilities) working group had a new PAR
- proposed, POSIX.2b, which covered the reformatting of the POSIX.2 and
- POSIX.2a (User Portability Extension) documents, and the incorporation
- of new utilities. The new POSIX.2b PAR was changed so that only new
- extensions would be part of the PAR, and the document reformatting was
- left out. This means we won't have a two thousand page document
- arriving for ballot as POSIX.2b! POSIX.7 (System Administration) was
- reviewed and recommendations made to separate it into several PARs
- under the same working group. An additional PAR for 1224 to cover the
- Object Management API for X.400 and X.500 was recommended. The POSIX.4,
- POSIX.6 and POSIX.11 projects were also reviewed during the first week.
-
- This committee will likely begin to have more and more effect on the
- building of POSIX as it becomes comfortable with its role. Its members
- are long-time POSIX people with considerable experience and I look
- forward to what they bring to the overall process with all of its
- current problems of co-ordination and synchronization.
-
-
- Par Wars
-
- Competing X Window PARs dominated the Chicago meeting. A month before
- the Chicago meeting, the Open Software Foundation (OSF) submitted a
- PAR to the TCOS-SS SEC proposing a direct ballot of the OSF/Motif API
- Document and Style Guide.
-
- These documents would be reformatted according to TCOS style guides if
- the PAR was accepted. Test assertions and Language Independent
- Specifications would be written at the OSF's expense if required. The
- legal copyright issues were arranged with the IEEE Standards Office.
- Sufficient industry acceptance and experience to make Motif a standard
- was claimed.
-
- This forced the backers of Open Look to rush forward with a similar
- PAR, championed by Sun Microsystems and UNIX Systems Labs. Similar
- claims of industry acceptance and experience were made, and similar
- reformatting, test assertions and LIS were promised. So the battle was
- joined once again.
-
- There is significance to a direct ballot. POSIX standards are usually
- drafted by a working group who take base documents and create a new
- revised document. This revised document is balloted, reviewed and
- made into a standard.
-
- With a direct ballot, there is no working group formed to build a
- document through a consensus process, but a balloting group is formed
- directly. In theory the document is ready to be shipped to balloters,
- which was not the case for either of these PARs. TCOS-SS has rules for
- creating standards this way, but no one has ever done it before. The
- stage was set for a week of theatrics.
-
- The first people to have to deal with the duel was the PMC. They
- stuck to the letter of their mandate, and reviewed these PARs to
- ensure they were correctly formatted. They also recommended that
- certain steering committees review them. The Steering Committee on
- Windowing User Interfaces (SCWUI) was an obvious reviewer. (Yes, it's
- pronounced ``scwewy'', you wascally wabbit.) SCWUI stated that it did
- not want these PARs accepted because of the overlap with the current
- P1201.1 (Windowing Toolkit API) work.
-
- The Steering Committee on Conformance testing (SCCT) was also asked
- for comment, and reported they had no concerns with either of them as
- stated.
-
- One SC that was missed was the Distributed Services Steering Committee
- (DSSC) which came to light in the SEC discussions of the PARs. The
- Sun/USL PAR characterizes Open Look as a distributed desktop paradigm,
- so DSSC should have an opportunity to comment on it.
-
- The P1201.2 working group is building a Recommended Practice document
- for driving window based applications. The chair of this working group
- raised concerns that if either of these documents became standards
- before P1201.2 completes its work, it may conflict with it.
-
- People discussed and debated all week in the hallways as to what would
- and should happen. Many felt that both PARs should be accepted,
- pointing to the IEEE 802 LAN standards as an example. Fortunately,
- many of the Europeans present were able to point out the problems with
- this, since they are currently living in a situation where many
- conforming implementations of OSI protocols cannot talk to one another
- because of such differences. This destroys any hope of building very
- portable applications which have windowed interfaces, unless one is
- willing to only be portable within windowing environment ``A''.
-
- Others felt that neither PAR should be accepted, pointing out that if
- P1201.1 (Windowing Toolkit API) has been deadlocked over this type of
- API for so long, perhaps there isn't sufficient industry consensus to
- create a standard. This is extremely important. On a few occasions
- during the week I heard different people refer to the original POSIX
- work to build POSIX.1. These references came about during completely
- seperate discussions on conformance for language independent
- specifications and profiles. People talked about the way that the
- working group members laid aside their preferences for their
- particular flavours of UNIX in favour of building the standard. This
- does not appear to be happening in this arena.
-
- Neither PAR could be accepted alone, since this would have disastrous
- commercial effects on the ``loser.'' This points out some of the
- problems of allowing vendors and vendor consortia to produce such
- documents for standardization. It has been successfully done in the
- past in other areas of technology, but it needs to be done with great
- care, and not in an environment of direct and blatant commercial
- competition.
-
- The membership of the balloting groups for these PARs would be
- interesting to see. The IEEE has rules about the percentage of
- balloting group content that is vendor related, user related or
- ``general interest''. This has never been contested in the past.
- Likewise, ballot resolution of comments and objections would also be
- interesting, as the PAR presenters would be responsible for
- administering their own ballot resolution according to the PAR's
- scope. Somewhat like handing a pit bull terrier its own leash and
- telling it to walk itself without getting into a fight.
-
- The SEC was forced into a painful discussion for a few hours on these
- PARs. During part of the discussion, PAR presenters pointed out that
- if the TCOS-SS SEC refused the issue, there was still a court of final
- appeal, being the IEEE Standards Board itself.
-
- Fortunately, Paul Borrill was present. Paul is the vice-president for
- standards in the IEEE Computer Society, and a member of the IEEE
- Standards Board. Paul didn't have a lot to say, but his points were
- clearly made. First, he encouraged the groups to fix their own
- problems. Second, he reminded them who sets the rules, if people
- chose to bend or abuse them. (The IEEE Standards Board!) Points taken.
-
- In the end, the discussion was halted with a flurry of Robert's Rules
- procedural magic. The Rules are used as a way to ensure that work is
- accomplished in a committee forum and that all participants have fair
- opportunity to be heard. The SEC resolved that it ``does not feel at
- this time that it should sponsor either the Modular Toolkit
- Environment PAR (Motif) or the Open Toolkit Environment PAR. (Open
- Look)''
-
- The PARs are in procedural limbo, By that hour, the SEC was only too
- happy to kill discussion of the PARs. The PARs have not been
- ``tabled'', ``withdrawn'', or ``postponed''. They are still very real
- and I fear that the Santa Clara meeting will have these PAR presenters
- haunting the hallways, singing ``weee're baaaack....''
-
- Profiles! Get your Profiles!
-
- For quite some time now, profiles have been a great source of
- confusion in the POSIX world. Ask ten different people from ten
- different areas what a POSIX profile is, and you will indeed receive
- ten different answers. There is a list of serious outstanding issues
- on defining, co-ordinating and standardizing POSIX profiles, which has
- been built up by the working group on the POSIX Guide (P1003.0) and
- current profile writing groups.
-
- They have long felt that some form of managing group needed to take
- charge of these issues. After much (circular) discussion as to the
- nature of this committee (is it a rapporteur group, an ad hoc group or
- a steering committee) it was finally decided that a steering committee
- was required to deal with the management issues of profiles. The SEC
- ratified this decision and the Profiles Steering Committee was born.
-
- Bob Gambrel is the chair of the Profiles Steering Committee, and each
- working group with a profile project also has representation. The
- group held its first organizational meeting the next day and by the
- time Santa Clara rolls around, the committee's work will be well
- underway.
-
- LIS POSIX.1
-
- A first draft language independent specification of POSIX.1 (System
- Application Program Interface) was delivered this week. Language
- Independence is an issue raised by ISO who wish standards to be
- unrelated to a particular programming language.
-
- In January, the SEC formed a subcommittee to solicit and evaluate
- submissions to produce a complete POSIX.1 language independent
- specification (LIS). Monies were put forward by the IEEE Computer
- Society, the contract was awarded and the work was done.
-
- The completed first draft language independent specification of
- POSIX.1 (to IEEE 1003.1-1990) and a near complete draft C language
- binding (POSIX.16) were presented at the LIS BOF on Monday afternoon.
- BOF attendees raised concerns that input on certain language
- indendence issues raised over the last few working group meetings may
- not be completely reflected in the drafts, but the drafts were
- generally well received. Copies were in such high demand that the
- rules for making document copies at meetings had to be changed to
- prevent further drafts from being produced.
-
- This work is significant. A concrete example of a near complete LIS of
- POSIX.1 now exists. Other working groups can use it as an example in
- much the same way that POSIX.3.1 (Test Methods for POSIX.1) is an
- example of how to construct and structure test assertions. Many
- working groups point to the functionality described in POSIX.1, and it
- was unclear how their LIS would need to be structured to point to an
- LIS version of POSIX.1. These issues can now be addressed and the
- language indendence requirements on the POSIX standards process can
- move forward with more confidence.
-
- ISO's working group 15 (WG15) on POSIX requested that language
- bindings to the POSIX standards come forward as ``thin'' bindings to
- the LIS documents. Thin bindings indicate that there is no significant
- duplication of semantic content between the LIS and the language
- binding. Because of this request, the POSIX.5 (Ada Binding) and
- POSIX.9 (FORTRAN-77 Binding) working groups are not proceeding at the
- international level at this time.
-
- Both of these groups are balloting their documents at the IEEE level
- and are busy resolving ballot objections. Both of these groups have
- language standards groups reviewing their respective programming
- languages, with a view to significantly changing them. The groups
- feel they can better serve the industry by waiting until the POSIX.1
- LIS and the changing language standards stabilize, and then produce
- the documents which will be forwarded to the international level for
- standardization. In the meantime, IEEE standard bindings will exist
- for Ada and FORTRAN-77 to the C based POSIX.1 standard.
-
-
- Volume-Number: Volume 23, Number 94
-
-