CVS difference for ai05s/ai05-0060-1.txt

--- ai05s/ai05-0060-1.txt	2008/03/07 06:15:19	1.8
+++ ai05s/ai05-0060-1.txt	2008/05/10 05:14:33	1.9
@@ -1,4 +1,4 @@
-!standard A(4)                                         08-02-26    AI05-0060-1/05
+!standard A(4)                                         08-04-09    AI05-0060-1/06
 !standard E.2.2(9/1)
 !standard E.2.2(9.2/1)
 !standard E.2.2(14/2)
@@ -18,7 +18,7 @@
 or support Annex E pragmas in standard library library_unit_declarations
 if the implementation does not support Annex E.
 
-The definition of remote access types is clarified to only apply to
+The definition of remote access types is clarified to apply only to
 named access types.
 
 Remote access types should be allowed to designate class-wide limited interface
@@ -37,7 +37,7 @@
 (2) It is possible to derive a nonlimited type from a limited interface type.
 If remote access types are allowed to designate class-wide limited interface types,
 should we allow the value of a remote access-to-class-wide limited interface type to
-be a nonlimited object? (Yes.)
+designate a nonlimited object? (Yes.)
 
 (3) E.2.2(16/1) states that remote access types cannot be dereferenced except through
 dispatching calls. This would be the rule that would allow the value of a remote
@@ -95,7 +95,7 @@
    * The primitive subprograms of the corresponding specific [limited private]
      type shall only have access parameters if they are controlling formal
      parameters; each non-controlling formal parameter shall support external
-     streaming (see 13.13/2); 
+     streaming (see 13.13.2); 
 
 Add a new paragraph after E.2.2(14/2): [Note: This depends on pragma Implemented,
 which was added by AI05-0030-2.]
@@ -144,7 +144,7 @@
 can only be operated through the use of remote dispatching calls. Components
 of the object cannot be remotely accessed directly, only indirectly though the
 dispatching calls. This is why the existing rules restrict remote access types
-to only designate private tagged types that are limited in nature whereby all
+to designate only private tagged types that are limited in nature whereby all
 components of the type are private. 
 
 A limited interface type mostly satisfies these basic constraints. A limited
@@ -154,12 +154,12 @@
 type. If remote access types are allowed to designate limited interface types,
 then this would mean that the value of a remote access to class-wide limited
 interface can be an object of a nonlimited type derived from the interface. The
-remote (client) view view of the object would still be the equivalent of a
+remote (client) view of the object would still be the equivalent of a
 limited view however, because of rule E 2.2(16/1) which states that a value
 of a remote access-to-class-wide type shall be dereferenced (or implicitly
 converted to an anonymous access type) only as part of a dispatching call where
 the value designates a controlling operand of the call. The local (server) view
-of the object could be a nonlimited view. This would would mean it could be
+of the object could be a nonlimited view. This would mean it could be
 possible to assign the object locally to a local variable, and that the object
 could be assigned a new value locally. This capability seems to be potentially
 useful and no issues could be found with allowing such usage.
@@ -186,7 +186,7 @@
 and protected interfaces are all considered limited interface types. Also,
 E.2.2(9.3/1) states that a type that is derived from a remote access type is a
 remote access type. Therefore we need to consider whether such interface types
-can be used as remote access types. The first point to consider is that E.4 (17)
+can be used as remote access types. The first point to consider is that E.4(17)
 states that all forms of remote subprogram calls are potentially blocking
 operations. This would seem to rule out interfaces where primitive subprograms are
 required to be implemented by protected subprograms, since protected subprograms
@@ -269,12 +269,12 @@
 @xbullet<The primitive subprograms of the corresponding specific limited private
 type shall only have access parameters if they are controlling formal
 parameters; each non-controlling formal parameter shall support external
-streaming (see 13.13/2);>
+streaming (see 13.13.2);>
 @dby
 @xbullet<The primitive subprograms of the corresponding specific
 type shall only have access parameters if they are controlling formal
 parameters; each non-controlling formal parameter shall support external
-streaming (see 13.13/2);>
+streaming (see 13.13.2);>
 
 @xbullet<The corresponding specific type shall not have a primitive procedure to which
 a @fa<pragma> Implemented applies unless the @fa<implementation_kind> of the pragma is