From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,FROM_WORDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,66752102482bbdca X-Google-Attributes: gid103376,public From: "Ken Garlington" Subject: Re: Required Metrics Date: 2000/05/07 Message-ID: X-Deja-AN: 620187330 References: <5DDO4.2237$wb7.194854@news.flash.net> <8ek4ea$5ta$1@nnrp1.deja.com> <390DC8AD.59B5EBEE@averstar.com> <8ep0k3$jlr$1@nnrp1.deja.com> <8es5fv$4ov$1@nnrp1.deja.com> <_HnQ4.7884$wb7.550012@news.flash.net> <8eukm0$ssm$1@nnrp1.deja.com> <8f26s6$lrj$1@nnrp1.deja.com> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Complaints-To: abuse@flash.net X-Trace: news.flash.net 957678566 216.215.86.137 (Sun, 07 May 2000 00:49:26 CDT) Organization: FlashNet Communications, http://www.flash.net X-MSMail-Priority: Normal NNTP-Posting-Date: Sun, 07 May 2000 00:49:26 CDT Newsgroups: comp.lang.ada Date: 2000-05-07T00:00:00+00:00 List-Id: "Robert Dewar" wrote in message news:8f26s6$lrj$1@nnrp1.deja.com... > > Do you think it's fair to accuse me of such an accusation, > > when the quoted statement doesn't actually say that? > > Yes, I think it's fair, reread what you said. > > > Like I said, "with a pen in the hand, and a song in the > > heart." > > Nope! No "song in the heart", which I take to mean with an > intent other than a formal declaration. Perhaps you have > some other meaning, if so, it is obscure to me. I do have some other meaning, and apparently it is obscure to you (even though you quote its meaning in the following): > > Of course, > > your signature is based on your determination as to which > requirements are > > "real" requirements, believing that all other requirements are > "met" no > > matter what. > > All requirements are requirements. I am not saying that the > documentation requirements are not requirements, just that > they are trivially met. or vacuously met, to quote previous posts? as in: "all other requirements are 'met' no matter what"? Perhaps you have some meaning for vacuous or trivial that is obscure to me! > > You may believe that the ACVC review board, and all other > > vendors, agree with you. > > You mean I agree that there can be no formal tests for whether > you meet the documentation rquirements. I cannot imagine anyone > with any reasonable knowledge thinking otherwise. No, I mean that you may believe that the ACVC review board agrees with you, based on your statement in a previous post: "By the way, the ACVC review board discussed this briefly. They immediately agreed that these requirements were too ill-defined to even consider including them in conformance assessment." Isn't it at least possible that I simply mean what I say? > There is no list of non-requirements, because there are no > non-requirements. THe DOC requires that you have not made > any intentional deviations from the FULL SET of requirements, > including the documentation requirements. > > > You might want to re-read your original statement: "How can > the DOC be > > signed if you have ignored a requirement?" Note that the word > > "intentionally" does not appear. > > intentionally is of course critical. Otherwise the DOC would > be a declaration that your compiler was bug free. This is not > intended, and would be impractical. That's right. You can sign the DOC "with a pen in the hand and a song in the heart", and still make an unintentional mistake. Perhaps, even, a certain kind of unintentional mistake relevant to the topic at hand. And yet, the meaning of my statement above still eludes you. Unfortunate, but there's no point in banging my head against that wall any further. > > > Nope, the issues with pragma Reviewable are also all > > > documentation based, let's look: > > > > Yes, let's. Specifically, let's look at the words which appear > just before > > paragraph 5: > > > > ***** Implementation Requirements ***** > > > > "5 The implementation shall provide the following information > ..." > > > > Now, I suspect you're using the term "documentation" > informally, not in the > > sense of ARM 1.1.2. However, since all Implementation > Requirements, like all > > Documentation Requirements, are not really requirements, > perhaps we _should_ > > use the same name for both. > > Of course implementation requirements are requirements, what > gave you the lunatic idea that this is not the case. I say > lunatic here, because it simply makes no sense. There are many > critical implentation requirements. Where ON EARTH did you > get this idea, certainly not from anything I wrote. Except for the bit you quoted from your earlier post: "Nope, the issues with pragma Reviewable are also all documentation based, let's look:" So, which is it? (a) the ***implementation*** requirements for pragram Reviewable should be treated like documentation requirements (vacuously met), or (b) they shouldn't (i.e. it is possible to fail to meet them). If (a), then how does someone determine which other ***implementation*** requirements are vacuously met, and which are critical? > This is formally definable, and of course tested by the ACVC > tests. Again, I ask where did you get the idea that > implementation requirements are not requirements??????? >From you. You should really read the implementation requirements for pragma Reviewable, they're quite extensive. None are tested by the ACVC, of course... > > > When we were discussing these safety and security requirements > during that > > industry-implementors meeting lo these many years ago, I was > frankly > > surprised that the vendor representatives (including yourself) > didn't put up > > more of a fuss. Now I see why. What a total waste of our time. > > Actually many useful things came out of those meetings, but if > you thought that the meetings were about requiring vendors to > provide useful usable implementations, you were indeed deluding > yourself, since language standards can never guarantee this. Actually, I thought we were working on a useful usable standard. That is, an agreement from the vendors as to the text of the implementation requirements included the concept that the vendors understood what they meant! Apparently, I was mistaken. > > !topic Non-Requirement Requirements > > !reference RM95-1.1.2(24-39) > > !from Ken Garlington 00-05-05 > > !keywords requirements, advise > > !discussion > > > > The referenced paragraphs define several different categories > of the > > standard. Some of these categories use the term > "requirements," although > > they are not considered requirements by the Ada vendor > community. There > > should be an explicit list of which categories can be > considered > > requirements (i.e., it is possible for a vendor to "fail" to > meet it). All > > other categories should be described in the terms currently > used for > > "Implementation Advice." > > > This is plain silly, I can't imagine the ARG giving it much > attention, since it amounts to nothing more than an unfounded > polemic. There is no part of the Ada community that considers > any requirements in the RM not to be requirements, and > certainly the vendor community does not ignore any requirements. Note my definition of a requirement: "i.e., it is possible for a vendor to 'fail' to meet it." So, which is it? (a) There are areas of the standard that have the word "requirement" attached to them which are vacuously met by all vendors. (b) There aren't. You may consider it "plain silly" to take items in (a) and label them implementation advice, and I'm sure the ARG will give it no attention (I mean, how much weight should my opinion hold?). At least, when a user comes to me and says, "if this is crap, why is in the standard?" I can say, "beats me, I tried to get it fixed, but no one cared." > Again, I think the entire problem comes from the fact that you > don't really understand the purpose of a formal language > definition, and that you read the word "requirement" in > (to use your terms) "software engineering" sense, which is > totally misleading in this context. Absolutely! An equally elegant solution to the problem to this would be to put in the front of the standard: "WARNING: Terms used in this standard, such as 'requirement,' do not have their usual English meaning." > (by the way, I suddenly realize that you Ken > converts my general use of semantic into the headings in the > manual, don't make that mistake, semantics includes a lot more > :-) Excellent! Light begins to dawn. Now, the slippery part: How much more?