CVS difference for ais/ai-presentation.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-presentation.txt

--- ais/ai-presentation.txt	1998/10/01 19:10:54	1.2
+++ ais/ai-presentation.txt	1999/07/29 00:51:02	1.3
@@ -579,64 +579,6 @@
 pleroy@rational.com                             +33.1.30.12.09.66 FAX
 
 ****************************************************************
-!standard G.1.1    (02)                               95-06-25  AI95-00028/00
-!class presentation 95-06-25
-!status WG9 approved  96-06-14
-!status received 95-06-25
-!subject Typo: "pragma" should be in boldface
-
-!summary 95-06-25
-
-!question 95-06-25
-
-!recommendation 95-06-25
-
-!wording 95-06-25
-
-!discussion 95-06-25
-
-!appendix 95-06-25
-
-!section G.1.1(02)
-!subject Typo: "pragma" should be in boldface
-!reference RM9X-G.1.1(2);5.95
-!from Norman Cohen
-!reference as: 95-5088.d Norman H. Cohen 95-1-30>>
-
-****************************************************************
-!standard 03.06.02 (02)                               95-06-25  AI95-00030/00
-!class presentation 95-06-25
-!status WG9 approved  96-06-14
-!status received 95-06-25
-!subject The word "prefix" should be in sans-serif font.
-
-!summary 95-06-25
-
-!question 95-06-25
-
-!recommendation 95-06-25
-
-!wording 95-06-25
-
-!discussion 95-06-25
-
-!appendix 95-06-25
-
-!section 3.6.2(2)
-!section 3.7.2(2)
-!subject More syntactical categories
-!reference RM9X-3.6.2(2);5.95
-!reference RM9X-3.7.2(2);5.95
-!from Stéphane Barbey
-!reference as: 95-5089.a Stephane Barbey 95-1-31>>
-
-Shouldn't the word "prefix" in the paragraph 3.6.2(2) ("The following
-attributes are defined for a prefix A that is of an array type ...") be
-a syntactical category, like (for instance) in 3.7.2(2) ?
-
--Stephane
-
-****************************************************************
 !standard B.1      (39)                               95-06-25  AI95-00052/00
 !class presentation 95-06-25
 !status WG9 approved  96-06-14
@@ -672,129 +614,6 @@
 words "adainit" and "adafinal" don't need to be capitalized.
 
 ****************************************************************
