Re: Required Metrics

["Ken Garlington" <Ken.Garlington@computer.org>]

"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wcczoq7jyt9.fsf@world.std.com...

> The advantage of having a standard is portability.  So
> it's hard to get too excited about a rule in the standard that has no
> effect on portability.... Eg, we all know Robert Dewar hates asynchronous
transfer of
> control, but it would be annoying indeed if GNAT didn't implement it.
> Likewise, I hate modular types -- but of course I don't refuse to
> implement them in the AverStar compilers, and I don't insist on changing
> the rules to be more to my liking.  These would be true even if the
> ACATS didn't test for these features.

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.

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?

> 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.