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.7 required=5.0 tests=BAYES_00,MSGID_RANDY 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: Robert Dewar Subject: Re: Required Metrics Date: 2000/05/04 Message-ID: <8es5sk$5cr$1@nnrp1.deja.com> X-Deja-AN: 619175649 References: <5DDO4.2237$wb7.194854@news.flash.net><8ek4ea$5ta$1@nnrp1.deja.com> <390DC8AD.59B5EBEE@averstar.com> <8ep0k3$jlr$1@nnrp1.deja.com> X-Http-Proxy: 1.0 x33.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Thu May 04 15:44:24 2000 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; I) Date: 2000-05-04T00:00:00+00:00 List-Id: In article , "Ken Garlington" wrote: > You *have* changed the rules to be more to your liking, if you can > *unilaterally* decide which rules affect portability (or any other desirable > aspect of standardization, such as the ability to reduce training costs). > For example, if a vendor decides that there's some required aspect of ATC > that no one is ever going to use, and it's not required to pass the > validation suite, then it sounds like that vendor is permitted to not > implement the feature. Certainly, no one could in good conscience complain > that this violates the standard, if they accept your argument. That's a strawman. Obviously no one can sign the DOC if they have deliberately failed to implement some aspect of the standard, whether or not it is tested in the ACAATS tests > In addition, if vendors alone are permitted to decide what really _isn't_ in > the standard, why can't vendors alone decide what's really _in_ the > standard? Why spend all this time fooling with ISO standardization > procedures if vendors have, in essence, a veto? Is it just for the publicity > value? That's an absurd over-reaction to the thread at hand, not based in any reality. Remember this thread is all about a requirement that is clearly semantically meaningless in formal terms (the RM does not even describe what the word "documentation" means, and that's a serious omission. Note that we could if we wanted perfectly well declare that our sources are part of the documentation and constitute the full compliance with the requirements of annex M. That would meet the RM standards from a legal point of view, but it would be useless to our customers. I really think the documentation requirements of the standard have almost no effect on compiler writers. Documentation is written for the benefit of users. It is presumptious in any case for the RM to think it can know what kinds of documentation the user will require. Furthermore, if it requires documentation without any indication of what the requirement means, then the requirement is plain useless. But Ken, extending this to clearly defined technical features, where the requirements are meaningful and semantically sound makes no sense at all. Bob Duff was quite clear in saying that in THIS area, vendors follow the RM closely even if they don't like what it says, and even if the tests do not test something. His examples were well chosen ones. I do indeed think that ATC was a huge mistake in the design of Ada, but Ada Core Technologies has invested significant resources in making this feature work completely and well, not just to pass the tests, but to meet the requirements of our users. Your concerns about vendors running amok would make more sense if you would give us some nice examples of what it is that you do not like :-) Robert Dewar Ada Core Technologies > > > The ARG still exists, and still generates AI's. > > > > I suspect that if you sent in a question saying "Are the metrics really > > required?", the ARG would issue a ruling saying, "Yes, of course, it > > says so in plain English." (I'm not sure of that; some people might use > > it as an opportunity to get rid of these silly rules. Some people might > > take the attitude that you can't require something unless you can > > precisely define it -- and thus declare the metrics to be meaningless > > gibberish.) > > Per the standard, I just sent the mail message attached at the end. We'll > see what happens... > > > On the other hand, if you asked, "What, exactly, do the metrics > > require?", the ARG would refuse to waste time trying to answer the > > impossible. > > > > So, whatever compiler it was that said "Documentation not yet > > available", send them a bug report. I wouldn't be surprised if it's our > > compiler. ;-) > > If it's impossible to answer whether or not an implementation meets the > requirement, what's the bug? How would I know if it's fixed? In particular, > if _every_ vendor is doing this (and no one has said otherwise), it sounds > like something a bug report to a single vendor won't fix. > > ----- > > From: Ken Garlington [mailto:Ken.Garlington@computer.org] > Sent: Wednesday, May 03, 2000 7:23 PM > To: ada-comment@sw-eng.falls-church.va.us > Subject: Minimum criteria for metrics documentation > > !topic Minimum criteria for metrics documentation > !reference RM95-D(2) > !from Author Name 00-05-03 > !keywords metrics, documentation, real-time > !discussion > > Is there any criteria that can be used to determine if a vendor has formally > met the requirements to document metrics described in D(2-6)? For example, > which (if any) of the following conditions would be considered acceptable? > > 1. The vendor states that the metrics are not currently available. > > 2. Same as #1, but vendor provides source code for its implementation of > interfaces to an underlying operating system. > > 3. Same as #2, but vendor explicitly states that source code is provided to > meet requirement. > > 4. Same as #3, but vendor provides a list of which source code files are > applicable. > > Sent via Deja.com http://www.deja.com/ Before you buy.