Fw: [sca-c-cpp-comment] Comments on C Specification Version 1.1

[Bryan Aupperle <aupperle@us.ibm.com>]

Folks, 

In case any of the TC members are not following the Public Review comments
list, here is a copy of an email received there today.

Based on the text in the comments, they apply to the C++ spec despite what
the subject states (but the same comments can be applied to the C spec).


I have also entered this in JIRA as
CCPP-87: http://www.osoa.org/jira/browse/CCPP-87

Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect

Research Triangle Park,  NC 
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com
----- Forwarded by Bryan
Aupperle/Raleigh/IBM on 06/30/2009 04:20 PM -----

Patrick Durusau <patrick@durusau.net>

06/26/2009 10:57 AM

To	sca-c-cpp-comment@lists.oasis-open.org
cc
Subject	[sca-c-cpp-comment] Comments on C Specification Version 1.1

Greetings!

Apologies but I sent these comments to the wrong list. :-(

Some editorial comments on the current draft:

1. Language usage needs to be consistent: "the following snippet"
twice 
in 2.1 and "The following code extract" in 2.3.

2. Moreover, the use of "following," or "above," or
"below," creates 
ambiguity about which "snippet" or "code extract" is
being described. 
The better practice would be to number all of them and then make 
specific reference to those numbered (suggest) "code examples".

Note that the use of indirect and ambiguous references limits the 
utility of the final version as others cannot make clear references to
the "code examples" either in texts, tutorials, manuals or other
materials.

One could argue that the use of line numbers makes precise citation 
possible, if awkward, but the ambiguity of internal referencing remains.
3. I think these are all the instances of "some:"

40 "This specification follows some naming conventions for artifacts
defined by the specification, as follows: "

52 "This specification follows some typographic conventions for some
specific constructs"

370-371 "Some member functions of an interface have behavioral 
characteristics, which will be described later, that need to be 
identified."

448 "Some member functions of an implementation have operational 
characteristics that need to be identified." (err, care to say which
ones?)

1294-1295 "No additional discussion is needed for header files, but
here 
are some additional considerations for executable and componentType 
files discussed in the following sections." (is this all the "additional
considerations"?)

Generally "some" language is to be avoided in standards. Either
we know 
what we want to say or we don't.

BTW, compliments on consistent use of the control language specified in
1.1.

Hope everyone is having a great day!

Patrick

PS: The commenter is a member of the OASIS Technical Advisory Board 
(TAB) ( I shamelessly stole that from Toby Considine.)

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)


--
This publicly archived list offers a means to provide input to the
OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: sca-c-cpp-comment-subscribe@lists.oasis-open.org
Unsubscribe: sca-c-cpp-comment-unsubscribe@lists.oasis-open.org
List help: sca-c-cpp-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/sca-c-cpp-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-c-cpp
Join OASIS: http://www.oasis-open.org/join/