Fw: [sca-c-cpp-comment] Comments on Public Review Draft 01 - C++

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

Folks, 

I have marked up the following set of comments on the C++ spec as <Editorial>
for editorial comments, which I think 
should be logged as a single issue, and <Issue
n> for substantive comments
which I think should each be raised as a separate 
issue for tracking purposes. 

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/24/2009 08:53 AM -----

William Cox <wtcox@comcast.net>

06/23/2009 11:01 PM

To	sca-c-cpp-comment@lists.oasis-open.org
cc
Subject	[sca-c-cpp-comment] Comments on Public Review Draft 01 - C++

Comment numbers in square brackets. References are
to the PDF.

[0] The specification is excellent overall. I found few errors, and the
specifcation raised relatively few questions.

<Editorial - FYI,
there is some discussion about the color choice for the highlighting in
a couple of the other TCs.>
[1] Editorial Line 52

Reference should be made to the typographical conventions for 
conformance assertions in this section. The Assembly document's handling
of conformance statements and highlighting is excellent; I recommend 
that this (and all other SCA specs) follow that example.

A reference to Section 11 belongs in the typographic conventions section.

<Issue 1>
[2] Technical Section 2.1.1ff

Some of this reads like reinvention of aspects of CORBA with remote 
services. A compare and contrast (perhaps in a separate architectural 
white paper) with other remoting techniques would make this choice 
easier to review. Is this indeed a reinvention? Or is it a simple 
acknowledgement that remotable and local services share some similarity
in the SCA model? More architectural discussion would make that 
evaluation easier.

The specification is quite clear and seems effective, though I've not 
tried to write to it.

<Editorial - same
formatting conversion problem raised by J. Durand.>
[3] Editorial lines 1152-1154

Part of the text is a heading; repair.

<Issue 2>
[4] Technical Lines 1641-1644

It's quite clear (given the context, though not stated) why Friend 
classes MUST NOT be used; it's less clear why Macros should not be.  If
this is an implementation-based architectural decision, perhaps it 
should be mentioned

<Issue 3>
[5] Technical General

It's hard to tell where to start reading the SCA specifications; I've 
concentrated on Assembly and Java/C++ as that's what I intend to use.  
Many of the architectural choices, and the specification details, would
be more clear if mentioned in a separate white paper or linkable 
publication . The architectural choices made in the design of SCA are 
interesting in of themselves, but would inform the reader, implementer,
and user as they work with the specifciations.

<Editorial>
[6] Editorial Lines 1758-1766

A reference to the conformance items and Appendix F would make this 
section read better.

<Editorial>
[7] Editorial General

"Error! Reference source not found" at lines 991 and 1413. Please
repair.



--
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/