-!standard 13.11    (39)                               95-07-27  AI95-00066/00
-!class presentation 95-07-27
-!status WG9 approved  96-06-14
-!status received 95-07-27
-!subject Incorrect syntax in example -- remove "limited"
-
-!summary 95-07-27
-
-The reserved word "limited" should be removed from the example in
-13.11(39).
-
-!question 95-07-27
-
-!recommendation 95-07-27
-
-!wording 95-07-27
-
-!discussion 95-07-27
-
-!appendix 95-07-27
-
-!section 13.11(39)
-!subject Incorrect syntax in example -- remove "limited"
-!reference RM95-13.11(39)
-!from Bob Duff
-!reference as: 95-5214.a Robert A Duff 95-7-8>>
-!discussion
-
-The syntax used in this example is incorrect.  The reserved word
-"limited" should be removed.  (This dates from an earlier version of Ada
-9X, where "limited" was required at that point.)
-
-****************************************************************
-!standard D.4      (01)                               95-07-27  AI95-00068/00
-!class presentation 95-07-27
-!status WG9 approved  96-06-14
-!status received 95-07-27
-!subject "It also defines [one such policy]{two such policies}."
-
-!summary 95-07-27
-
-D.4 defines *two* language-defined policies.
-
-!question 95-07-27
-
-!recommendation 95-07-27
-
-!wording 95-07-27
-
-!discussion 95-07-27
-
-!appendix 95-07-27
-
-!section D.4(01)
-!subject "It also defines [one such policy]{two such policies}."
-!reference RM95-D.4(01)
-!from Bob Duff
-!reference as: 95-5214.c Robert A Duff 95-7-8>>
-!discussion
-
-I'm submitting this on behalf of Robert Dewar.
-
-There are two language-defined policies: FIFO_Queuing and
-Priority_Queuing.  Perhaps the sentence is meant to imply that this
-clause defines Priority_Queuing, whereas FIFO_Queuing is defined in
-9.5.3 and 9.7.1.  But then, "Other policies are implementation defined."
-would imply that FIFO_Queuing is implementation defined, which is
-clearly not true.
-
-
-
-****************************************************************
-!standard F.3.2    (74)                               95-08-19  AI95-00070/00
-!class presentation 95-08-19
-!status WG9 approved  96-06-14
-!status received 95-08-19
-!subject Incorrect Picture String Example
-
-!summary 95-08-19
-
-The picture example in F.3.2(74) should read as follows:
-
-   123456.78  Picture:   "-$**_***_**9.99"
-              Result:    "b$***123,456.78"
-                        "bFF***123.456,78"  (currency = "FF",
-                                             separator = '.',
-                                             radix mark = ',')
-
-!question 95-08-19
-
-!recommendation 95-08-19
-
-!wording 95-08-19
-
-!discussion 95-08-19
-
-!appendix 95-08-19
-
-!section F.3.2(74)
-!subject Incorrect Picture String Example
-!reference RM95-F.3.2(74)
-!from Ben Brosgol 95-08-16
-!reference as: 95-5259.a Ben Brosgol 95-8-16>>
-!discussion
-
-The picture string "-$$$**_***_**9.99" in the referenced paragraph is
-invalid, since a floating currency symbol is not allowed in the same
-picture string as a zero suppression symbol.  The correction is to have
-just one '$' in the picture string, making it a fixed-position currency
-symbol, and to remove two leading blanks (indicated by 'b') from the
-result strings.  Thus:
-
-   123456.78  Picture:   "-$**_***_**9.99"
-              Result:    "b$***123,456.78"
-                        "bFF***123.456,78"  (currency = "FF",
-                                             separator = '.',
-                                             radix mark = ',')
-
-Note that one of the ACVC tests currently relies on the incorrect
-version of the example and thus will need to be revised.
-
-
-****************************************************************
 !standard 13.01    (24)                               95-07-27  AI95-00075/00
 !class presentation 95-07-27
 !status received 95-07-27
@@ -918,48 +737,6 @@
 end R;
 
 ****************************************************************
-
-****************************************************************
-!standard A        (02)                               95-07-27  AI95-00081/00
-!class presentation 95-07-27
-!status WG9 approved  96-06-14
-!status received 95-07-27
-!subject Integer_Text_IO, etc. not listed in A(2)
-
-!summary 95-07-27
-
-Integer_Text_IO and Float_Text_IO should be listed in A(2).
-
-!question 95-07-27
-
-!recommendation 95-07-27
-
-!wording 95-07-27
-
-!discussion 95-07-27
-
-!appendix 95-07-27
-
-!section A(02)
-!subject Integer_Text_IO, etc. not listed in A(2)
-!reference RM95-A(2)
-!reference RM95-A.10.8(20-22)
-!reference RM95-A.10.9(32-34)
-!from Keith Thompson 95-07-24
-!reference as: 95-5231.a Keith Thompson 95-7-24>>
-!discussion
-
-Paragraph A(2) is (intended to be) a list of all the predefined library
-units in the language.  This list does not include Ada.Integer_Text_IO,
-Ada.Float_Text_IO or the equivalent packages for any other predefined
-integer and floating-point types.  (Since any other predefined
-numeric types are implementation-specific, I wouldn't expect
-Ada.Long_Integer_Text_IO, for example, to be listed here.)
-
-Note that Ada.Numerics.Elementary_Functions, a non-generic equivalent
-of Ada.Numerics.Generic_Elementary_Functions for type Float, is listed.
-
-****************************************************************
 !standard RM-00.00 (00)                               95-09-29  AI95-00088/00
 !class presentation 95-09-29
 !status WG9 approved  96-06-14
