CVS difference for ais/ai-00104.txt

--- ais/ai-00104.txt	1998/09/30 00:17:17	1.1
+++ ais/ai-00104.txt	1999/07/08 17:25:14	1.2
@@ -1,5 +1,6 @@
-!standard E.3      (04)                               97-11-14  AI95-00104/06
+!standard E.3      (04)                               99-07-07  AI95-00104/07
 !class binding interpretation 95-10-21
+!status Corrigendum 2000 99-05-25
 !status WG9 Approved  97-11-14
 !status ARG approved 8-0-1 (subject to editorial review)  97-04-11
 !status ARG approved 12-0-0 (subject to editorial review)  96-10-07
@@ -11,7 +12,7 @@
 !difficulty Hard
 !subject Version and Body_Version attributes
 
-!summary 97-05-08
+!summary
 
 If P is not a library unit, and P has no completion, then P'Body_Version
 returns the Body_Version of the innermost program unit enclosing the
@@ -28,7 +29,7 @@
 also unspecified whether there are other events (such as recompilation)
 that result in the version of a compilation unit changing.
 
-!question 95-10-21
+!question
 
 Two questions:
 
@@ -57,15 +58,15 @@
 would return a different value every time, which would make them
 useless.  What is the intent?
 
-!recommendation 95-10-21
+!recommendation
 
 (See summary.)
 
-!wording 95-11-17
+!wording
 
 (See summary.)
 
-!discussion 97-10-27
+!discussion
 
 It should not be an error to query P'Body_Version when P has no body,
 because:
@@ -158,8 +159,38 @@
 Note that if X is a renaming declaration (not a renaming-as-body), then
 X'Version and X'Body_Version refer to the versions of the renamed
 entities.
+
+!corrigendum E.03(05)
+
+@drepl
+The @i<version> of a compilation unit changes whenever the version changes
+for any compilation unit on which it depends semantically. The version also
+changes whenever the compilation unit itself changes in a semantically
+significant way. It is implementation defined whether there are other events
+(such as recompilation) that result in the version of a compilation unit
+changing.
+@dby
+The @i<version> of a compilation unit changes whenever the compilation unit
+changes in a semantically significant way. This International Standard
+does not define the exact meaning of "semantically significant". It is
+also unspecified whether there are other events (such as recompilation)
+that result in the version of a compilation unit changing.
+
+@dinsa
+If P is not a library unit, and P has no completion, then P'Body_Version
+returns the Body_Version of the innermost program unit enclosing the
+declaration of P. If P is a library unit, and P has no completion,
+then P'Body_Version returns a value that is different from Body_Version
+of any version of P that has a completion.
+
+!ACATS test
+
+A useful test of these attributes is difficult to construct. Probably the
+most useful test would be a pair of C-Tests which check that the version
+values change when a "semantically significant" change is made. There is
+not currently an ACATS test checking this.
 
-!appendix 97-03-19
+!appendix
 
 !section E.3(04)
 !subject P'Body_Version for package with no body
@@ -1012,7 +1043,7 @@
 > built on different systems at different times; then how do you make
 > sure that the partition you are calling did use the same spec than the
 > one you used at compilation time?
-> 
+>
 > In our case, versions are used to ensure that we have a global
 > consistency. Since we have several executables which may have been
 > bound and linked separately from each other, we cannot rely on a
@@ -1027,7 +1058,7 @@
 
 > Offer> P.S. I wonder if 'Partition_Version would not have been a much
 > Offer> more useful and simpler solution...
-> 
+>
 > I don't think so for the reasons explained above: we need a per
 > package information, since we don't know a priori what will reside in
 > a partition (and in our model, we don't even know at compile time
@@ -1042,10 +1073,10 @@
 
 >     Let's say that Compression_Method is a normal unit (replicated
 >     on two partitions P1 with RCI_1 and P2 with RCI_2) with the
->     same specification on both sides. 
-> 
+>     same specification on both sides.
+>
 >     On RCI_1
-> 
+>
 >     if Compression_Method'Body_Version =
 >       RCI_2.Get_Your_Compression_Body_Version then
 >        RCI_2.RPC_Using_Compressed_Image
@@ -1066,8 +1097,8 @@
 
 > Don't except too much from the partitioning/configuration
 > tool. Version consistency checks have to be performed during
-> execution. Otherwise, they are useless. 
-> 
+> execution. Otherwise, they are useless.
+>
 > If partitions are built by two different compilers vendors, first,
 > they should check consistency by calling `Version; second, `Version
 > has to be precisely defined such a way that the two implementations
@@ -1086,15 +1117,15 @@
 hash-code on the source text (with or without comments, etc).)
 
 > Offer Pazy wrote :
-> | It seems to me that you have to ensure that the function 
-> | Get_Your_Compression_Method must always return the a value consistent with 
-> | the attribute value.  This may be specially tricky when the said body 
-> | indirectly depends on other things in RCI_2 (just as the value of some 
+> | It seems to me that you have to ensure that the function
+> | Get_Your_Compression_Method must always return the a value consistent with
+> | the attribute value.  This may be specially tricky when the said body
+> | indirectly depends on other things in RCI_2 (just as the value of some
 > | variable which may be set by another, completely unrelated unit, in RCI_2).
-> 
+>
 > True, so what? Compression_Method unit is different, the client is not
 > sure that the server compression is *exactly* the same and will send
-> the regular image. 
+> the regular image.
 
 But, given the current definition of 'Body_Version in the RM (and in
 AI-104), there is no way for the client to know that it is not *exactly*