Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.30/text0086.txt

Text File | 1993-03-11 | 15.8 KB | 328 lines

Submitted-by: [e-mail] (Stephen Walli)

                       Corwin's Razor
                      Stephen R. Walli
                     [e-mail]

In December, I wrote at length about a couple of fundamental
problems with  the  structure and  process  of defining  the
POSIX family  of standards.  POSIX  will collapse under  its
own structure if not rescued soon was the premise.[1] It was
motivated by  the  concern that  we  will lose the  existing
valuable model  for  portable applications  programming,  if
POSIX  continues along  its  current path.   These  concerns
settled  around  test  methods  requirements placed  on  the
working  groups,  and  language  independent  specifications
(LIS).

__________
1.  comp.std.unix,  Volume  29,   Number  86,  and  ;login:,
    January/February 1993.

It  provoked  some  people  to  do  the  net  equivalent  of
``writing to their congressman,'' and the email addresses at
the end of the article received some mail.  It also provoked
some discussion  on  the net,  which  is good, because  this
stuff is important  to you if you care about writing C, Ada,
and Fortran programs that are as portable as possible across
the widest possible set of architectures.  YOUR viewpoint is
important!  Ultimately, it  was a source  of a lot of debate
and discussion at  the IEEE POSIX meetings in January, which
is responsible for  developing these source code portability
standards.

One of the driving arguments in these discussions was who is
the customer for this work.  This sentiment is best embodied
by something  said  by Bill  Corwin,  the chair  of  POSIX.4
(Real-time extensions), which became:

  Corwin's Razor: If they're not willing to put their money
  where their mouth is, they're not a customer.

Let's see where it got us.

Test Method Madness -- Part II
==============================
I expressed  a  lot of  concern  with the  creation of  test
methods  standards.   These  are standards  containing  test
assertions,  based on  the  test methodologies  outlined  in
POSIX.3, which could  act as the  basis for a test suite.  I
was concerned about  the setting up  of a directly competing
body  of  text,  used  to  create  test  suites  to  measure
conformance of implementations of base standards, before the
base standard had even received wide spread implementation.

After the last editorial hit the net, I discovered something
which only fueled  my concerns.  The test methods which were
balloted as  part  of the XOM  (Object Management) API,  and
X.400 API (P1224 and P1224.1) received no comment in ballot.
Changes made to  the test methods were done by the technical
editor  during  ballot to  keep  them synchronized  as  best
possible  with  changes  made to  the  base API  text.   The
POSIX.17 (X.500  Directory  Services) test methods  received
very few comments  in ballot, in  relation to the  volume of
comments on the base API.

All three of these test methods standards are about to go to
the IEEE Standards  Board in March  for final approval.  One
might  think  that  their  test  methods weren't  read  very
carefully by the balloting group, which was concentrating on
balloting the base  API that it cared about.  Would you want
NIST to  choose  these standards as  the specification of  a
conformance test suite?

All three of  these documents had their test methods written
for them by a couple of contractors in the employ of X/Open.
X/Open wants  these base specifications  to get through  the
standardization process.  The  process demands there be test
methods for the  base documents to  exit ballot.  There  are
now test methods.   At least X/Open  was willing to  put its
money where its mouth is.  POSIX.10 (Supercomputing Profile)
has just  completed  its first  ballot  cycle, and no,  they
received no  ballot comments on  their test methods  section
either.

There is  an  example, however, of  a test methods  standard
that is, IMHO, a well-constructed standard.  POSIX.3.1 (IEEE
Std  2003.1-1992)  is  the  test  methods standard  for  the
POSIX.1 base functionality.  What's different about it:

-- It  lags  the original  standard  by four  years,  since
  POSIX.1  was  originally   approved  in  1988   (IEEE  Std
  1003.1-1988).

-- At least  four implementations of  real test suites  fed
  its creation.   (The NIST  PCTS, Perennial's POSIX.1  test
  suite, X/Open's  VSX,  built by  Unisoft, and  Mindcraft's
  CTS.)

-- People that wanted  to have a  standard for test methods
  to  measure conformance  to  POSIX.1 got  together  (i.e.,
  found  the  time  and  money) and  did  the hard  work  of
  defining, drafting, and balloting a document.

-- The document was  balloted separately and seriously by a
  group of people  that seriously cared about the outcome of
  the standard (i.e.,  the implementors of  the base POSIX.1
  standard), as well as the people that cared about having a
  standard test suite.

Many working groups that have written test methods for their
base functional definitions,  even just partially, feel that
their base specifications are stronger for the effort.  They
aren't  sure  whether  or  not  they've  written  good  test
methods.   They don't  care.   Their base  specification  is
better.  That's what they came together to do.

