The SCA C-C++ TC thanks you for review and comments on the SCA Client and Implementation Model for C++ Specification.

Our responses to your comments are below.

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

Response: “snippet” will be used consistently.

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.

Response: All snippets, examples, pseudo-schemas, will be captioned and explicitly referenced.

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.

Response: All of these will be reworded.

All of these changes are being tracked by issue CCPP-87 ( http://www.osoa.org/jira/browse/CCPP-87).

Bryan Aupperle, Ph.D. STSM, WebSphere Enterprise Platform Software Solution Architect OASIS SCA C-C++ TC Chair

Research Triangle Park, NC +1 919-254-7508 (T/L 444-7508) Internet Address: aupp...@us.ibm.com

Patrick Durusau <patr...@durusau.net> 06/26/2009 10:57 AM

To sca-...@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 patr...@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-...@lists.oasis-open.org Unsubscribe: sca-...@lists.oasis-open.org List help: sca-...@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/