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

--- ai05s/ai05-0194-1.txt	2009/11/04 05:50:07	1.1
+++ ai05s/ai05-0194-1.txt	2009/12/08 21:12:00	1.2
@@ -1,5 +1,5 @@
-!standard  13.13.2(1.6/2)                                  09-11-03  AI05-0194-1/01
-!class ramification 09-11-03
+!standard  13.13.2(1.2/2)                                  09-12-08  AI05-0194-1/02
+!class binding interpretation 09-12-08
 !status work item 09-11-03
 !status received 09-07-23
 !priority Low
@@ -18,32 +18,36 @@
 What is the value of S'Stream_Size if it is not user-specified, while S'Write
 has been user-specified?
 
-!response
+!recommendation
 
 (See summary.)
 
 !wording
 
-Add an AARM Note after 13.13.2(1.6/2.c):
+Replace the first sentence of 13.13.2(1.2/2) by:
+     Denotes the number of bits read from or written to a stream by the
+     default implementations of S'Read and S'Write.
+
+Add after 13.13.2(1.a/2):
+   AARM ramification:
+     The value of S'Stream_Size is unaffected by the presence or absence
+     of any attribute definition clauses specifying the Read or Write
+     attributes of any ancestor of S. S'Stream_Size
+     is defined in terms of the behavior of the default implementations
+     of S'Read and S'Write even if those default implementations are
+     overridden.
 
-AARM Ramification: The default value of the Stream_Size attribute depends on how
-the implementation converts values into stream elements for the default
-implementation of Read and Write for elementary types. It does not necessarily
-correspond directly to a conversion of the binary representation to a number of
-stream elements (although that is the most likely meaning). The default value of
-the Stream_Size attribute does not depend on the implementation of any
-user-defined stream attributes.
-
-
 !discussion
 
 Any interpretation other than the one given in the proposed AARM note fails
-"Robert's rule", as any other interpretation quickly leads to nonsense.
-
-The original wording was carefully worded in terms of the "stream elements
-required"; it very carefully avoids any mention of "binary representation"
-or "memory representation" as some seem to think is intended. The "stream
-elements required" clearly depend on how the memory representation is
+"Robert's rule", as any other interpretation quickly leads to nonsense. We
+change the definition of S'Stream_Size in order to avoid any confusion, but
+there is no change in the intended semantics.
+
+The original wording of 13.13.2(1.6/2) was carefully worded in terms of the
+"stream elements required"; it very carefully avoids any mention of "binary
+representation" or "memory representation" as some seem to think is intended.
+The "stream elements required" clearly depend on how the memory representation is
 converted to stream elements, but there is no assumption that that conversion
 is an identity function.
 
@@ -59,9 +63,20 @@
 used in the attribute.) Alternatively, it could adjust the default value of
 Stream_Size to reflect the non-binary representation.
 
+!corrigendum 13.13.2(1.2/2)
+
+@drepl
+@xindent<Denotes the number of bits occupied in a stream by items of
+subtype S. Hence, the number of stream elements required per item of
+elementary type @i<T> is:>
+@dby
+@xindent<Denotes the number of bits read from or written to a stream by the
+default implementations of S'Read and S'Write. Hence, the number of stream
+elements required per item of elementary type @i<T> is:
+
 !ACATS Test
 
-None needed.
+None needed, there is no intended change of semantics.
 
 !appendix
 
@@ -194,5 +209,58 @@
 
 So I still don't see anything worth changing here, but if a Ramification AI will
 make someone feel better, I guess I'll write it up...
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, December 8, 2009  2:23 PM
+
+I've got an action item to take a stab at clarifying wording for AI05-0194, so
+here goes.
+
+13.13.2(1.2/2) currently says
+     Denotes the number of bits occupied in a stream by items of
+     subtype S.
+
+Replace this with:
+     Denotes the number of bits read from or written to a stream by the
+     default implementations of S'Read and S'Write.
+
+   AARM note:
+     The value of S'Stream_Size is unaffected by the presence or absence
+     of any attribute definition clauses specifying the Read or Write
+     attributes of any ancestor of S. S'Stream_Size
+     is defined in terms of the behavior of the default implementations
+     of S'Read and S'Write even if those default implementations are
+     overridden.
+
+Randy points out that accepting this change would mean that the !class for the
+AI then needs to be changed from "ramification" to "binding interpretation" and
+that consequently the "!response" section becomes a "!recommendation" section.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, December 8, 2009  2:46 PM
+
+This looks like a helpful clarification.  I am surprised it needs to be
+classified as a binding interpretation, since it isn't changing the intent, it
+is just clarifying the wording.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, December 8, 2009  3:00 PM
+
+We classify any change to the normative wording as a Binding Interpretation.
+Only changes to notes (esp. AARM notes), examples, etc. can be ramifications.
+That's because any change to the normative wording can have consequences for
+implementations. In this case, if anyone misintrepreted 'Stream_Size (one
+possibility would be to assume that it always means the binary size of the
+subtype, even when some other meaning of the default stream attributes), they
+might feel compelled to change the values of the attribute. Not very likely,
+perhaps, but still possible. (Also, by doing so we don't need to argue about
+whether the change is "clarifying" or "significant". Which sounds like a waste
+of time, but yet one that would happen given our group dynamics.)
 
 ****************************************************************