You can't legislate  a standard.  Especially from a group of
volunteers.   Just  because  one  group  of  people  want  a
standard ``test suite,''  does not mean  that the group that
originally got  together  to define and  draft and ballot  a
standard for some  base functionality wants  to do the extra
work of  defining,  drafting, and  balloting a test  methods
standard.  Corwin's Razor.

So  what  happened?   Most  of  the  Steering  Committee  on
Conformance Testing's (SCCT's)  discussions agreed that  the
market will speak.  If and when it cares about standards for
test methods, people will find the money and energy.

A motion was  made in the  Sponsor Executive Committee (SEC)
to  remove  the  testing  requirement  from  balloting  base
documents.  It was  modified to ``suspend'' the requirement.
It passed.  The SCCT will consider if there are alternatives
to the current  process, but until  such time as they report
back to the  SEC, the requirements placed on the wrong group
of people have been lifted.

It does not  mean POSIX considers  test methods standards to
be bad  things.  POSIX.3.1  stands as an  example of a  well
developed test  methods  standard.  It  also  does not  mean
POSIX doesn't care about building good documents.  Quite the
contrary.  A tool  exists, called ``writing  test methods,''
that working groups  can use, when and where appropriate, to
improve  the   clarity   and  preciseness   of  their   base
specification.   It  does  mean  that  the  POSIX  standards
working  groups  feel that  people  that want  test  methods
standards should go to the effort of building them.

LIS -- Again!
=============
The scope of  POSIX.1 says that  it is a  standard operating
system interface to  support applications portability at the
source code level.  It is to be used by systems implementors
and application developers.   This would tend to indicate it
should  be  a   readable  document.   It   is  the  official
``contract'' with which  an applications developer  can call
up their systems vendor and say ``this is supposed to behave
this way,'' or  vice versa.  Just  like the ANSI C standard.
Together, these two documents define an environment in which
to design  more portable applications,  written in C.   (The
Ada based POSIX.5 has similar statements in its scope.)

I raised  concerns  over the  structure  and format  of  the
programming-language-independent  specifications  method  of
defining POSIX  standards.   It takes  what  I believe is  a
useful single-book,  single-context format,  as used in  the
current C-based POSIX.1  and Ada-based POSIX.5, and makes it
hard to read  and harder to use by creating a two-book, two-
context standard.

The LIS debate  is far more political and emotional.  ISO is
involved.  The  ISO working  group responsible for  bringing
IEEE POSIX  documents  forward as  international  standards,
WG15,  requires  that  they  be  brought forward  as  thick,
semantic LI  specifications  with attendant thin,  syntactic
language bindings.

This requirement was  agreed to by  the U.S. member  body to
WG15, which passed  it on to the IEEE working groups back in
1988, which  also  agreed to  do  it.  Some  argue that  the
United States  is  not fulfilling  its  obligations if  they
don't follow the LIS approach.

This is just  plain wrong.  The  IEEE is the POSIX standards
development organization.  The  IEEE is a ``trans-national''
organization, open  to  all.  While  the IEEE POSIX  working
groups are  predominantly attended by  people living in  the
United States,  a  fair number  of  people hail  from  other
locations, and the  IEEE POSIX working groups have never not
entertained a  person's  point of  view.  They really  don't
care where you  live.  The ``U.S.  member body'' to  WG15 is
merely the  administrative  point between  the IEEE and  ISO
WG15.

The IEEE then spent a lot of time and effort, first defining
a methodology,  then  applying that  methodology where  they
could.   As  with  the  test-methods  tool,  working  groups
discovered holes  and  errors in  their  base text  as  they
reviewed it critically,  asking the question,  ``How would I
express  this  concept  such  that  I  could write  the  Ada
equivalent of it?''   Or Fortran.  They  discovered they can
more clearly  express  some of  the  meaning in  their  base
documents.

The people  most  able to  do  this work  in the IEEE  POSIX
working group's experience  were the people in POSIX.5 (Ada)
and POSIX.9  (Fortran).   They did  the painful exercise  of
critically  reading  the   text  of  C-based   POSIX.1,  and
recasting it into the words and programming semantics/syntax
of their own language.

The funny thing  is, they did  this without the benefit of a
language-independent specification of POSIX.1.  The only way
that the  POSIX.1/LIS  could be  created  was for  the  IEEE
Technical Committee on  Operating Systems to  open the purse
strings and pay a contractor to write the first drafts of an
LIS of POSIX.1 and its attendant C binding.

And these other  language groups, which pay money to come to
IEEE  POSIX  meetings  to  do  the  work of  building  POSIX
standards  in  their  own  language (which  they  understand
well), are concerned  with the current POSIX LIS methodology
being used and  the format of  the documents it produces.  I
think I hear Corwin's Razor being sharpened.