@@ -997,81 +774,6 @@
 Suggestion: add 10.2(29) to the index entry for "main subprogram".
 
 ****************************************************************
-!standard A        (02)                               96-04-04  AI95-00111/00
-!class presentation 96-04-04
-!status received 96-04-04
-!subject Integer_Text_IO, etc. not listed in A(2)
-
-!summary 96-04-04
-
-The packages Ada.Integer_Wide_Text_IO and Ada.Float_Wide_Text_IO should
-also be listed in A(2).
-
-!question 96-04-04
-
-!recommendation 96-04-04
-
-!wording 96-04-04
-
-!discussion 96-04-04
-
-!appendix 96-04-04
-
-!section A(02)
-!subject Integer_Text_IO, etc. not listed in A(2)
-!reference RM95-A(2)
-!reference RM95-A.10.8(20-22)
-!reference RM95-A.10.9(32-34)
-!reference RM95-A.11(3)
-!reference AI95-00081
-!from Keith Thompson 95-11-02
-!reference 95-5380.a Keith Thompson 95-11-2>>
-!discussion
-
-The packages Ada.Integer_Wide_Text_IO and Ada.Float_Wide_Text_IO should
-also be listed in A(2).
-
-****************************************************************
-!standard B.3.2    (49)                               96-05-07  AI95-00142/00
-!class presentation 96-05-07
-!status received 96-05-07
-!subject Incorrect example for Interfaces.C.Pointers
-
-!summary 96-05-07
-
-
-!question 96-05-07
-
-
-!recommendation 96-05-07
-
-
-!wording 96-05-07
-
-
-!discussion 96-05-07
-
-
-!appendix 96-05-07
-
-!section B.3.2(49)
-!subject Incorrect example for Interfaces.C.Pointers
-!reference RM95 B.3.2(49)
-!from Pascal Leroy 96-04-29
-!reference 96-5528.e Pascal Leroy 96-4-29>>
-!discussion
-
-In the example, the usage of "=" in:
-
-   exit when Element = C.Nul;
-
-is illegal unless a use type clause is added for type C.Char.
-
-_____________________________________________________________________
-Pascal Leroy                                    +33.1.30.12.09.68
-pleroy@rational.com                             +33.1.30.12.09.66 FAX
-
-****************************************************************
 !standard 04.05.02 (37)                               97-08-19  AI95-00154/01
 !class presentation 96-09-04
 !status received 96-09-04
@@ -1121,7 +823,7 @@
 !reference 1997-15776.a Xu Bao Wen 1997-8-15>>
 !discussion
 
-In the section 3.8.1, Variant Parts and Discrete Choice,   of  Ada  Reference 
+In the section 3.8.1, Variant Parts and Discrete Choice,   of  Ada  Reference
 Manual¡ª¡ªLanguage and Standard Libraries[ARM95], variant parts in records is
  syntactically defined as following(3.8.1, 2-5):
 
@@ -1135,18 +837,18 @@
                 component_list
       discrete_choice_list ::= discrete_choice {| discrete_choice}
       discrete_choice ::= expression | discrete_range | others
+
+And, in the relevant Lagality Rules(3.8.1, 8), the language imposes  the  two
+restrictions on the use of the reserved word others:
 
-And, in the relevant Lagality Rules(3.8.1, 8), the language imposes  the  two 
-restrictions on the use of the reserved word others: 
-    
-              The  discrete  choices  others  shall  appear  alone  in  a 
+              The  discrete  choices  others  shall  appear  alone  in  a
     discrete_choice_list, and such a discrete_choice_list, if it appears,
      shall be the last one in the enclosing construct.
 
