Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/volume.30/text0014.txt

Text File | 1993-03-11 | 3.8 KB | 78 lines

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

In <[e-mail]> [e-mail] (Chuck Karish) writes:

Thank you for taking the time to comment, but I believe I disagree with
your comments.

>In article <[e-mail]> [e-mail] (Stephen Walli) writes:
>>To give a real example: POSIX.4 (Real-time Extensions to POSIX.1) is almost
>>done. It will go in front of the IEEE Standards Board in June. There are no
>>test methods.
>>....
>Remember that a lot of the functionality in POSIX.4 is invented,
>either extending what's in existing implementations or specifying
>the behavior differently.
>It will be even more important for this standard than for POSIX.1
>and POSIX.2 to have agreed-upon test methods.

Why? I fail to see the connection between the above two paragraphs.  If
a lot of POSIX.4 *is* invented, then I would be *real* scared of
trusting them to get the test method specification correct without the
benefit of real implementations of the base standard upon which to cut
real test suites. I would hope that large procurement groups such as
the U.S. government would never choose so naive a specification for
testing for a possible FIPS of POSIX.4.

>The fact that the IEEE Standards Board won't publish the standard yet
>does nothing to prevent OS vendors from implementing the C binding,
>and thus has little effect on the individual programmer's ability to
>use its features.

I disagree. VMS implemented to POSIX.4/Draft 9. QNX has implemented a
few chapters out of Draft 9 as well, (I think.) I'm not sure how
current Lynx is. There is at least one other vendor I know of,
implementing to Draft 10. The sooner the working group's work is done,
the sooner the IEEE Standards Board can approve it, and the sooner the
IEEE can publish it.  Until then, there is no definitive reference for
a programmer to follow or brow beat a vendor.

>The tradeoff, from the programmer's point of view,
>is that the sooner test methods are agreed upon, the sooner it will
>be possible to write portable code that can be expected to work on
>all POSIX.4 systems that support the applicable option(s).

Again I ask, why?  The sooner the POSIX.4 *standard* exists, the sooner
a programmer can write portable code. Test methods *standards* do not
matter.  The only organizations that seem to really care about test
methods *standards* are large governmental procurement agencies.
Testing is expensive. They don't have the money to develop the suites
in house anymore, in these recessionary times.

There is nothing preventing them when they are evaluating possible
suites to test conformance to a standard, from laying down the criteria
that the suites document individual test cases according to the grammar
laid out in POSIX.3 (Test Methodologies for POSIX Standards), and that
they report status accordingly.  This would give them a basis for
judging test suites, one against the other.  They could even request
that individual test cases are tagged with some sort of
Section.subsection.page.line# identifier, and the quoted text from the
base standard, so someone could go through the standard with a
high-liter, (crude as this may seem,) to check for coverage.  They will
likely get a better suite, if they have more than one real suite to
judge against, than by asking the standards working groups to second
guess what a test suite will look like. Or they can pay the testing
houses like Mindcraft, Unisoft, Datafocus, and Perennial to develop the
suites in this manner. This is not work that should be hoisted onto the
standards development working groups any longer.

cheers,
stephe
--
Stephen R. Walli,       [e-mail] | Just say ``NO'' to anticipatory
Mortice Kern Systems Inc.              | standards.
phone: [phone]               |

Volume-Number: Volume 30, Number 15