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


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

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

Subject: Re: [sca-assembly] CD 01 review observations.


I recommend that you raise items 1) and 2)  as separate issues.

I also recommend that you raise 3) and 4) as an issue to avoid losing the material - it is basically editorial but without tracking it will get lost.

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

Bryan Aupperle <aupperle@us.ibm.com>

16/06/2008 18:54

[sca-assembly] CD 01 review observations.

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

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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