-It is quite evident that these two restrictions are  both  belong  to  syntax 
-categories, and impossible to be derived  from  the  above- mentioned  syntax 
-rules on variant_part.   This  is  inconsistent  with  the  syntax  rules  of 
-record_definition  etc.   For  examples,    from   the   syntax   rules   of 
+It is quite evident that these two restrictions are  both  belong  to  syntax
+categories, and impossible to be derived  from  the  above- mentioned  syntax
+rules on variant_part.   This  is  inconsistent  with  the  syntax  rules  of
+record_definition  etc.   For  examples,    from   the   syntax   rules   of
 record_definition (section 3.8, ARM95),
 
       record_definition ::=
@@ -1164,13 +866,13 @@
 
 we can derive the that:
 
-     *   There  is  a  variant_part  at  most  in  the  component_list  of  a 
+     *   There  is  a  variant_part  at  most  in  the  component_list  of  a
 record_definition;
-    * The variant_part, if it appears, shall be the last one in the enclosing 
+    * The variant_part, if it appears, shall be the last one in the enclosing
  construct.
 
 In order to resolve the inconsistency, and to make a more precise description
- of the syntax rules of the variant_part, I propose that the syntax rules  of 
+ of the syntax rules of the variant_part, I propose that the syntax rules  of
 the variant_part should be revised as follows:
 
       variant_part ::=
@@ -1180,7 +882,7 @@
       variant_list ::=
             basic_variant { basic_variant }
           | { basic_variant } others_variant
-      basic_variant ::= 
+      basic_variant ::=
             when basic_discrete_choice_list =>
                 component_list
       basic_discrete_choice_list ::=
@@ -1190,9 +892,9 @@
             when others =>
                 component_list
 
-Based on the revised  syntax  rules,   the  above- mentioned  description  on 
-Legality Rules can be removed. Althoug it seems the revision is more complex, 
-its advantages are quite obvious: it not only solves the  aforementioned 
+Based on the revised  syntax  rules,   the  above- mentioned  description  on
+Legality Rules can be removed. Althoug it seems the revision is more complex,
+its advantages are quite obvious: it not only solves the  aforementioned
 problem, but also simplifies the Legality Rules.
 
 Address :
@@ -1215,8 +917,8 @@
 !reference 1997-15777.a Xu Bao Wen 1997-8-15>>
 !discussion
 
-In the section 5.4, Case statements, of Ada Reference Manual¡ª¡ªLanguage  and 
-Standard Libraries[ARM95],   case  statements  is  syntactically  defined  as 
+In the section 5.4, Case statements, of Ada Reference Manual¡ª¡ªLanguage  and
+Standard Libraries[ARM95],   case  statements  is  syntactically  defined  as
 following(5.4, 2-3):
 
       case_statement ::=
@@ -1228,16 +930,16 @@
             when discrete_choice_list =>
                 sequence_of_statements
 
-And, in the relevant Lagality Rules(5.4, 5), the  language  imposes  the  two 
-restrictions on the use of the reserved word others: 
-    
-    A discrete_choice others, if present, shall appear alone and  in  the 
+And, in the relevant Lagality Rules(5.4, 5), the  language  imposes  the  two
+restrictions on the use of the reserved word others:
+
+    A discrete_choice others, if present, shall appear alone and  in  the
     last discrete_choice_list.
 
-It is quite evident that these two restrictions are  both  belong  to  syntax 
-categories, and impossible to be derived  from  the  above- mentioned  syntax 
-rules on case_statement.   This  is  inconsistent  with  the  syntax  rules  of 
-record_definition  etc.   For  examples,    from   the   syntax   rules   of 
+It is quite evident that these two restrictions are  both  belong  to  syntax
+categories, and impossible to be derived  from  the  above- mentioned  syntax
+rules on case_statement.   This  is  inconsistent  with  the  syntax  rules  of
+record_definition  etc.   For  examples,    from   the   syntax   rules   of
 record_definition (section 3.8, ARM95),
 
       record_definition ::=
@@ -1255,13 +957,13 @@
 
 we can derive the that:
 
