OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-c-cpp-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Forgot to mention that this was submitted by a member of the OASIS Technical Advisory Board.

bill cox
--
William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax


William Cox wrote:
4A4196F9.7000707@comcast.net" type="cite">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.

[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.

[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.

[3] Editorial lines 1152-1154

Part of the text is a heading; repair.

[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

[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.

[6] Editorial Lines 1758-1766

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

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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]