atom feed3 messages in org.oasis-open.lists.sca-c-cpp-chairRe: [sca-c-cpp-comment] Comments on P...
FromSent OnAttachments
William CoxJun 23, 2009 8:00 pm 
William CoxJun 23, 2009 8:11 pm 
Bryan AupperleJul 16, 2009 9:47 am 
Subject:Re: [sca-c-cpp-comment] Comments on Public Review Draft 01 - C++
From:William Cox (wtc@CoxSoftwareArchitects.com)
Date:Jun 23, 2009 8:11:26 pm
List:org.oasis-open.lists.sca-c-cpp-chair

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

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