-     *   There  is  a  variant_part  at  most  in  the  component_list  of  a 
+     *   There  is  a  variant_part  at  most  in  the  component_list  of  a
 record_definition;
-    * The variant_part, if it appears, shall be the last one in the enclosing 
+    * The variant_part, if it appears, shall be the last one in the enclosing
  construct.
 
 In order to resolve the inconsistency, and to make a more precise description
- of the syntax rules of the case_statement, I propose that the  syntax  rules 
+ of the syntax rules of the case_statement, I propose that the  syntax  rules
 of the case_statement should be revised as follows:
 
       case_statement ::=
@@ -1280,12 +982,12 @@
             when others =>
                 sequence_of_statements
 
-Based on the revised syntax rules, the sentence in the subsection 5.4(5)  can 
-be removed:¡°A discrete_choice others, if present, shall appear alone and  in 
+Based on the revised syntax rules, the sentence in the subsection 5.4(5)  can
+be removed:¡°A discrete_choice others, if present, shall appear alone and  in
 the last discrete_choice_list.¡±
 
-Althoug it seems the revision is more  complex,   its  advantages  are  quite 
-obvious: it not only solves the aforementioned problem, but  also  simplifies 
+Althoug it seems the revision is more  complex,   its  advantages  are  quite
+obvious: it not only solves the aforementioned problem, but  also  simplifies
 the Legality Rules.
 
 Address :
@@ -1308,7 +1010,7 @@
 !reference 1997-15778.a Xu Bao Wen 1997-8-15>>
 !discussion
 
-In the section 11.2, Exception Handlers, of Ada Reference Manual¡ª¡ª Language 
+In the section 11.2, Exception Handlers, of Ada Reference Manual¡ª¡ª Language
 and Standard Libraries[ARM95], handled_sequence_of_statement is syntactically
  defined as following(11.2, 2-5):
 
@@ -1322,17 +1024,17 @@
             sequence_of_statements
     choice_parameter_specification ::= defining_identifier
     exception_choice ::= exception_name | others
+
+And,   in  the  relevant  Lagality  Rules(11.2, 7),   the  language  imposes  the  two
+restrictions on the use of the reserved word others:
 
-And,   in  the  relevant  Lagality  Rules(11.2, 7),   the  language  imposes  the  two 
-restrictions on the use of the reserved word others: 
-    
-        A choice with others is allowed only for the last  handler  of  a 
+        A choice with others is allowed only for the last  handler  of  a
     handled_sequence_of_statements and as the only choice of that handler.
 
-It is quite evident that these two restrictions are  both  belong  to  syntax 
-categories, and impossible to be derived  from  the  above- mentioned  syntax 
-rules on handled_sequence_of_statement. This is inconsistent with the  syntax 
-rules of record_definition etc. For  examples,   from  the  syntax  rules  of 
+It is quite evident that these two restrictions are  both  belong  to  syntax
+categories, and impossible to be derived  from  the  above- mentioned  syntax
+rules on handled_sequence_of_statement. This is inconsistent with the  syntax
+rules of record_definition etc. For  examples,   from  the  syntax  rules  of
 record_definition (section 3.8, ARM95),
 
       record_definition ::=
@@ -1350,14 +1052,14 @@
 
 we can derive the that:
 
-     *   There  is  a  variant_part  at  most  in  the  component_list  of  a 
+     *   There  is  a  variant_part  at  most  in  the  component_list  of  a
 record_definition;
-    * The variant_part, if it appears, shall be the last one in the enclosing 
+    * The variant_part, if it appears, shall be the last one in the enclosing
  construct.
 
 In order to resolve the inconsistency, and to make a more precise description
  of the syntax rules of the handled_sequence_of_statement, I propose that the
- syntax rules of  the  handled_sequence_of_statement  should  be  revised  as 
+ syntax rules of  the  handled_sequence_of_statement  should  be  revised  as
 follows:
 
       handled_sequence_of_statements ::=
