From derek@knosof.uucp Sun Aug 7 17:53:32 1994 Received: from eros.Britain.EU.net by dkuug.dk with SMTP id AA06648 (5.65c8/IDA-1.4.4j for ); Sun, 7 Aug 1994 17:53:32 +0200 Received: from pyra.co.uk by eros.britain.eu.net with UUCP id ; Sun, 7 Aug 1994 16:51:12 +0100 Received: by knosof.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA04339; Sun, 7 Aug 94 16:48:13 BST Date: Sun, 7 Aug 94 16:48:13 BST From: derek@knosof.uucp (Derek M Jones) Message-Id: <9408071548.AA04339@knosof.UUCP> To: wg15@pyra.co.uk Subject: Applications testing X-Charset: ASCII X-Char-Esc: 29 All, >Date: Wed, 3 Aug 94 23:51:31 EDT >From: stephe@mks.com (Stephen Walli) > >dmj> srw> >dmj> srw> As a customer of an application, I would like to know that: >dmj> srw> -- it runs on every platform upon which I wish to install it. >dmj> ... >dmj> >dmj> But can you say today what platforms you will be interested in tomorrow. >No. I don't know what will be available tomorrow. >I would like to think they provide a POSIX.1 interface and an ISO C >compiler and libraries. That will help protect my current application >development investment as much as possible, without guarantees. >As an ISV, I probably do not have sufficient buying clout personnally >with the hardware vendors to ensure they will continue to support standards >of interest to me. (There are very few ISVs such as Lotus, with sufficient >SELLING clout to call the shots.) >As a large MIS shop, or better yet, HUGE procurement concern, I probably >have better clout with my hardware vendors. > Who is the customer and what are they buying? A customer buying source is likely to be very interested in standards conformance. After all they are likely to be porting and maintaining (or paying somebody else to do it) their purchase. Customers buying binaries are unlikely to be that interested in the standards conformance of the source code. It is somebody else's problem. Knowing that the source conforms to standards will create a warm feeling in some people, but they are unlikely to be willing to pay much for it. >dmj> Software vendors showing some level of proof of conformance to >dmj> POSIX are likely to have fewer porting problems than those who don't >dmj> investigate the issues. > >``Some level of proof of conformance to POSIX'' worries me. >Which ``POSIX''? And with which conformance options? And >with which functional options? And how does one distinguish? Which ever bits of Posix are required. One useful side effect of checking applications is that it hightlights those optional parts of Posix that are used. My customers then feed this information back to their hardware procurement people (it also acts as a useful handle for management to control what the developers are assuming will exist on all platforms). > >Many useful applications will make use of features beyond >IEEE Std 1003.1-1990 as described by FIPS 151-2 (which I use as >a convenient short-hand for all the conformance options and specified >limits.) This means that were one to be able to test the model >used by an application suite, it would likely test as a ``conforming >application with extensions''. Okay. What extensions? Are they also >ISO or IEEE standards, possibly completely unrelated to POSIX in >functionality because they are embedded SQL, or a GUI toolkit? >Or are they a proprietary service, or a completely different industry spec? > Exactly, what options? An important part of the conformance checking process is the uncovering and documentation of these options. >dmj> >dmj> So why does POSIX go to such lengths to define the concept of >dmj> applications conformance? Given that most vendors claim some sort >dmj> of conformance to standards this issue of obviously important. > >I disagree. I'm not sure how obvious it is. Clause 1.3.2 "Applications Conformance" is on page 4. >I have not seen people claim conformance for their applications w.r.t. >POSIX.1, only implementations. (I appreciate that this probably reflects >more on my lack of reading of trendy magazines lately. If people >have seen such claims, I would genuiely like to see them itemized, >i.e. who, what, and where.) ... They usually use the blanket term Posix. What you need to do is talk to software developers and ask them simple questions in a non threatening way, like; what standards does your application conform to (I would not waste my time asking this question of people in the DOS world)? >dmj> >dmj> srw> >dmj> srw> POSIX.1 is an excellent base for a portability model, >dmj> srw> used in conjunction with ANSI/ISO C. One can even write useful and >dmj> srw> interesting applications using just these two standards. >dmj> srw> One will likely want to expand their model to include specifications >dmj> srw> (standard or otherwise) for a GUI API, possibly a GUI look-and-feel, >dmj> srw> and a network IPC mechanism. This immediately puts the >dmj> srw> application at odds with just POSIX.1 and its amendments, >dmj> srw> with respect to applications conformance. >dmj> >dmj> The existing POSIX conformance model handles this situation. > >I'm not sure how. I've read what I believe are the appropriate sections >of the standard. Please point me to the text and how it helps. > Clause 1.3.2.3 "Conforming POSIX.1 Applications Using Extensions" Why are you so against the testing of applications? Like most standards activities only those that are interested in it need be involved. In terms of industrial take, conformance certification will take to battle it out with other user requirements. At the moment there are a number of large organisations who want some form of applications certification. The Portable Applications Standards Committee ought to be responding to this need. derek