ELKS flat-short compliance issues 
Author Message
 ELKS flat-short compliance issues

(Yes I know I am beating this flat-short compliance issue to death,
but as long as it continues to be the sole criteria for determining
compliance I think it has to be beaten to death. Also given the
apparent possibility that some vendors may attempt to meet ELKS95
this year, I think more precision is needed on what "ELKS95 compliant"
means)

1) Is case significant in determining flat-short compliance? I would
think not, but it is not listed as one of the acceptable deviations.

2) Is the presentation placement of the indexing information checked
for flat-short compliance? I.e., if a vendor's tools placed the indexing
after the "class GENERAL ..." line (where it belongs) instead of before
it (where Eiffel requires it to be), does that violate flat-short compliance?
(Again I would think not but this deviation is not on the acceptabl list)

3) Allowing different tag names for assertion labels is not a good idea.
For one thing, it complicates compliance verification in that specific
tests must be maintained for each candidate implementation to check that
the appropriate assertion was raised (since only the tag_name is available,
not the actual assertion check itself)

4) Similarly, allowing complete replacement of the assertion (provided that
it can be proved logically ...) is also not a good idea in terms of compliance
checking.

5) Certifiable bogus implementation #3 (or is it #4?):
 class GENERAL
 ... -- as required
 invariant
   -- as required
   bogus: False; -- new class invariant
 end

While totally useless, this candidate implementation must be certified
by the NICE library technical committee as compliant.

6) Has any progress been made in cleaning up the multitude of paradoxes in
ELKS95? Have any changes been made to ELKS95 since Version 8?

7) What authority brands a candidate implementation as compliant? NICE or
the provider of the candidate implementation?

Would any vendor thinking of releasing an ELKS95 compliant product
be willing to provide information now on how they are defining
"ELKS95 compliant" given the flaws in the definition (and the possibility
that no corrections will be made to the ELKS95 definition)?



Sun, 01 Mar 1998 03:00:00 GMT  
 
 [ 1 post ] 

 Relevant Pages 

1. ELKS & flat-short compatibility paradox #1 :-)

2. long = short*short ; (short,short) = long/short

3. flat panel screen issues

4. Flat Real Mode Stack and 32-bit Code Segment Issues

5. Keep FLAT button FLAT

6. CFP: The AI Pride Issue (IEEE intelligent systems special issue)

7. Y2K Compliance & APL2 V1R3

8. ANSI Compliance?

9. Appearance Hacking for Compliance

10. ANSI Compliance

11. IBM VAST Y2K Compliance Document

12. Y2K Compliance Certification

 

 
Powered by phpBB® Forum Software