@@ -1378,13 +1080,13 @@
       choice_parameter_specification ::= defining_identifier
       exception_name_list ::= exception_name {|exception_name }
 
-And the subsection 11.2(7) can be completely deleted, that is,  the  sentence 
-in the subsection 11.2(7) can be removed:¡°A choice with  others  is  allowed 
-only for the last handler of a handled_sequence_of_statements and as the  only 
+And the subsection 11.2(7) can be completely deleted, that is,  the  sentence
+in the subsection 11.2(7) can be removed:¡°A choice with  others  is  allowed
+only for the last handler of a handled_sequence_of_statements and as the  only
 choice of that handler.¡±
 
-Althoug it seems the revision is more  complex,   its  advantages  are  quite 
-obvious: it not only solves the aforementioned problem, but  also  simplifies 
+Althoug it seems the revision is more  complex,   its  advantages  are  quite
+obvious: it not only solves the aforementioned problem, but  also  simplifies
 the Legality Rules.
 
 Address :
@@ -1407,8 +1109,8 @@
 !reference 1997-15779.a Xu Bao Wen 1997-8-15>>
 !discussion
 
-In the section 4.3.1, Record Aggregates, of Ada Reference Manual¡ª¡ª Language 
-and Standard Libraries[ARM95], record aggregate is  syntactically defined  as 
+In the section 4.3.1, Record Aggregates, of Ada Reference Manual¡ª¡ª Language
+and Standard Libraries[ARM95], record aggregate is  syntactically defined  as
 following(4.3.1, 2-5):
 
       record_aggregate ::= ( record_component_association_list )
@@ -1421,16 +1123,16 @@
             component_selector_name {| component_selector_name }
           | others
 
-And, in the relevant paragraph(4.3.1, 6), the language imposes the  following 
-restrictions on the use of the reserved word others: 
-    
-        If there is a named association with a  component_choice_list  of 
+And, in the relevant paragraph(4.3.1, 6), the language imposes the  following
+restrictions on the use of the reserved word others:
+
+        If there is a named association with a  component_choice_list  of
     others, it shall come last.
 
 It is quite evident that the restriction  is belong to syntax categories, and
- impossible  to  be  derived  from  the  above- mentioned  syntax  rules  on 
-record_aggregate.   This  is  inconsistent  with   the   syntax   rules   of 
-record_definition  etc.   For  examples,    from   the   syntax   rules   of 
+ impossible  to  be  derived  from  the  above- mentioned  syntax  rules  on
+record_aggregate.   This  is  inconsistent  with   the   syntax   rules   of
+record_definition  etc.   For  examples,    from   the   syntax   rules   of
 record_definition (section 3.8, ARM95),
 
       record_definition ::=
@@ -1448,13 +1150,13 @@
 
 we can derive the that:
 
-     *   There  is  a  variant_part  at  most  in  the  component_list  of  a 
+     *   There  is  a  variant_part  at  most  in  the  component_list  of  a
 record_definition;
-    * The variant_part, if it appears, shall be the last one in the enclosing 
+    * The variant_part, if it appears, shall be the last one in the enclosing
  construct.
 
 In order to resolve the inconsistency, and to make a more precise description
- of the syntax rules of the record_aggregate, I propose that the syntax rules  of 
+ of the syntax rules of the record_aggregate, I propose that the syntax rules  of
 the record_aggregate should be revised as follows:
 
       record_aggregate ::= ( record_component_association_list )
@@ -1470,11 +1172,11 @@
             others => expression
 
 Based on the revised syntax rules,the sentence in the subsection 4.3.1(6) can
- be removed:¡°If there is a named association with a component_choice_list of 
+ be removed:¡°If there is a named association with a component_choice_list of
 others, it shall come last.¡±
 
-Althoug it seems the revision is more  complex,   its  advantages  are  quite 
-obvious: it not only solves the aforementioned problem, but  also  simplifies 
+Althoug it seems the revision is more  complex,   its  advantages  are  quite
+obvious: it not only solves the aforementioned problem, but  also  simplifies
 the description on the syntax.
 
 Address :
