CD 01 review observations.

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

I have had a chance to do a more complete
read of CD 01 and I have the following observations.  I believe items
3 and 4 are editorial but I suspect that 1 and 2 need issues opened.  If
folks agree, I will be happy to open the issues.

1) Lines 185-186 state: A component
type file has the same name as the implementation file but has
the extension “.componentType”.

This works only for languages where
the executable artifact for an implementation is distinct from the executable
artifact from other implementations. In languages like C++, multiple implementations
are likely linked together is a common executable file (DLL).  Source
files are not appropriate for basing the name either since the actual code
files (as opposed to header files) typically will not be available at runtime.
 A case could be made for basing componentType files on header files,
but this does not work for all languages either (C in particular).
We need to allow for an implementation
to point to the artifact(s) defining the component type with no forced
relationship between the implementation artifact name and the componentType
artifact(s).

Proposal:  Delete the above sentence
and modify the following sentences to be: The component type is defined
by a componentType element in the componentType file. The
extension of a componentType files is “.componentType”
but its name and location depends on the type
of the component implementation: the specifics are described in the respective
client and implementation model specification for the implementation type.


2) Lines 385-386 state: source
: string (0..1) - an XPath expression pointing to a property of
the using composite from which the value of this property is obtained.

Does a property in a componentType really
have a source?  And if it does, what is the containing composite for
a componentType?

Proposal: Delete these lines and adjust
the schema & pseudo-schema accordingly.


3) Lines 624-627 identify all of the
implementation types that the current TCs are defining except for implementation.cpp
and implementation.c.

This should either be inclusive of all
of the implementation types being defined as part of 1.1 or just be a limited
set of example implementation types.

Proposal:  Either add implementation.cpp
and implementation.c or remove implementation.spring and implementation.ejb
in this paragraph.


4) Line 2115 lists Java interfaces as
being supported by SCA.

This suggests C++ classes and collections
of C functions for specifying interfaces are not supported by SCA to the
same extent that Java is.

Proposal: At least add C++ classes to
the list to solidify the view that SCA is not language specific.

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