The POSIX.5 Ada working group built their version of POSIX.1
without  the  POSIX.1/LIS.  They  feel  it would  have  been
easier to build  their document if one had existed, but they
don't know what that LIS would have looked like.  They don't
particularly like the one that has been produced.

They further chose to ignore the ISO requirement of ``thin''
syntactic  bindings,  which  don't  reproduce  the  semantic
description of the ``thick'' base LIS document.  They wanted
their standard to  be self-contained and readable, such that
programmers would only  require the one  book on their desk.
Their  gamble  failed!  ISO  WG15  refused to  accept  their
standard for international standardization.

But wait!  ISO WG9, the ISO Ada language group wants to fast
track the  IEEE POSIX.5  standard.  They feel  it is a  good
standard.  So maybe their gamble didn't fail.

So who actually  benefits by presenting  the standard as  an
LIS?  Language-bindings writers  certainly.  But the  people
who already care  enough to participate seem to be doing so.
It doesn't take  a huge number of people to set up a working
group.  There were  only about twelve  in the Fortran  group
(POSIX.9).

So what  happened  at the  SEC?   A motion  came forward  to
remove  the  requirement  for  the  current  LIS  method  of
defining POSIX  standards.  It  was massaged into  something
considerably more diplomatic,  which passed, creating  an ad
hoc committee to  go investigate the  problem in detail, and
without  particular restrictions,  and  report back  at  the
April 1993 meetings.

This is a  good thing.  To  change the direction of POSIX at
this point is  not a trivial  task to be  taken lightly, nor
decided too quickly.   There will be ramifications no matter
what the outcome of the report from the ad hoc.

I chair  the ad  hoc.  If I  was going to  stir up all  this
fuss, then I  was going to  be made accountable for it :-) I
am interested in  your thoughts or concerns, so by all means
e-mail me.

There was  another  wonderful quote  that  came out  at  the
January meetings, that essentially said:

  ``Standards organizations that choose to make themselves
  irrelevant deserve what they get.''

This  was  actually   made  in  reference  to  a  completely
different problem,  but  I believe  it  is very  appropriate
here.  If we  make these standards  unusable, they won't  be
used.   We  will   lose  the  ``contract''  for  a  portable
programming  model   between  applications  developers   and
systems implementors.

I am repeating  the list of  email addresses from the end of
``POSIX -- Caving  in Under Its Own Weight.''  I believe it
is still important  that you make your concerns known to the
people that can actually make the decision about this.

                              IEEE Concerns
    Position                      Name                   E-mail

Chair SEC                        Jim Isaak          [e-mail]
Vice Chair Interpretations       Andrew Twigger     [e-mail]
Vice Chair Balloting             Lorraine Kevra     [e-mail]
Chair Comm on Conf Testing       Roger Martin       [e-mail]
Chair Project Management Comm    Shane McCarron     [e-mail]
Chair POSIX.1                    Paul Rabin         [e-mail]
Chair POSIX.2                    Hal Jespersen      [e-mail]
Chair POSIX.3                    Lowell Johnson     [e-mail]
Chair POSIX.4                    Bill Corwin        [e-mail]
Chair POSIX.5                    Jim Lonjers        [e-mail]
Chair POSIX.6                    Dennis Steinauer   [e-mail]
Chair POSIX.7                    Martin Kirk        [e-mail]
Chair POSIX.8                    Jason Zions        [e-mail]
Chair POSIX.9                    Michael Hannah     [e-mail]
Chair POSIX.12                   Bob Durst          [e-mail]
USENIX Institutional Rep         Jeff Haemer        [e-mail]
EurOpen IR                       Stephen Walli      [e-mail]
DECUS IR                         Loren Buhle        [e-mail]
OSF IR                           John Morris        [e-mail]
UNIX International IR            Shane McCarron     [e-mail]
X/Open IR                        Derek Kaufman      [e-mail]

                              WG15 Concerns

Convener WG15                    Jim Isaak          [e-mail]
US Head of Delegation            John Hill          [e-mail]
Canadian HoD                     Arnie Powell       [e-mail]
UK HoD                           David Cannon       [e-mail]
German HoD                       Ron Elliot         [e-mail]
Dutch HoD                        Herman Wegenaar    (phone: [phone])
Japanese HoD                     Nobuo Saito        [e-mail]
French HoD                       Jean-Michel Cornu  [e-mail]
Danish HoD                       Keld Simenson      [e-mail]
New Zealand HoD                  Keith Hopper       [e-mail]


Volume-Number: Volume 30, Number 87