@@ -1497,8 +1199,8 @@
 !reference 1997-15780.a Xu Bao Wen 1997-8-15>>
 !discussion
 
-In the section 4.3.3, Array Aggregates, of Ada Reference Manual ¡ª¡ª Language 
-and Standard Libraries[ARM95],  named  record  aggregate  is    syntactically 
+In the section 4.3.3, Array Aggregates, of Ada Reference Manual ¡ª¡ª Language
+and Standard Libraries[ARM95],  named  record  aggregate  is    syntactically
 defined as following(4.3.3, 4-5):
 
       named_array_aggregate ::=
@@ -1507,23 +1209,23 @@
            discrete_choice_list => expression
 
 According to the syntax and the relevant description, we can write several  ¡°
-legal¡± named array aggregates as follows: 
+legal¡± named array aggregates as follows:
 
       (1,2=>6.1, others=>4.95, 5,6=>9.0)
       (1..3=>8.978, 7,9,others=>9.7)
 
-However, it is obviously that these  two  named  array  aggregates  are  both 
+However, it is obviously that these  two  named  array  aggregates  are  both
 illegal! In order to solve this, we should  append  some sentence  similar  to
 the following in therelevant paragraph(such as in paragraph 6,9 or 10):
-    
-      The   discrete   choice   others   shall   appear   alone   in   a 
-    discrete_choice_list,and such a discrete_choice_list, if it appears,  
+
+      The   discrete   choice   others   shall   appear   alone   in   a
+    discrete_choice_list,and such a discrete_choice_list, if it appears,
     shall be the last one in the enclosing construct.
 
 But it is quite evident that the restriction  is belong to syntax categories,
- and impossible to be derived  from  the  above- mentioned  syntax  rules  on 
-record_aggregate.   This  is  inconsistent  with   the   syntax   rules   of 
-record_definition  etc.   For  examples,    from   the   syntax   rules   of 
+ and impossible to be derived  from  the  above- mentioned  syntax  rules  on
+record_aggregate.   This  is  inconsistent  with   the   syntax   rules   of
+record_definition  etc.   For  examples,    from   the   syntax   rules   of
 record_definition (section 3.8, ARM95),
 
       record_definition ::=
@@ -1541,13 +1243,13 @@
 
 we can derive the that:
 
-     *   There  is  a  variant_part  at  most  in  the  component_list  of  a 
+     *   There  is  a  variant_part  at  most  in  the  component_list  of  a
 record_definition;
-    * The variant_part, if it appears, shall be the last one in the enclosing 
+    * The variant_part, if it appears, shall be the last one in the enclosing
  construct.
 
 In order to resolve the inconsistency, and to make a more precise description
- of the syntax rules of the named_array_aggregate, I propose that the  syntax 
+ of the syntax rules of the named_array_aggregate, I propose that the  syntax
 rules of the named_array_aggregate should be revised as follows:
 
     named_array_aggregate ::=
@@ -1603,20 +1305,3 @@
 
 ****************************************************************
 
-From: 	Stephane Barbey[SMTP:Stephane.Barbey@di.epfl.ch]
-Sent: 	Monday, April 27, 1998 7:58 AM
-Subject: 	Accept body
-
-!topic     Accept body
-!reference RM95 D.11(18), RM95 J.7.1(16), RM95 J.7.1(20)
-!from      Stéphane Barbey 1998-4-27
-<<reference as: 1998-15857.a Stephane Barbey  1998-4-27>>
-
-RM95 D.11(18), RM95 J.7.1(16) and RM95, J.7.1(20) mention the concept
-of "accept body", which is not defined elsewhere. The ARG should probably
-rephrase these paragraphs, although I guess that the priority of this
-item is very low.
-
--Stephane
-
-****************************************************************

Questions? Ask the ACAA Technical Agent