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.
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Tue, 17 Jun 2008 10:18:30 +0100
Bryan,
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
|
To
| sca-assembly@lists.oasis-open.org
|
cc
|
|
Subject
| [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]