Issues for Components RTF mailing list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 2204: Locality constrained objects + externalization
Issue 2227: Versioning needed for CORBA Core
Issue 2301: Locality-constrained objects
Issue 2611: Policies not locality-constrained?
Issue 2973: implementing import for C++
Issue 3060: Components Issues - Chapter 61 ptc/99-10-04
Issue 3062: Components Issues - Chapter 69 ptc/99-10-04
Issue 3063: Components Issues - Interface Repository ptc/99-10-03
Issue 3064: CCM Issue: Basic Level doesn't mention homes
Issue 3065: CCM Issue: CIDL Syntax doesn't allow for modules
Issue 3066: CCM Issue: Is a home needed?
Issue 3099: Should Components::Enumeration be an IDL interface or an IDL abstract value
Issue 3182: CCM Issue: How are standard EJB exceptions mapped into the CCM View
Issue 3183: CCM Issue: Is CCMObject::remove intended to be available to the CCM client?
Issue 3187: Do EJB-mapped attributes go to the ComponentDefault interface?
Issue 3189: What's the return type of CCM mappings of EJB finder and creator methods?
Issue 3190: How is CCMHome::get_home_def mapped to EJB operations?
Issue 3191: Is the ccm_home method shown in Table 8-1 a typo?
Issue 3197: Use of undefined "id" attribute
Issue 3198: Purpose of "name" element
Issue 3199: atribute not part of definition
Issue 3207: CORBA IR METAMODEL
Issue 3208: PACKAGING AND DEPLOYMENT METAMODEL
Issue 3212: 1. Should a session component have a way to save and restore its private st
Issue 3213: Implementation of get_component
Issue 3214: Registering homes outside of the container
Issue 3215: Federation of HomeFinders?
Issue 3216: New IDL keywords
Issue 3229: Components: Relationship of CIDL and PSDL unclear
Issue 3230: Components: readonly_attr_declarator slightly ambiguous
Issue 3232: Missing Rights Combinator in Security deployment descriptor
Issue 3233: IFR backward compatibility broken
Issue 3236: destroy() for local objects
Issue 3260: EJB/CCM mappings for the IR
Issue 3299: Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01
Issue 3412: CCM issue chapter 69 ptc/99-10-04
Issue 3418: USING Components::Enumeration
Issue 3419: Bridge Interoperability of the Java mapping with the EJB-to-CCM mapping
Issue 3645: Use of the type ComponentHome
Issue 3646: Document OMG ptc/99-10-04 p.615-87
Issue 3647: operation <string get_implementation(in string iuuid)>
Issue 3648: Why does not CCMHome include the operation create_component() ?
Issue 3649: p.615-85 ToonTownImpl
Issue 3650: In example p.615-86
Issue 3651: Where is HomeExecutorBase interface defined?
Issue 3652: CCM specification terms
Issue 3725: Issue On the use of typed home (or CCMHome subtypes)
Issue 3726: Issue on Assemblies and descriptors
Issue 3746: Pbl: Improper mapping rule from IDL3 to IDL2 when dealing with events.
Issue 3785: operation get_implementation() referenced but not declared
Issue 3786: What about valuetype factories?
Issue 3873: Implementation of extended CCM features
Issue 3925: range description in CPF files.
Issue 3926: simple ELEMENT definition
Issue 3927: Attribute exception definition
Issue 3928: Local push() operation.
Issue 3929: ExecutablePlacement definition
Issue 3930: exception raised by Components::Events::subscribe()
Issue 3937: Channel Setup for Emits ports.
Issue 3938: Intent of Components::Events::(un)subscribe to bypass the notif. service ?
Issue 3939: An assembly is always mono-vendor ???
Issue 3940: INS name ? where do we get them from ?
Issue 3954: equivalent interfaces issue
Issue 3955: push() versus push_event()
Issue 3977: Services available for a basic container
Issue 3982: Deployment Object Life Cycles
Issue 3985: description element need to be added to corbacomponent.dtd
Issue 3986: repository element needed by softpkg DTD
Issue 3987: typo in connections element definition
Issue 3993: CCM Events issue
Issue 3996: IDL question concerning CCM
Issue 3997: No user access to filterable body in CCM spec.
Issue 3998: No Access to event filter form component
Issue 4011: grammar rule for home_executor_body contradicts description
Issue 4024: Typo in assembly element paragraph heading
Issue 4025: New component issue: connection failure recovery
Issue 4073: Components, Facets, and Object References Unclear
Issue 4075: Inter-component type semantics unclear
Issue 4077: Component assemblies do not follow composition pattern
Issue 4078: Component assembly templates
Issue 4079: Component home polymorphism
Issue 4080: Component home interface inheritance
Issue 4081: Problems with the Components Notification Event Interface
Issue 4116: Extended Interface Repository
Issue 4136: ComponentIR Interface fixes
Issue 4140: Components FTF: TypeCodeFactory
Issue 4203: CCM : Session2Context and Servants
Issue 4204: CCM : Session2Context naming
Issue 4214: CCM: usage of the MOF profile
Issue 4269: IDL out parameters can't map to EJB?
Issue 4307: CCM: Chapter 66 should be removed
Issue 4329: "supports" terminology issue for CCM
Issue 4412: Component port introspection
Issue 4529: Incorrect syntax in Components::Enumeration
Issue 4540: explicit definition of CCM exceptions mapped from EJB standard exceptions
Issue 4574: Issue for Components: Missing language mapping
Issue 4575: Issue for components: No meta model for CIDL ?
Issue 4576: CCM: Isolated scope tokens
Issue 4577: CCM: Definition of import declaration unclear
Issue 4578: CCM: import and re-opening of modules
Issue 4579: CCM: Meaning of "exposed" scopes unclear.
Issue 4716: Little problem with introspection API
Issue 4717: minor IDL changes required in CCM API
Issue 4983: Generic operations for subscribing/unsubscribing at publishing ports
Issue 4986: IDL3 keyword "eventtype" conflicts with struct "CosNotification::EventType
Issue 5091: components-ftf: repository id in software package descriptor
Issue 5092: components-ftf: registercomponent element
Issue 5093: components-ftf: connectevent element
Issue 5340: Issue regarding language mapping for keyless homes
Issue 5429: simple type element of the property file issue
Issue 5492: Issues related to CCM's XML descriptors: chapter 69.4.4
Issue 5493: Issues related to CCM's XML descriptors: chapter 69.4.5.4
Issue 5494: Issues related to CCM's XML descriptors: chapter 69.4.5.16
Issue 5495: Issues related to CCM's XML descriptors: chapter 69.7.2.25
Issue 5496: Issues related to CCM's XML descriptors: chapter 69.7.2.38
Issue 5497: Issues related to CCM's XML descriptors: chapter 695.4
Issue 5498: CIDL Grammar problems: Productions must be renumbered : 134 -> 1, ...
Issue 5499: paragraph 60.2.1 : There is two mistakes in keywords
Issue 5500: Productions 140, 141, 142 and 143 must be removed
Issue 5506: Typo (??) in chapter 61
Issue 5507: 69.8.2 Property File XML Elements
Issue 5577: create operation of AssemblyFactory interface
Issue 5583: Remove section 4.4.1.4 in formal/02-06-65
Issue 5584: Corrections in XML DTDs for packaging
Issue 5585: Editorial issues in formal/02-06-65
Issue 5588: Update Table 5-13 in the EJB Chapter of formal/02-06-65
Issue 5683: Derived component supported interface restriction
Issue 5906: insufficient examples of component attributes
Issue 7902: sections 1, 3, 4, 5 essentially empty
Issue 7903: Section 7, Overview
Issue 7911: On Page 18 - Figure 11 Home mapping
Issue 7912: Section 7.2
Issue 7913: Minor comments re Components FTF
Issue 7914: use the proper notation for expressing Profiles
Issue 7915: Figure 1
Issue 7916: Section 7.1, line1:
Issue 7917: - Figure 2
Issue 7918: 7.2, sentence 3
Issue 7919: Section 8.1.1
Issue 7920: Sections 8.1.1, 8.2.1:

Issue 2204: Locality constrained objects + externalization (components-ftf)

Summary: Here"s an interesting question. How do you prevent the externalization of
   an l-c object? The user can create a reference to the l-c object *before*
   the l-c object has been bound to the POA itself. This means that the     
   reference can be externalized, and calls could presumably come into      
   the POA for this l-c object. What should the result of this call be?     
   OBJECT_NOT_EXIST?   
 

The only portable mechanism to implement locality constrained objects is LocalObject, which does not involve the
POA.

Summary: At present there is no formal mechanism or process for versioning the
 CORBA Core. Indeed, it is somewhat hard to figure out what is part of
 the CORBA Core. In Rev 2.3 we tried to at least bring all the IDL for
 the Core together in pieces at logical places, e.g. ORB interface,
 Object interface, IR Interfaces etc. In addition we also have the
 PortableServer module and the GIOP and related modules, the versions of
 all of which have to match for the resulting system to have any hope of
 working as advertized.  I guess the basis of the current state of
 affairs is that - the vendor delivers the core, and therefore one can
 trust the vendor to deliver the right things. This model tends to break
 down in situations where people can download bits and pieces of a Java
 ORB at different times and then try to make the whole thing work
 together. 
 

The general versioning problem could not be dealt with by the Components FTF
as it is too general and out of the scope of this FTF. However this should be the
subject of a future RFP issued both in the Platform and Domain Technical
Committees.
Let's note that the changes in the CORBA Core implied by the CCM are only
related to the OMG IDL grammar (i.e. new keywords and EBNF rules), the new
CORBA::Object::get_component operation, the Interface Repository and
CORBA::TypeCode interfaces. All other CCM APIs are defined in the separate
Components module.

Summary: something about locality-constrained objects... The spec says that LC objects
 are local, so I cannot pass reference to another process or use
 object_to_string with them. There are no other restrictions so, by
 implication, LC objects can do everything a normal object can do. In paricular,
 I can invoke operations on LC objects via the DII, I get preinvoke and
 postinvoke calls from a servant locator, and the reference for an LC object
 and its servant have independent life cycles.
 
 This seems rather strange.

The DII issues are covered in issue 3177.  The only portable mechanism to implement locality constrained objects is
LocalObject, so no servant locator is involved. LocalObject specifies that the reference and implementation lifecycles are
equivalent.

Summary: the current spec doesn"t list policy objects as locality constrained.
 This seems rather strange. In particular, at the time I create policy objects,
 there is no POA that could be responsible for them, and I have no way
 to associate a policy object with a particular POA.
 Of course, this raises the question of whether references to policy objects
 are persistent or transient, whether I can pass them to another address
 space, whether requests on them are single-threaded or not, etc, etc.
 

Section 11.1.5 of the components submission identifies the interfaces that are changed to local, including "all the
interfaces in the PortableServer module".  These changes will be incorporated into the CORBA 3.0 specification.

I'm concerned that for C++, implementing "import" as currently specified in
the Components spec will be extremely difficult.

Imagine how you might implement this: your IDL compiler generates a C++
header file for all imported name scopes and creates #include directives
for these files in the C++ code generated for the main IDL file. The main
problem is that importable name scopes are modules, interfaces, valuetypes,
structures, unions, and exceptions. To import an exception, for example,
the import mechanism would have to keep a dependency graph for that
exception type and make sure that all dependencies are generated into the
header file so the C++ compilation won't fail. This seems way too complex,
and I don't see the value of being able to import individual structs and such.

In Java the import feature is nothing more than a convenience (it allows types from other packages to be referred to using simple names, rather than fully scoped names); it is very similar to 'using namespace' in C++. The CCM import is indeed the same kind of beast: a convenience to avoid the use of fully scoped names when referencing types from other modules. 

A potential issue with the import specification in the Components specification is that it suggests that a CORBA3-compliant ORB should provide an interface-repository based IDL compiler, e.g.: (from ptc/99-10-03 p 3-19)) 

The definition of import obviates the need to define the meaning of IDL constructs in terms of "file scopes". 
[...] 
A specification that imports name scopes must be interpreted in the context of a well-defined set of IDL specifications whose union constitutes the space from within which name scopes are  imported. By "a well-defined set of IDL specifications", we mean  any identifiable representation of IDL specifications, such as an interface repository. The specific representation from which name scopes are imported is not specified, nor is the means by which importing is  implemented, nor is the means by which a particular set of IDL specifications (such as an interface repository) is associated with the context in which the importing specification is to be interpreted. 

Generating usable C++ code with such an IR-based IDL compiler would be a real challenge. But since CCM import does not specify that a compliant ORB implementation needs to provide such a tool, this is not an issue. 

A minor error in the CCM import spec is that import can refer to constructs that do not create scopes (struct, union and exception). This resolution fixes this bug. 

Now, regarding language mappings, the CCM-IDL import does not need to be mapped to anything (remember, it's just a convenience). 
For example if we have: 

module A 
{ 
   interface X {}; 
}; 

import A; 

interface B 
{ 
    void op(in X p); 
}; 

The C++ mapping for operation op could be 

virtual void op(A::X_ptr p); 

Another possibility in C++ is to map import <module_name> to using namespace <module_name>. And in Java, import <module_name> can be mapped to import <module_name>.*. Each language-mapping RTF will have to decide. 

	The following errors in the component model chapter 61 need to be fixed as
follows to align the IDL in the text with the final IDL published in
Appendix A (orbos/99-08-08).
	1. In IDL on page 46, section 61.6.3 add a “;” after 		expected_event_type.
	2. In IDL on page 43, section 61.5.3 replace 
		ConnectionList get_connections (in FeatureName name) 
				raises (InvalidName);
		with
		ConnectedDescriptions get_connections (in FeatureName name) 
				raises (InvalidName);
	3. In IDL on page 68, section 61.10.1.2 replace				
		valuetype ConfigValue {
			FeatureName name;
			any value;
		};
with
		valuetype ConfigValue {
			public FeatureName name;
			public any value;
		};

	The following errors in the deployment chapter 69 need to be fixed as
follows to align the IDL in the text with the final IDL published in
Appendix A (orbos/99-08-08).

	1. In IDL on page 330, section 69.9.2 replace two occurences of
		raises InvalidLocation;
		with
		raises (InvalidLocation);
		and one occurence of
		raises UnknownImplId;
		with
		raises (UnknownImplId);
	2. In IDL on page 331, section 69.9.3 replace one occurence of
		raises InvalidLocation;
		with
		raises (InvalidLocation);
		and two occurences of 
		raises InvalidAssembly;
		with
		raises (InvalidAssembly);
	3. In section 69.9.1.2 on pages 328 and 329, items 2 and 9 change
Installation to ComponentInstallation

The following errors in the interface repository chapter 10 need to be fixed.

	1. In IDL for interface HomeDef on Page 52 and Page 88: 
	   Remove the line: readonly attribute boolean is_basic; 
	2. In IDL for struct HomeDescription on Page 52 and Page 88: 
    	   Remove the line:  boolean is_basic; 
	3. In section 10.5.38.1 on page 53: Remove the paragraph that begins with: 
          "The is_basic attribute is TRUE if this is a basic home......."

 There is nothing in the FTF documents about leveling with
respect to homes. Basic CCM does not allow components to inherit from
other components. Why is there no similar restriction for homes?

The FTF draft does not allow a CIDL composition to be
included in a module.

Discussion: In the FTF Draft, the CIDL BNF (Section 60.3) is not yet
tied into IDL syntax. As it stands, a composition cannot be embedded
in a module. The draft recognizes that with the note (Section 60.4):

The CCM FTF draft document ptc/99-10-04 does not fully describe the CIDL
grammar, i.e. relationship between CIDL, PSDL, and IDL grammars,
compositions declared into modules.
CIDL is a language to describe compositions, i.e. the structure and state of
component implementations. In order to declare and refer state definitions, CIDL
is a superset of PSDL as stated in the orbos/99-07-01 document. Moreover CIDL
is also a superset of OMG IDL in order to refer home and component definitions.
Then the CIDL grammar must be a combination of the PSDL and IDL grammars
plus the composition rule.

Summary: The CCM FTF IDL chapter does not state whether a home must be
declared for a component. A home must have a component, but must a
component have a home?

Summary: Section 8.2.1.2 of the spec defines Components::Enumeration as an
IDL interface, with the implication
that it is intended as a remote type.

Issue: It has been noted that java.util.Enumeration is usually implemented
as a java.io.Serializable and that making
Components::Enumeration an IDL interface would prevent this from happening
for collections of primary keys returned
from EJB Homes that are mapped to CCM Homes.

Proposal: Define Components::Enumeration as an IDL abstract valuetype.

It has been noted that java.util.Enumeration is usually implemented as a java.io.Serializable and that making Components::Enumeration an IDL interface would prevent this from happening for collections of primary keys returned from EJB Homes that are mapped to CCM Homes.

Chapter 8 of the spec specifies mappings between EJB operations and their
equivalents in the CCM view, but it leaves the mappings of standard EJB
exceptions unclear.


Issue:
Create methods on an EJB home interface all throw the standard
javax.ejb.CreateException; finder methods on the EJB home interface all
throw the javax.ejb.FinderException; and remove methods on both home and
remote interfaces all throw the javax.ejb.RemoveException.  In a few cases
chapter 8 gives an implied mapping: for example, the FinderException on the
findByPrimaryKey method seems to map to either the
Components.UnknownKeyValue exception or to the Components.InvalidKey
exception on the equivalent find_by_primary_key CCM method.  Even in these
cases the names are sometimes inappropriate.  In the majority of cases,
however, there is simply no CCM equivalent to the EJB exception, and bridge
implementors are left to wonder whether they should attempt a non-standard
mapping.


Proposal:
     (a) Add the new CCM standard exceptions Components.CreationFailure,
Components.NotFound, and Components.RemovalFailure
     (b) Add Components.CreationFailure to the raises clause of all create
methods on implicit and explicit home interfaces
     (c) Add Components.NotFound to the raises clause of
find_by_primary_key on implicit home interfaces, and to the raises clause
of all finder methods on explicit home interfaces
     (d) Add Components.RemovalFailure to the raises clause on the remove
operation on implicit home interfaces, to the CCMObject.remove operation,
and to the CCMHome.remove_component operation
     (e) Specify in chapter 8 that the EJB Finder exception is always
mapped to Components.CreationFailure; that the EJB CreateException is
always mapped to Components.CreationFailure; and that the EJB
RemoveException is always mapped to Components.RemovalFailure.
     (f) Make explicit in chapter 8 the already implied mapping bewteen the
EJB DuplicateKeyException and the Components.DuplicateKeyValue exception

 Create methods on an EJB home interface all throw the standard javax.ejb.CreateException; finder methods on the EJB home interface all throw the javax.ejb.FinderException; and remove methods on both home and remote interfaces all throw the javax.ejb.RemoveException. In a few cases chapter 8 gives an implied mapping: for example, the FinderException on the findByPrimaryKey method seems to map to either the Components::UnknownKeyValue exception or to the Components::InvalidKey exception on the equivalent find_by_primary_key CCM method. Even in these cases the names are sometimes inappropriate. In the majority of cases, however, there is simply no CCM equivalent to the EJB exception, and bridge implementors are left to wonder whether they should attempt a non-standard mapping. 

Section 5.12.1 of the spec can be interpreted to mean that the
CCMObject::remove call is not intended for use by CCM clients; but this is
inconsistent with the EJB/CCM mapping given in chapter 8.


Issue:
The explanation given for the CCMObject::remove call in section 5.12.1 is:
     "This operation is called when a component is about to be destroyed.
The component
     can perform any cleanup processing required (e.g. releasing resources)
 prior to its
     destruction."
This explanation can be interpreted to mean that the call is a private call
 from a CCM container to one of its components; if it has this internal
purpose then it might not be
intended for use by CCM clients wanting delete the component.  However,
table 8-1 shows that the CCM view of an EJB maps this call to the
EJBObject.remove()
method. This implies that the method is intended for client use as the
EJBObject.remove() is.  If so, then it also makes more sense to implement
the
CCMHome::remove() method in terms of the EJBObject.remove() method, rather
than the current mapping which requires an EJB Handle.


Proposal: (a) Change the text for remove() in 5.12.1 to say: "This
operation is used to delete a component".
     (b) Change the mapping in table 8-1 for CCMHome::remove to use
EJBObject.remove

: The explanation given for the CCMObject::remove call in section 5.12.1 is: "This operation is called when a component is about to be destroyed. The component can perform any cleanup processing required (e.g. releasing resources) prior to its destruction." This explanation can be interpreted to mean that the call is a private call from a CCM container to one of its components; if it has this internal purpose then it might not be intended for use by CCM clients wanting delete the component. However, table 8-1 shows that the CCM view of an EJB maps this call to the EJBObject.remove() method. This implies that the method is intended for client use as the EJBObject.remove() is. 

When mapping EJB set/get methods to a CCM view, it is not clear whether the
resulting IDL attributes belong on the ComponentDefault interface or on the
component definition itself


Issue:
Set/get method pairs on the EJB remote interface map to IDL attributes, but
do these attributes end up in the XXXDefault interface or in the XXX
component definition?  Section 8.2.1.2 of the specification seems to imply
they belong in the XXXDefault interface, but section 5.3.2 says the
component definition for a basic CCM "shall only contain zero or more
attribute declarations", which suggests that attributes of a CORBA
Component belong in the component definition.   Also, the mapping in the
other direction (EJB view of a CCM), described in 8.3.1, suggests that CCM
attributes are always found in the component definition itself.  It appears
that both versions will work, but this point is worth clarifying.


Proposal:
Change 8.2.1.2 to say that all EJB set/get method pairs are mapped to IDL
attributes on the component definition itself.

Set/get method pairs on the EJB remote interface map to IDL attributes, but do these attributes end up in the XXXDefault interface or in the XXX component definition? Section 8.2.1.2 of the specification seems to imply they belong in the XXXDefault interface, but section 5.3.2 says the component definition for a basic CCM "shall only contain zero or more attribute declarations", which suggests that attributes of a CORBA Component belong in the component definition. Also, the mapping in the other direction (EJB view of a CCM), described in 8.3.1, suggests that CCM attributes are always found in the component definition itself. It appears that both versions will work, but this point is worth clarifying. 

Summary:

8.2.1.2 of the CCM specification says that EJB finder and creator methods
which return an RMI object reference are mapped to methods which return a
Components::CCMObject reference.  It is unclear whether the actual base
class CCMObject is intended or whether the specific component subclass
(e.g., Widget) is intended.   The specific subclass seems more sensible,
and is consistent with the equivalent IDL mappings shown in section 5.8.4.

Proposal:

Change 8.2.1.2 to make it clear that the specific subclass (e.g., Widget)
is the return type.

Chapter 8 omits to mention how the CCMHome::get_home_def call is mapped by
the bridge at runtime to an EJB operation.


Issue:
The very similar call CCMHome::get_component_def is shown as mapped to the
EJBHome.getEJBMetaData operation, but there is no mapping shown for
CCMHome::get_home_def.  It appears that get_home_def could be also be
implemented using the EJBHome.getEJBMetaData operation, and if necessary,
with the help of Java introspection.


Proposal:
Add a line in Table 8-1 to show CCMHome::get_home_def mapped at runtime to
EJBHome.getEJBMetaData.

The very similar call CCMHome::get_component_def is shown as mapped to the EJBHome.getEJBMetaData operation, but there is no mapping shown for CCMHome::get_home_def. It appears that get_home_def could be also be implemented using the EJBHome.getEJBMetaData operation, and if necessary, with the help of Java introspection. 

Table 8-1 shows a mapping for CCMObject::get_home.  It looks like it should
say CCMObject::get_ccm_home


Proposal:

Change "CCMObject::get_home" to "CCMObject::get_ccm_home" in Table 8-1.

I have a number of issues with the Software Package Descriptor section of
the CCM specification (Component Spec - Volume I, orbos/99-07-01.) I have
not found answers to issues raised below in either the components-ftf
archive, or the issues list.

ISSUE - The softpkg descriptor example uses an "id" attribute, which isn't
defined in the softpkg.dtd.

>From page 10-305, 10.2.1 A softpkg Descriptor Example, CORBA Components -
orbos/99-07-01:

	<idl id="IDL:M1/Bank:1.0" ><link href="ftp://x/y/Bank.idl"/></idl>

According to the softpkg.dtd, (page B-435, B.1 softpkg.dtd, CORBA Components
- orbos/99-08-05, ) the idl element is defined as follows:

<!ELEMENT idl
	( link
	| fileinarchive
	| repository
	) >

The same definition can also found in section 10.2.2.14, The idl Element (,
page 10-311, CORBA Components - orbos/99-07-01.) There are no attributes
defined for the idl element.

In ptc/99-10-04 section 69.3.1 page 69-260, the following
<idl id="IDL:M1/Bank:1.0" ><link href="ftp://x/y/Bank.idl"
/></idl> describes what the repository Id is and where the IDL file is located for the
softpkg descriptor example.
Require to add "id" to the list of attributes of the "idl" element in the softpkg XML
DTD.

ISSUE - What is the purpose of the "name" element as used in the
"dependency" element?

See section 10.2.2.7, The dependency Element (, page 10-308, 10.2.1 A
softpkg Descriptor Example, CORBA Components - orbos/99-07-01.) Section
10.2.2.20, The name Element, describes the name element as an optional
element of the "author" element, and is meant to identify the author. So
does the name element identify the author of the dependency, or is it used
to identify the dependency itself?

Resolution:
Require to update the text describing the name element of the softpkg XML DTD
as this element is an optional child element of both the author and dependency
elements. When used as a child of author, it specifies the name of the author.
When used as a child of dependency, it specifies the expected value of the
dependency.

ISSUE - The description of the "implementation" element explains the
"variation" attribute, but the attribute is not part of the definition. 

>From page 10-32, CORBA Components - orbos/99-07-01: "The variation attribute
is used to indicate a variation from a normal implementation." But the
definition of the implementation attribute list only lists the "id"
attribute. The variation attribute is not part of the definition as given in
softpkg.dtd either (, page B-419, B.1 softpkg.dtd, CORBA Components -
orbos/99-08-05.)

Require to add "variation" to the list of attributes of the "implementation" element
in the softpkg XML DTD.

1) The isBasic Attribute needs to be removed from HomeDef to synchronize
with the regular CORBA IR.

Resolution: Remove isBasic attribute from HomeDef in the metamodel and regenerate the XMI and IDL for the metamodel.  Theoretically the generated code can be hand-modified to remove artifacts generated from the isBasic attribute of HomeDef, but this is a dangerous practice and is not recommended. 

1) Some concepts from the CORBA metamodel (component, facet, receptacle,
event publishing/emission/consumption) are also in P/D metamodel but the
definitions from the CORBA metamodel are not directly reused.  

Recommendation: Analyze where reuse is appropriate and adjust the P/D
metamodel accordingly.

2) The P/D metamodel has the notion of files (e.g. configuration property
files and some other files) where some metadata are stored.  The hand-coded
DTDs treat these files as types in their own right, i.e. they conceptualize
them as files, and some of the other types point to the file types.  This
is approach is mimicked in the metamodel.  However, it might not make sense
in the metamodel because, in a repository context, you are referencing
other information in the repository and not necessarily a file.   The way
the metamodel is now, when something references one of these files you lose
the metadata trail.  The file metaclass itself does not have structural
features pointing to metaclasses that define the contents of the file.  You
have to go elsewhere (i.e. to the property file Package) to get that
metadata and there is no reference to the property file Package.

Recommendation: It might make more sense for references to the file
metaclass to instead reference the top level element of the property file
Package so that you can "follow the metadata trail." If someone wants to
break out the properties metadata in a file, then the generated DTD should
allow that, i.e. the part that needs to go into a properties file should be
able to be self-contained without external references.

This issue points out only two problems of the packaging and deployment model.
There are lot of other problems and there are lots of inconsistencies between the
meta model and the deployment descriptors. For this reason, it is better to
remove the Packaging and Deployment meta model and to address this by a
future RFP process.

1. Should a session component have a way to save and restore its private state? 
	Problem: The current component specification provides no way for the component programmer to explicitly save and restore its private state for session components.

Since basic components do not participate in creating references, there is no way for them to control saving and restoring of their state. Extended components already have the required operations. No change is required. 
Revised Text: No change. 

2. Implementation of get_component with separate ORB and component vendors 
	Problem: A design goal of the components specification was to permit the component container to be provided by a different vendor than the ORB vendor. When this is true, how does the implementation of get_component work?

Resolution: A CORBA 3.0 ORB must implement get_component even if it does not provide an implemention of CORBA components and therefore, a CCM implementation from any other vendor can rely on a get_component implementation being available. 

Problem: The current specification does not provide an interface for registering homes that can be used outside of the container. Should it?

Homes cannot be registered outside the container, since HomeFinder are not federated (see resolution of issue 3215). This means that the scope of a HomeFinder is a single CCM implemementation. Clients may use the Naming Service instead, which is federated. 

Problem: Can home finders be federated?

Problem: The new IDL keywords use mixed case, rather than the lower case style used by current keywords. Should the new keywords be changed to comply with the existing style?

The draft component specification (ptc/99-10-04) explains that CIDL is
a superset of IDL. This is a derivation from the specification
voted-on in the PTC (orbos/99-07-01), which specified that CIDL is a
superset of PSDL.

Also, declaring CIDL not to be a superset of PSDL means that the
<catalog_use_dcl>, <abstract_storage_home_binding> etc become
meaningless, as they refer to entities from PSDL.

Proposed Resolution: Declare CIDL to be a superset of PSDL.

In ptc/99-10-04, the production 104

<readonly_attr_declarator >::= 
    <simple_declarator> [ <raises_expr> ] 
  | <simple_declarator> { "," <simple_declarator> }*

is ambiguous, since a sole <simple_declarator> could either denote the
first alternative (with no <raises_expr>), or the second alternative
(with the simple-declarator-list omitted). Even though this does not
constitute a serious problem, it is also easy to fix:

<readonly_attr_declarator >::= 
    <simple_declarator> <raises_expr>
  | <simple_declarator> { "," <simple_declarator> }*

The production 104 is ambiguous and is replaced by the rule provided by the
issue submitter.

In section 69.4.5.45, the "rights" element is mentioned, but the "rights
combinator" elemnt is not. Given a set of "rights" it is not possible to
determine how to cobine them without the "rights combinator" as specified in
CORBAsec. Suggest we add a "rights cobminator" element, consistent with the
definition of rights combinator in CORBAsec.

The CCM FTF draft document ptc/99-10-04 does not provide the required
information needed to set the required rights for an operation since the rights
combinator is missing. A rightscombinator attribute must be added to the
security element of the CORBA component descriptor DTD.

Moving existing interfaces from the CORBA module to a new IR module breaks
backward compatibility. Hence they should be moved back to the CORBA module. The
elements that are newly added can go into a new module, and interfaces
corresponding to the existing ones with the same names can be placed in the new
module, with these interfaces deriving from the existing corresponding
interfaces in the CORBA module, thus allowing all CORBA3 IR interfaces to be
accessed from a single module.

This also fixes a related problem regarding separation of the TypeCode stuff,
specifically TypeCode factory. It is broken in the current spec because certain
types used by the typecode factory were inadvertently moved to the IR module.

Resolution:
The Interface Repository interfaces are moved back to the CORBA module to not
break backward compatibility. New OMG IDL constructions introduced by the
CCM, i.e. home, component and ports, are reflected by new OMG IDL interfaces
contained in the new CORBA::ComponentIR module.
The last draft of the CORBA Chapter 10 "The Interface Repository" is available in
OMG TC Document # ccm/2001-08-01 and the full OMG IDL is available in OMG
TC Document # ccm/2001-08-02.

every ORB I know of implements the various destroy() operations on
local objects (such as policies or DynAny) as a no-op and destroys the local
object on the final call to release() instead. Yet, the spec still requires
programmers to call destroy(). The problem with this is that programmers
can easily end up writing non-portable code without any visible problem.
Then, when code is moved to another ORB, it is conceivable that it will
leak objects.

This isn't very pretty. I think we should get rid of the destroy() calls
on local objects (possibly with the exception of the ORB object, although
the entire shutdown issue for that is quite a mess anyway). It doesn't
make sense to require the programmer to make a destroy() call for something
that naturally can be reference counted.

When the interfaces identified in section 11.1.5 are updated to be local interfaces, any destroy() operations should
be deprecated using the text below.  Note that this does not include CORBA::ORB.

The mapping between EEJB metadata and the IR is missing in the
current specification .Resolution: Define the mapping

Given that the information needed to implement the EJBMetadata interface for a
given EJB (in particular, for one that is the mapping of a CORBA Component) is
available from the Java runtime, it is not necessary to define a mapping between
EJB metadata and the IR. That is, for the purposes of implementing
EJBMetadata, which is the only concern in this issue, a mapping between EJB
metadata and the IR is not required. An example of this implementation involves
looking up class information in the classpath for the EJBMetadata methods that
require this information (getHomeInterfaceClass, getRemoteInterfaceClass,
getPrimaryKeyClass), and caching information obtained at generation time for
the remaining EJBMetadata methods (getEJBHome, isSession and
isStatelessSession).

Document orbos/99-08-13, line 9 and further, contradicts with
orbos/99-07-01,
Chapter 4.4. The production rules for typePrefix and typeId contain a
";",
where file orbos/99-08-13 omits them.

Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01,
Chapter 4.2. The production rules for import contain a ";",
where file orbos/99-08-13 omits them.

Resolution:
Require to add ';' at the end of lines 1-6 and 9 in orbos/99-08-13 in order to be
compliant with the CCM specification (ptc/99-10-03) and to replace typePrefix by
typeprefix (see Issue 3216).

What exactly is meant in chapter 69.7.2.3 by component archive file? It is
not defined anywhere. Is it a software package descriptor or a software
package? At least it is not a CORBA component descriptor as shown in the
example in chapter 69.7.1. The text there is like:

<componentfile id="A">
    <fileinarchive name="ca.ccd"/>
...

Is the sufix ccd right?

Resolution:
The referred file has to contain a SoftwarePackageDescriptor in order to get
information about actual implementations. Thus the example at the beginning of
69.7.1 must be changed. The suffix ccd must change to “csd”.

It is probably not a good idea to mandate an implementation for
Enumeration, since there may be different options for implementing.
For example, it may be desirable for
performance reasons to implement a form of lazy Enumeration that does
not carry with it every element that it can contain, but requiring
this kind of implementation can be overkill for some
applications. Given this, Enumeration is defined as an abstract
valuetype and at least one concrete specialization of it is
required. In addition, FOR INTEROPERABILITY, at least one STANDARD
implementation must also be provided so that client stubs and server
skeletons know how to marshal and unmarshal Enumeration values.

Resolution: Require that one standard concrete implementation of Components::Enumeration be included. This implementation shall specialize Components::Enumeration by defining a sequence of CCMObject as its private state, and by implementing the methods has_more_elements and next_element in terms of this sequence. 

he following sub-issues need to be addressed to make sure that CCM/EJB
bridge implementations are interoperable. In particular, these sub-issues
have in common that the current definition of the bridge relies on the
Java-to-IDL mapping, which in certain cases does not match the requirements
of the EJB-to-CCM mapping.

Sub-issue: METHOD NAMES IN STANDARD INTERFACES

The names for some methods defined on standard interfaces, for example
<home-name>Implicit.find_by_primary_key or <home-name>Implicit.create,
differ from the names that their EJB counterparts get mapped to under
Java-to-IDL (in the example these would be
<home-name>.findByPrimaryKey and create__keytype, respectively). When
this happens, the translation from one form of the name to the other
can happen at either the client or the server side of the bridge. FOR
INTEROPERABILITY, it is necessary to eliminate this ambiguity. Choices
for doing this include requiring the client stub to always do the
translation or requiring the server skeleton to take into account both
name forms.

The actual problem we are getting hit by here is overloaded names. Methods
like remove and create in EJBHome and user-defined EJB homes can only be
mapped to remove__XXX and create__XXX under Java-to-IDL, yet the
definitions of the corresponding methods in <home-name>Implicit are remove
and create, respectively. I can understand that these implicit home names
were defined as such because <home-name>Implicit is a standard interface
(although the fact that its name is prefixed by <home-name> is a bit
troubling) and, if for no other reason, because the XXX in create_XXX
cannot be known in general. So, if we stick to the standard names, there is
a mismatch. Notice however that I said that the mapping is done under
Java-to-IDL. Perhaps I should not say that but the CCM spec is not clear
about this and in fact it states that the create methods in an EJB home are
mapped to factory names under Java-to-IDL. So we may actually be talking
about two different issues: (1) use different mapping rules for create with
no primary key, in which case we need to ammend the spec to this effect;
(2) perform a translation, in which case we have an interoperability issue.

Sub-issue: HANDLING STANDARD EXCEPTIONS

Standard exceptions thrown by EJB methods, such as
DuplicateKeyException, have a mapping specification to IDL (under the
current Java-to-IDL specification) that does not match the exceptions
that they map to under the CCM spec (in the example this would be
DuplicateKeyValue). This requires that the bridge perform a run-time
translation of exceptions from the Java-to-IDL mapping to the CCM
mapping at either the client stub or the server skeleton. FOR
INTEROPERABILITY, it is further necessary that the location of the
translation be fixed. Early prototype implementation suggests that it
is more advantageous for the client stub to perform the translation
since otherwise the server skeleton would need to know what kind of
client it is talking to: a CCM client or an EJB client. A larger issue
that this falls under is the reconciliation of the Java-to-IDL mapping
with the EJB-to-CCM mapping. If and when the larger issue is resolved,
this issue would largely disappear.

This also falls under the Java-to-IDL mismatch. Our choices seem to be: (1)
define the standard exceptions, e.g. Components::DuplicateKeyValue, as if
they had been mapped from Java under Java-to-IDL, (2) map the exceptions
from Java under rules different from those on Java-to-IDL; (3) perform a
translation. Choice (1) may be too intrusive but it could be rationalized
with a "integration with EJB" argument. Choices (2) and (3) are similar to
the above.

Sub-issue: PASSING A PRIMARY KEY PARAMETER

A number of methods defined by standard interfaces, such as remove
defined by EJBHome, include in their signature a primary key value and
define its type to be java.lang.Object, which under RMI-IIOP is mapped
to CORBA::Any. Since the primary key is actually an object passed by
value and thus mapped to an IDL value type, a run-time translation
must be performed from the value type to Any and viceversa whenever a
method that includes a primary key is called. FOR INTEROPERABILITY, it
is necessary that the location of this translation be fixed. Choices
for doing this include requiring the client stub to always do the
translation or requiring the server skeleton to take into account both
a value or an Any that could possibly be coming from any given
client. In additon, if a primary key is returned it may be more
advantageous for the client to perform this translation, since the
server skeleton may not know what form the client is expecting.

Here again the problem is that, under Java-to-IDL, java.lang.Object gets
mapped to ::java::lang::Object (not CORBA::Any actually, as per the actual
Java-to-IDL I am looking at) for methods like EJBHome.remove, whereas the
key is expected to be passed as a value type. So the choices seem to be:
(1) use rules other than those in Java-to-IDL for the mapping or (2)
perform a translation.

Require that client or server stubs of home and remote interfaces for both
CORBA Component views of EJBs as well as EJB views of CORBA Components
include the necessary code to perform the translations outlined in the summary.

1. In the document OMG ptc/99-10-04 p.69-329 there is in item 5 a use
   of the type ComponentHome, shouldn't it be CCMHome? If I do recall
   correctly, ComponentHome was used in the first versions of the
   specification proposal.

. 

2. Document OMG ptc/99-10-04 p.615-87. In the last paragraph of the
   illustrative example, it is said that: "The implementations of
   operations for navigation, executor activation, object reference
   creation and management, and other mechanical functions are either
   generated or supplied by the container." 
   Don't you think this is dangerous in a multi vendor context? Let say 
   a component implementation rely on the container to provide these 
   operations. What will happend if this component is deployed in a
   container which considers that component implementations include
   the generated code providing these operations? (Same feeling as in
   remark 2.)

 Since we don't guarantee portability for non-Java languages, component binaries will need to be tailored to hardware platform, compiler, and ORB/container provider. To be deployed in a different container, a new binary is likely to be required, which will take care of the difference between provided and generated code

3. Why isn't the operation <string get_implementation(in string iuuid)>
   defined in the interface ComponentInstallation while being used in
   ptc/99-10-04 p.69-329 item 9? (Where Installation should be
   replaced by ComponentInstallation don't you think?) Moreover, this
   operation is required for an Assembly to find the location of a
   component implementation in order to load it in a container.

The section 69.9 of the ptc/99-10-04 document does not define the signature of
the required get_implementation operation. Moreover this section refers to the
Installation interface instead of the ComponentInstallation interface.
The section 69.9 of the ptc/99-10-04 document must be replaced by the content
of the ccm/2001-10-03 document defining the signature of the
get_implementation operation and replacing all occurrences of the Installation
interface by the ComponentInstallation interface.

4. Why does not CCMHome include the operation create_component() ? I
   understand that a component created by a home with keys should not
   offer this interface, however according to the exemple in the spec
   Container operation install_home() returns a CCMHome, thus how
   could a component be created in this context? Does it imply that
   you know if the home is keyless or not, thus narrowing it before
   use? Don't you find strange to have the remove operation but not a
   default create in the CCMHome interface?

Clients could invoke the remove_component operation of the CCMHome
interface without requiring to know if the home has or has not an associate
primary key.
In order to create a component from a CCMHome instance, the caller must know
if the home has or has not a primary key. Moreover for keyed homes, the caller
must know what the home’s primary key type is, in order to create a primary key
value. This knowledge is obtained statically if the caller knows explicitly the
concrete home interface, or dynamically via the Interface Repository for instance.
If the home has no primary key, the caller could invoke the
Components::KeylessCCM Home::create_component operation to create a
component. If the home has a primary key, the caller should create a primary key
value according to the home’s primary key type, and should invoke the create
operation of the equivalent implicit interface of the called home. A dynamic caller
could invoke this latter operation via the DII.
Adding a generic create_component operation for keyed homes could only
resolve a part of the problem for dynamic clients: They always need to obtain
dynamically the primary key type in order to create a primary key value. As these
two knowledge could already be obtained simultaneously by introspecting the
associate CORBA::ComponentIR::HomeDef object, this issue should be closed
with no change.

5. Even if it is _only_ an example, p.615-85 ToonTownImpl implements
   ExecutorSegmentBase, shouldn't it be HomeExecutorBase?

In ptc/99-10-04 chapter 615 example 1, ToonTownImpl is the skeleton executor
implementation class for the home ToonTown. Then this class must implement
the HomeExecutorBase interface instead of the ExecutorSegmentBase interface.

6. In example p.615-86, shouldn't myToonImpl extends ToonSessionImpl
   (presented in the previous pages) instead of ToonImpl (which is not
   defined)? The same classname is used in pages 96-98, but it seems
   correct in this case. 

In ptc/99-10-04 chapter 615 example 1, myToonImpl is the user-provided
executor implementation class for the component executor ToonSessionImpl.
Then this class must inherit from the generated ToonSessionImpl class instead
of the non defined ToonImpl class.

7. Where is HomeExecutorBase interface defined? I only saw it used in 
   the packaging and deployment model. If it is a standard interface
   which is returned (how could it be non standard), shouldn't it be
   defined somewhere? (Same remark for ExecutorSegmentBase
   interfaces. It may be defined in the last Components.idl, but I did  
   not find one more recent than orbos/99-08-13.)

The interface HomeExecutorBase is defined in the Language Mapping Chapter.
See the resolution for issue 4574.

In the first versions of the CCM specification terms such as
ComponentBAse, ComponentHome, ... have been used. More recently these
terms have been changed to CCMObject, CCMHome... Shouldn't all the
interfaces of the ccm module be changed this way in order to be
homogeneous in their naming?

Why is there CCMContext (with CCM prefix) and SessionContext without
CCM prefix ?  

Thus SessionComponent, EnterpriseComponent, SessionContext, ... would
become CCMSessionObject, CCMEnterpriseObject, CCMSessionContext ...

: No, interface names were changed to conform to the style used by EJB. E.g. CCMObject is analgous to EJBObject, CCMHome is analogous to EJBHome, SessionComponent is analagous to SessionBean, not EJBSessionBean. 

When a component type is implemented, it inherits a specialized
interface for callback functions, for example SessionComponent. In
this context, why should home implementations be unspecialized? Using
a specific home type, deployment could be improved when performed in a 
multi-actor context. As the cooperation between containers and homes
is unspecified, using multi-actors components seems unreachable. One
particular aspect is how the container <Context> interface si provided 
to the component instance. Using a well defined specialized home
interface would solve this problem easily. Thus, avoiding the use of 
wrappers for example which are another solution, but far more complex.
Such an interface should be defined for each component type category. 

As an example the following interface could be a basis for session
component homes. (there must be other operations to add here, but I
have not foudn them yet.)

interface SessionCCMHome : CCMHome { // or CCMHomeKeyless

    void set_session_context ( in SessionContext sc ) ;

};

A home has no use for a SessionContext reference. It is the container’s
responsibility to set the context value on component executor segments that
implement the SessionComponent interface. Adding a HomeContext interface
that provides useful information to a home (e.g. the home’s reference) is out of
the scope of this issue.

Looking a the <Assembly> interface, a question arises. When providing
the assembly descriptor location, a logic description of the
application to deploy is provided. But, how are set the pysical hosts
to be used for the deployemnt of the logic configuration? No hooks is
provided to the deployment tool (as there are no interfaces for the
tool) in order to provide these information, and no operation is
available on the assembly interface to do so. Is there an extension of 
the <Assembly> interface in order to contain this information?
Otherwise, how could the application be deployed?

Thinking about what should be provided, it is necessary to assign a
logical name contained in the assembly descriptor to a physical host
name. Maybe an extension to the assembly descriptor filled at
deployment time is the solution? The second possible choice crossing
my mind is an IDL structure (in fact sequence of structure) that could 
be provided to the assembly object.

In the Component Assembly Descriptor XML DTD, the destination element
should be used to fix the physical placement of homeplacement, executable
placement, hostcollocation, or processcollocation elements (see
section 69.7.2.18 page 69-309). To deploy a component assembly, a deployment
tool must provide to an Assembly object a copy of the logical assembly
descriptor where all destination elements are set with the expected physical
placement (see the note in ptc/99-10-04 section 69.7.2.1 page 69-303).

Dealing with the following IDL3 definition, a problem arises when
generating the IDL2 definitions (complete IDL2 mapping is enclosed at
the end of this mail).

    module example {
      valuetype AnEvent : Components::EventBase {
        public string value;
      };

      component Producer {
        publishes AnEvent output;
      };
    
      component Consumer {
        consumes AnEvent input;
      };
    };

According to the chapter 5 of the CCM specification, the publishes
definition of the Producer component is mapped to the following
definition (excerpt).

    interface Producer : Components::CCMObject {

      Components::Cookie 
      subscribe_output(in ::example::ProducerEventConsumers::AnEventConsumer consumer)
        raises (Components::ExceededConnectionLimit);

    };	

In the mean time, the consumes definition of the Consumer component is 
mapped to the following definition.

    interface Consumer : Components::CCMObject {

      ::example::ConsumerEventConsumers::AnEventConsumer 
      get_consumer_input();

    };

We can see that two versions of the "AnEventConsumer" interface have
been defined in two distincts modules. Thus the following Java
lines are not correct:


    example.Producer p = ...;
    example.Consumer c = ...;

    p.subscribe_output(c.get_consumer_input());

The Java compiler will refuse to compile the last one, producing an
error like "BadTypeCoerce". However, in the IDL3 definitions, both
components have been defined in order to be used together. (sic!)

Thus, we think that the mapping for a Consumer should not be based on
the component definitions, but on the event definition itself. It
would then avoid multiple (incompatible) definitions of the consumers.
This mapping could be defined in two distinct ways.

Add the new eventtype keyword in OMG IDL to define event types.
. Add the CORBA::ComponentIR::EventDef interface to reflect eventtype
definitions into the Interface Repository.
. Add the new EventDef metatype in the OMG IDL metamodel. This metatype
only inherits from the ValueDef metatype.
. Define component client view mapping rules to translate IDL3 eventtype
definitions to IDL2 valuetype definitions.
. Change component client view mapping rules for event port definitions to
IDL2 event consumer interfaces. The new mapping rules are event type
oriented instead of event port oriented.

In chapter 69.9.1.2 Deployment Scenario on page 329 of ptc/99-10-04.pdf the
operation get_implementation() is refered as if it belongs to the
ComponentInstallation interface (called only "Installation"), but the
specification of that interface lacks it.

What about <i>valuetype factories</i>?

<p>In the context of a component dealing with events, the aspect of 
<i>valuetype</i> factories has not been really mentionned in the spec, 
especially in the deploiement process. 
If I am right, dealing with <i>valuetypes</i> in a program means to 
instantiate and to register a factory for this <i>valuetype</i> to the 
ORB. In the context of the CCM, a component and its home is installed
into a generic container which may not know the <i>valuetype</i>. 
Thus, the <i>valuetype factory</i> may have to be installed at
deployment time. </p>
<p> According
to the similarity in the <i>home</i> and <i>valuetype factory</i>
concepts, it may be a good solution to add an entry in the CORBA
Component Descriptor OSD file to define the <i>valuetype factory</i>
(which would have to be included in the component package) required by
the component as well as to define a standard name scheme for their
entry points. Here is an draft example of what it could look
like. Relationships / dependencies between components and <i>valuetype 
factories</i> also have to be introduced.</p>  

<!--
<softpkg>
  ...
  <implementation id="...">
    ... all the environment stuff ...
    <descriptor type="Event Factory">
      <fileinarchive>...</fileinarchive>
    </descriptor>
    <code type="DLL">
      <fileinarchive name="bank.dll" />
      <entrypoint>createEventFactory</entrypoint>
    </code>
  </implementation>
  ...
</softpkg>
-->

<p><tt>&lt;softpkg>
<br>&nbsp; ...
<br>&nbsp; &lt;implementation id="...">
<br>&nbsp;&nbsp;&nbsp; ... all the environment stuff ...
<br>&nbsp;&nbsp;&nbsp; &lt;descriptor type="Event Factory">
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;fileinarchive>...&lt;/fileinarchive>
<br>&nbsp;&nbsp;&nbsp; &lt;/descriptor>
<br>&nbsp;&nbsp;&nbsp; &lt;code type="DLL">
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;fileinarchive name="bank.dll" />
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;entrypoint>createEventFactory&lt;/entrypoint>
<br>&nbsp;&nbsp;&nbsp; &lt;/code>
<br>&nbsp; &lt;/implementation>
<br>&nbsp; ...
<br>&lt;/softpkg></tt></p>

<p>The second solution could be to include the code for <i>valuetype
factory</i> creation in the <i>home</i> implementation, which mean
less specification: "The home has to install any valuetype factory
required by the component." would be enough. However, this second
approach may not be as much portable as the first one (as long as a 
<i>home</i> may be portable between containers, which IMHO should be
possible).</p> 

There are two problems involving valuetype factories. The first is in connection
with events as identified by the author in that there is no straightforward way to
register valuetype factories for events in a generic container. The second
problem is similar to the first in that there is no straightforward way to register
primary key valuetype factories for entity component homes nor is there a
mechanism to specify the state for a primary key that is required to create an
entity component. The solution to the first problem (and part of the solution for
the second problem) is to add a valuetypefactory ELEMENT in the software
package DTD and modify the description of the dependency ELEMENT in the
description of the software package descriptor to explicitly include handling of
valuetype factories. The solution to the second problem requires the addition of a
valuetype ELEMENT in the properties DTD so that the state for the primary key
of an entity component can be specified and identified.

This section indicates that the Language Mappings are to be provided as errata. I have searched high and low in the OMG web site to find these mappings and have not found a single bit of info on them. I need these mappings to accurately design and implement the extended CCM features.

The definition for "choices"  is as follow in the properties.dtd file:

<!ELEMENT choice ( #PCDATA ) >
<!ELEMENT choices ( choice+ )

knowing that the PCDATA for choice is supposed to hold one possible value
for the "simple" if I am right

I believe this is missing a bit of descriptive power. In case you want to
specify a range of 100 values you will have to give the 100 different values
each in its own "choice" element. It is very verbose !!!

We could add a range ELEMENT to the DTD as follow:

<!ELEMENT range (value, value)>

We could then change the choices ELEMENT as follow:

<!ELEMENT choices ( range | choice )+>

Any thought.

The choices ELEMENT in the properties DTD is restrictive and may result in
verbose properties descriptors and ultimately affect efficiency and performance.
Therefore, a range ELEMENT should be added to the properties DTD to allow a
choice between a single simple property value or a range of simple property
values.

I have a question about the property.dtd file provided with the CCM spec.

in this file "simple" is described as follow:

<!ELEMENT simple
( description?
, value
, choices?
, defaultvalue?
) >

This seems to indicate that a "simple" element has to have a value in the
file. Therefore it is not clear how usefull is the optional "defaultvalue"
field. It also means that if the component or assembly provider wants to
provide the CPF files with the CCD and CAD files it has to put values into
them instead of just setting the default value. Obviously the best thing to
do would be to repeat the default value into the value but it seems strange
to me. The point is that if there is a default value provided the value
doesn't seem to be mandatory.

Also, in a way similar to the CAD file, where placement information are
added at deployment time, we may want to enable the component/assembly
provider to provide CPF skeleton files together with the CCD files and
skeleton CAD files. In this case the "simple" element may not contain any
"value".

I propose to replace this definition with:

<!ELEMENT simple
( description?
, value?
, choices?
, defaultvalue?
) >

Any thought

In ptc/99-10-04, section 69.8.2.7 page 69-324 says " simple contains a
mandatory value element ", "If the value element is empty, the value is deemed unspecified. If the value is unspecified, and there is a defaultvalue defined, then
the default value will be used " (rule 1), and " The description, choices and
defaultvalue child elements may be used to provide guidance to the end user in
deciding how to set the attributes " (rule 2).
As described, the mandatory "value" element could be empty then it is not
required to repeat the default value into the value. Here is a valid property file
example:
<properties>
<simple name="size" type="long">
<value></value>
<defaultvalue>100</defaultvalue>
</properties>
This file describes that the value 100 must be affected to the "size" attribute at
deployment time according to the rule 1.
However a component or assembly provider could provide this file as a skeleton
completed by the end user at deployment time according to the rule 2.

In 99-07-01 there was a extention of the atribute definition to enable users
to define specific exceptions on GET/SET operations. This extension has
disappear from 99-10-04. What is the reason for it? This extension seems to
be quite usefull in particular if you consider component configuration
phase.

When the component implementor wants to emits an event it has to use the
push() operation from the local Event interface.

It is not clear how the container will manage to discriminate the event and
select the channel this event need to be send to.

Nothing prevent a component to define several publisher and several emitters
and nothing force the events to be of different types on all of these
channels.

So either the spec is not clear enough on this process or the local push
method is missing some a parameter (like the emitter/publisher port name) to
help the container do his job.

The component specific context will contain send operations for each named
port. The local interface Event is removed, see issue 3937.

In the componentAssembly DTD the executablePlacement is defined as follow:

<!ELEMENT executableplacement
( usagename?
, componentfileref
, componentimplref
, invocation?
, destination?
, extension*
)>
<!ATTLIST executableplacement
id ID #REQUIRED
cardinality CDATA "1" >

It seems to me that the DTD should not enforce the componentimplref as this
might depend on the deployment And there is no reason the assembler should
know where the executable is going to be deployed. For example the
componentimplref should be different between a Solaris, a Linux or an NT
placement.

Therefore I would propose to make componentimplref  optional (as it is in
homePlacement) and change the executablePlacement definition to:

<!ELEMENT executableplacement
( usagename?
, componentfileref
, componentimplref?
, invocation?
, destination?
, extension*
)>
<!ATTLIST executableplacement
id ID #REQUIRED
cardinality CDATA "1" >

When the assembler describes an executable placement, he/she could not
always know what the executable implementation is because this implementation
could be dependent of the physical placement selected at deployment time.
Require to change the mandatory "componentimplref" child element to an
optional child element of the "executableplacement" element in the component
assembly XML DTD in order to apply the same rule defined in the
"homeplacement" element.

The exception raised by Components::Events::subscribe() doesn't include the
Components::ExceededConnectionLimit exception raised by the
subscribe_source_name() 2.3 equivalent interface.

It should be added.

Yes this exception and the InvalidConnection exception are really missing here,
we add them.

I found 2 (possibly) contradictory statement in 99-10-04 for "emits" ports.

1) in 62.4.1.2 The Event Interface

EventConsumerBase obtain_channel (in string supp_name, in EventHeader hdr)
raises (InvalidName);

The obtain_channel operation is used by the component to obtain an
EventConsumerBase which it can use to push events. This operation
corresponds to an emits declaration in component IDL. The supp_name string
identifies an Interoperable Naming Service (INS) name which is used to
identify the SupplierAdmin to be used by CORBA notification. The name is
associated with the SupplierAdmin thorough container specific configuration
data. The obtain_channel operation may optionally specify the EventHeader
required by CORBA notification which will be used for all events pushed to
this channel. If hdr is present, it is prefixed to all events pushed to this
channel. If not, it is defaulted as described in Section 66.4, "Event
Management Integration," on page 66-252. If the supp_name is not recognized,
the InvalidName exception shall be raised.

2) in 66.4.2 Transmitting an event

. channel lookup - for emitted events, this is the channel configured for
general use at container start-up, for published events, this is the channel
established by the container for the purpose of pushing this event type.

Section 62.4.1.2 seems to imply that there can be a different event channels
for each emit port while 66.4.2 seems to imply that there is only one event
channel shared by all emits ports.

What means "general use"?

What is the truth/intent?.

Could you make things clear?

I certainly preffer 1)

The internal interface Events will be removed. Access for sending events will be
provided by the component’s specific context. The whole section about the local
Event interface is removed. The connection setup between event producer and
consumer is handle outside of the component via management functionality of
the container and assembly.

a component wants to publish an event. So, it calls
Components::Notification::Event::create_channel(). The container contact the
(remote) Notification service, create a dedicated channel, connect to it and
return an EventConsumerBase to be used by the component to push any event to
the channel. Each time the push() method is called on the EventConsumerBase
it will create a structured_event and push it to the notification channel.

Now, another component (in another container/memory space/system) wants to
receive these events. So it calls Components::Event::subscribe() on the
first component passing a reference to an EventConsumerBase. The component
internally calls Components::Notification::Event::subscribe() passing the
remote EventConsumerBase reference. So now the container has to create a
(local) strutured_push_consumer and connect it to the channel it has
created. By doing this any event that it send to the channel will be bounced
back to it so that it can then push them to the (remote) EventConsumerBase
that have subscribed to the publish port.

This scenario doesn't seem right to me because the notification service is
then useless as all events are bounced back to the publisher. The container
could just call the push() method on each registered EventConsumerBase.

What seems to be really needed is a way to pass the reference to the
NotificationAdmin back to the second component so that the second component
can then subscribe through its own container to the Notification channel.

Another possiblity would be that the subscribe call accept a (remote)
strutured_push_consumer as parameter instead of the EventConsumerBase.

The last solution is that the publisher port is not designed to work with
the notification service but on its own.

I am certaimly missing something!!!!!

Could you explain how it is supposed to work?

Through major change of equivalent IDL mapping consumer interfaces are
declared at the same scope as the eventtypes. Connection setup of event
producer and consumer is a management activity, which should be handled from the container/assembly not from the component. It is not stated, that event
transmission is realized with the notification service.
So any change here would be a restriction for the implementation conforming to
the specification.

Because the interfaces between the Assembly and the
container/componentServer/servantActivator is not defined, these ones have
to be vendor specific.

Because the ExecutorSegmentBase and the HomeExecutorBase are not specified a
component is always container specific.

As a result an assembly provided by one vendor can only speak to
container/componentServer/servantActivator provided by the same vendor and
the container can only run (even in Java???) components that have
specifically ported to it.

The conclusion is that it is not possble to build an asembly that combine
components build on different CCM platform. All of the component have to be
ported to a single CCM platform.

Is it what is intended?

The section 69.9 of the ptc/99-10-04 document does not define the ServerActiva-
tor, ComponentServer, Container, ExecutorSegmentBase and HomeExecutorBa-
se interfaces. Then, deployment could only be done in a vendor specific manner.
In order to allow the deployment of applications on different CCM platforms,
these interfaces must be defined in the CORBA Component Model specification.
The section 69.9 of the ptc/99-10-04 document must be replaced by the content
of the ccm/2001-10-03 document which defines the ServerActivator, Component-
Server, and Container interfaces. These interfaces are defined in a generic and
portable way allowing interoperability between deployment middleware provi-ded
by various vendors. As each creation operation takes a sequence of ConfigValue
objects as parameter, each vendor could add its own configuration values
without breaking the specification. However standard configuration values should
be collected and defined in a new RFP dedicated to advanced CORBA
component deployment. The definition of the ExecutorSegmentBase and HomeExecutorBase interfaces
must be resolved according to the Issue 3651.

In 99-10-04 chapter 62.4.1.4 (The Event Interface) in the paragraph
describing obtain_channel() and listen() the name passed to these methods
are supposed to be an INS name. Where do we get them from?

It seems to me that it should be the port name that should be passed and the
container job would be to link it with an INS name (that it gets through
container specific configuration) and then get the corresponding Admin
interface.

If this is what is intended we might want to make it more clear in the text.

The equivalent interfaces as described within the document result in type mismatches when code is built to implement the functions generated from the CIDL component specification. That is, you cannot assign a consumer to a subscriber because the interfaces are parallel derivations and not an inheritance compatible derivations. The code prototypes must be changed to overcome this problem. We have tried three different approaches, but the one that seems to work best has the most impact to the IDL revisions. 

See the CORBA Components Model specification, orbos/99-07-01, section
5.6, pages 5-84 through 5-89, approximately.
Could someone clarify the push() and push_event() operations, their
purposes, and their interaction, if any. There is no description
whatsoever of the relationship between the push() and push_event()
operations, even though push_event() is declared in the
inherited Components::EventConsumerBase.  The producing component
invokes its push() operation, which then performs any peculiar
formatting to the event before transmission to the underlying channel
through its container. It is unclear when, if ever, the push_event()
operation will be invoked. A text search of the document reveals the
operation appears only in the interface definition and its immediate
descriptive paragraphs.

Would a better model be to use push_event() as the interface to and from
the container?  (Perhaps this should be independent operations,
produce_event() and consume_event()?)  On the producer side, let push()
perform any component specific formatting of the event before passing
the [now modified] event on to push_event(). This latter interacts with
the container to send the event to the event channel, as
described. (Most push() implementations will do nothing to the event. 
This could be provided as a default generated implementation.) On the
consumer side, push_event() will be invoked by the container as part of
event delivery. The push_event() operation performs type checks, as
described, before it invokes the consumer agent’s push() operation. This
process correctly handles the semantics and permits suitable places to
intercept or override event processing.

EventConsumerBase is part of the client-side interface of a component. Clients
can equivalently use either the push_event() operation on the
EventConsumerBase interface or the push() operation on the consumer interface
associated to the used eventtype. The push_event() operation is described on
page 61-46 and must be used by clients having no static knowledge of the
concrete consumer interface associated to the used eventtype. The push()
operation is described in the text for equivalent eventtype consumer interfaces
and could be used by clients having static knowledge of the concrete consumer interface associated to the used eventtype. Neither interface is used on the
server side. No further clarification is necessary.

The CCM describes the services available for a basic container as being
one of two sets: security, transactions, and naming or security,
transactions, and persistence. Could someone please describe the exact
services available to basic containers and the particular semantics for
each? Are these differences related to one set for the component home
and the second set for the instance?

The text that noted this distinction was part of the removed chapter 66 (see issue
4307). However it is difficult to tell what services a container will need to provide
its functionality to the component instances. It is implementation dependant what
services are available for a container. The container could make use of any of
the CORBA services. It is transparent for components and for homes.
Furthermore there is no distinction between the functionality provided by a
container for a home or for a component. They use the same internal interface
type of the container i.e. the context interface. The context interface provides
also an interface to the orb object. Using this orb object a component or a home
can get access to all of the CORBA Services.

The description of the life cycle and system dynamics of the various
objects that contribute to component deployment and execution is
incomplete. From an implementation perspective, there are many run-time
objects involved that contribute to, or are required for, the overall
operation of a component. But the CCM does not adequately show the
interrelationships among such objects. Even the most rudimentary
implementation depends on the assumptions hidden behind these
interrelationships.

The following questions need to be addressed in order to build a
portable implementation:

1.    Deployment support services:

*  What is the life cycle of the support services needed to create an
   Assembly object?
*  Do these already need to be executing in, known to, or exposed by one
   or more servers?
*  How are these services contacted in a dynamic environment?
*  Is this structure equivalent to the TINA DPE concepts?
*  What is the life cycle of the Assembly object itself?
*  When and how is an Assembly object deleted?

2.    Application servers, containers, homes, components:

*  What is the exact life cycle of these various objects?
*  The specification identifies how component instances are created. How
   are they deleted?
*  When and how is a home removed from a container?
*  When and how is a container removed from an application server?
*  When and how is an application server terminated?

3.    Related or referenced objects:

*  What is the life cycle of event channels?
*  Does the life cycle of objects vary if they are "private" to an
   assembly?
*  When and how are event subscriptions released from their publisher or
   emitter?
*  When and how are objects "registered" with the naming service or
   trader unregistered?

A full and representative life cycle description of the run-time objects
denoted above is necessary to understand the dynamic system model and
its inherent limitations. This will be critical for systems that must
exhibit very high reliability and availability. There appear to be many
assumptions, particularly with respect to the deployment tools, that
affect recovery operations from fault conditions. These must all be made
explicit. Thus, the CCM description should include a comprehensive state
transition model. This may be documented as cooperating or nested state
machines for the various pieces.

The ptc/99-10-04 document does not define the whole life cycle of all objects
involved in the deployment process.
The section 69.9 of the ptc/99-10-04 document must be replaced by the content
of the ccm/2001-10-03 defining the life cycle of all objects involved in the
deployment process.
Comments about the questions:
1.1. Assembly objects are created by AssemblyFactory objects. These
AssemblyFactory objects are part of CCM middleware which must be
deployed on each host before any CCM application deployment.
1.2. There is at most one AssemblyFactory on each host. Then several
AssemblyFactory objects could run in a network. To create an Assembly
object, the AssemblyFactory object is selected by the user according to its
preferences or automatically according to a vendor specific load balancing
policy. When created, an Assembly object is hosted by one physical host
but its components can be distributed on several physical hosts.
1.3. As any CORBA object references, AssemblyFactory references could be
obtained by stringified IORs, CORBA Object Reference URLs, Name
Services, or Trader Services. This choice is vendor specific but is fully
portable and interoperable. 1.4. Here Name Services and Trader Services are adequate.
1.5. When an application must be deployed, the deployment tool invokes the
create operation of one AssemblyFactory object in order to create an
Assembly object. When the application must be destroyed, the
deployment tool invokes the destroy operation of the AssemblyFactory
object.
1.6. An Assembly object is destroyed when its associate application must be
removed by invoking the destroy operation of the AssemblyFactory used
to create the Assembly object.
2.1. When the build operation of an Assembly object is invoked, and according
to information contained into the component assembly descriptor, the
Assembly object invokes the ServerActivator::create_component_server
operation in order to create each required ComponentServer instance,
invokes the ComponentServer::create_container operation in order to
create each required Container instance, invokes the
Container::install_home operation in order to create each required
CCMHome instance, invokes one of the create operations of homes in
order to create the required CCMObject instances. Then components are
interconnected and configured according to information contained in the
component assembly descriptor. When the application should be stopped,
the Assembly object invokes the remove operation of each created
component, home, container, and component server instances.
2.2. A CCMObject instance could be removed by invoking its
CCMObject::remove operation or by invoking the
CCMHome::remove_component operation of its home. Implicitly, a
component is removed by its owner Assembly instance when the
Assembly::tear_down operation is invoked.
2.3. A CCMHome instance is removed from its container by invoking the
Container::remove_home operation. This operation is invoked by the
implementation of the Assembly::tear_down operation.
2.4. A Container instance is removed from its component server by invoking
the Container::remove or ComponentServer::remove_container
operations. This is implicitly invoked by the implementation of the
Assembly::tear_down operation.
2.5. A ComponentServer is terminated by invoking the
ComponentServer::remove or
ServerActivator::remove_component_server operations. This is implicitly
invoked by the implementation of the Assembly::tear_down operation. 3.1. Event channels are implicitly created by the deployment middleware. They
are implicitly destroyed when the associate assembly is removed. This is
done in a vendor specific manner.
3.2. Objects created during a deployment process - e.g. component servers,
containers, homes, event channels, etc - are private (owned) by the
Assembly instance which created them.
3.3. When tearing down an Assembly object, this object must remove all
interconnections between components by invoking the operations
provided by the Receptacles and Events interfaces, e.g.
Receptacles::disconnect, Events::unsubscribe, and
Events::disconnect_consumer operations.
3.4. Components are implicitly (un)registered from/to the name service or
trader service by the owner Assembly object if these registrations are
explicitly described into the component assembly descriptor.

in 99-08-05, the corbacomponent DTD is missing the "description" element
specification. It should be the same as the other DTDs and can be copied
from them

<!ELEMENT description ( #PCDATA ) >

Require to add the "description" element to the CORBA Component Descriptor
XML DTD as this is a child element of the "right" element described in ptc/99-10-04
section 69.4.5.44 page 69-293.

in 99-08-05 the softpkg DTD is missing the "repository" element
specification. It could be copied from corbacomponent DTD.

<!ELEMENT repository
( ins
| objref
| link
) >
<!ATTLIST repository
type CDATA #IMPLIED >

Require to add the "repository" element to the softpkg XML DTD as this is a child
element of the "idl" element described in ptc/99-10-04 section 69.3.2.14 page 69-266.

in 99-08-05 the componentassembly DTD has a typo in the "connections"
element definition. "connecthome" should be spelled "connecthomes"

<!ELEMENT connections
( connectinterface
| connectevent
| connecthomes
| extension
)* >

Require to replace "connecthome" by "connecthomes" in the chapter 69 of
ptc/99-10-04 in order to correct this typo.

I was researching the CCM Event Corba 3 to Corba 2.3 mappings in 
chapter 5 of Volume I, and found that the resulting interfaces did not 
permit a consumer to subscribe to a publisher because the interface 
type returned by the get_consumer_<name>() does not match the 
subscribe_<name)() parameter.  I am not sure if I made a mistake when 
mapping the 3.0 to 2.3 idl or if it is a problem in the standard.  I 
also provide an alternative that might work, though I'm sure it will 
need some work.

I have the following question (problem). The Corba Component Model Spec
(volume 1)  defines the following :
module CORBA_3 {
   module Components {
       interface Events {
          ...
       };
       ...
       module Events {
           ...
       };
   };
};

So the word 'Events' is used for defining an interface and a module!! Is
this correct IDL, because ther JavaORB idl-compiler nor the ORBACUS
idl-compiler is able to compile such idl.

This issue was already resolved by the revised text of Issue 3061, i.e.
7. In IDL on page 150, section 62.4.1.1 change
Events::Event get_event(); to Notification::Event get_event();
8. On page 152, section 62.4.1.4, change Components::Events to
Components::Notification

The CCM spec seems to have make the choice to prevent the component
implementor to fill in the filterable body part of a structured event sent
to the a notification channel.

What are the reasons of this choice?

2 remarks:
- The filtrable body part of a structured event seems to be the most usefull
part of the event. Not using it (or leaving it to the container to fill in
from obscure sources) doesn't seem to make a lot of sense.
- Other standard bodies (like T1M1.5) are using the filterable body part of
the event and are making the remainder of the boby (where the EventBase
derived value type should be put) optional and unnecessary.

Any comment/explanation of the choice is welcome.

As the CCM spec is not giving any mean (or very little) to fill in the
filterable body part, no services are provided for a component to set its
event filters when sending or receiving events.

This seems to be a very usefull service to me for application such as:

- limiting the number of events emitted by a component based on a config
parameter (like messages with priority > config value can go out, other are
discarded. when the config value change at runtime the filter could also
change.
- filtering events received from a notification channel.

I agree that these 2 function could be achieve by user code in the component
but it means that unecessary events are passed between components and the
netwok load and CPU load is higher than necessary.

I guess the point I am trying to make is that using the notification service
without using filters and/or filterable body doesn't seem to make a lot of
sense.

What is the intend of the sepc on this issue?

In ptc/99-10-04 on page 15 the grammar rule of home_executor_body in chapter
60.7 "Home Executor Definition" contains bars implying alternatives. These
bars have to be removed to match the subsequent description.

The alternatives in the OMG CIDL grammar rule home_executor_body (9) must
be removed to match the expected semantics described in section 60.7.

See the CORBA Components Model specification, orbos/99-07-01, paragraph
10.6.2.52, page 10-365.  See also the DTD appendices document, orbos/99-08-05.

The title of this paragraph heading is incorrect.  The element is "usesport",
not "usingcomponent".  It has occasionally been hard to find the description
because of this textual error.

Require to replace "usingcomponent" by "usesport" in the chapter 69 of ptc/99-10-
04 in order to correct this typo.

The CCM does not describe the behavior of the system in case of various fault situations. In particular, this issue only concerns itself with the recovery mechanisms of event subscriptions or facet receptacles that were automatically established through an assembly. While it is outside the scope of the CCM to describe general fault behavior, it is felt that recovery mechanisms (or their absence) should be explicitly identified for connections automatically built between ports. Otherwise, why go to the trouble of building them, since error detection and recovery wrappers would be needed around any use of them? 

The following scenario highlights the various situations. It assumes that the components are deployed in separate processes on different platforms so that one of the two components remains operational despite failure or inaccessibility of the other. The scenario primarily deals with the recovery of an interface provided by Component X and used by Component Y. Appropriate questions related to event channels are also given where applicable. Event channels are themselves more difficult because the notification services adds yet another object to the set that may fail during the scenario. 

Scenario: Component X declares that it provides an interface A. Likewise, Component Y declares that it uses interface A. (Or, X emits or publishes event A to which Y subscribes.) Instances of the components are combined through an assembly. Now, the assembly description indicates that a connection is to be built between X and Y. That is, the descriptor defines connections in which a connection element defines the association. Said element’s providesport acquires X’s facet A and assigns that through the usesport to Y’s interface receptacle. (For events, read these as emitsport or publishesport and subscribesport.) 

The following questions arise: 

When does the connection take place, during assembly construction or on reference to the port’s receptacle inside Y? That is, is this immediate or lazy initialization? When are event channels created or attached? Can the producer delay creation or attachment until a push() operation? Can the consumer accomplish the creation? Can an m:n emitter to consumer notification matrix be built? (The specification is unclear on this.) 
What happens if the interface reference to A cannot be acquired because (1) X has failed or is inaccessible, (2) X fails during the get operation, or (3) X returns a nil reference? 
What happens during run-time when Y invokes an operation on A and: 
The application server process containing X has terminated (COMM_FAILURE returned)? 
Derived valuetype arguments cannot be marshalled (MARSHALL/BAD_PARAM returned)? 
The underlying object supporting A in X has been deleted (INV_OBJREF returned)? 
An unexpected application error occurs (UNKNOWN returned)? 
With respect to error detection and recovery: 
How does one indicate the set of objects that can detect the error? Possible objects are Y, Y’s home, Y’s container, X’s container, X’s home, the assembly, an independent third party. 
How does one indicate the set of objects that can recover the error? 
How does one indicate whether the error should be detected? 
How does one indicate whether recovery should be attempted? 
How does one indicate the recovery strategy, especially if there are several objects that can recover the error? 
If the strategy has multiple fallback conditions, should this logic be placed into a single object or should it be given as a precedence-ordered list? 
Where should this information be specified: IDL, CIDL, or XML? 
What are the implications when the components have different type and container semantics? 
Let component X be transient and component Y be an entity. If component X fails, can a new X be safely created for its corresponding Y? 
Assume a new X was created and the old X still exists but became inaccessible. Can the old X be detected and one of the X’s be deleted [dismissed] after the old X is again accessible? 
Assume a request to X completes successfully in X but fails during the reply to Y. Can the operation be retried or the previous results retransmitted, either on the old X after recovery or on a new X? 
In these questions, what happens if X is an entity and Y is transient? 
In these questions, what happens if Y aborts rather than X? 

Ideally, it would be nice if either the IDL extensions or the CIDL constructions permitted specification of an error recovery wrapper around access to a receptacle (or event channel). This could actually work as a general mechanism for any component and not just components grouped in an assembly. The wrapper would be a specialized object implemented specifically in the context of the component or assembly that provided the desired error detection and recovery behavior. It would be a proxy similar to a stub: it would have the same interface as the target object to which it delegates. Errors would be caught (as described) and recovered automatically, if possible. This includes the initial reference to an object, which would now be built or acquired dynamically at run-time rather than semi-statically at assembly instantiation. Multiple inheritance, in languages that support it, would be very useful in standardizing proxy behavior. The component DTD could be used to specify desirable run-time operation and associated characteristics.

The CORBA Component Model Specification does not address fault tolerance
problems in general. However, a CCM implementation is free to use for instance
the OMG Object Transaction Service (OTS) and the OMG Fault Tolerance
Service defined in CORBA 2.5 in order to address any failure and recovery
problems during the deployment and execution of CCM applications. If a
standard for a Fault Tolerant CORBA Component Model is strongly required by
the industry, then this would be addressed by a future RFP.

See the CORBA Components specification, orbos/99-07-01, chapters 5, 6,
7, and 9.  The semantics, life cycle, and mechanisms behind components,
facets, "regular" objects, and their related object references is weakly
specified.  In particular, it is not clear how a component interacts
with a container to generate an object reference to a facet, especially
a facet in a secondary segment.  The description of component
identifiers indicates that the component object id, the facet number,
and the segment number are used to generate the facet's object reference
(or perhaps only the ObjectId), but the sequence of operations is not
given.  It appears that not all the necessary methods have been formally
specified, nor are the code generation examples adequate for this
siutation.
 
Consider the following IDL:

   interface A {};
   component C
   {
       provides A a_facet;
       A get_another_A();
   };

What is the life-cycle of the A object returned as the provided facet? 
Is it limited to the life-cycle of the component?  Is the member
operation returning an object of the same type as a provided facet
permitted?  Should this return the same object as the facet?  If not, is
the life-cycle of this extra object limited to the life-cycle of the
component?  Should such objects be considered facets, even if not
explicitly declared such (which, please note, provides the equivalent of
the deprecated "provides multiple" capability)?  What information needs
to be encoded in its object reference, especially for component
dependency?  How will the context for this be established, and are any
additional interfaces or operations required to accomplish this?

The example of this issue is not valid because a component can’t have
operations. But if this operation is in one of the supported interfaces than the
statement of this issue remains.
An operation can return an object reference i.e. an interface of course. If this
interface should be one of the facets of the component than it is not appropriate to use such an operation to get a reference to it. Instead of this it is better to use
the provide operation of the component interface itself.
The concrete values of the object reference (e.g. ObjectID) are implementation
specific and hidden by the container. A component should not create object
references of its facets by its own.
However it is possible for a component to get an object reference of one of its
interfaces. This can be achieved for instance via the get_CCM_object() method
of the context interface. And this reference can be returned by an operation as
shown above.
Regarding the issue questions, the lifecycle of the object reference returned by
such an operation is decoupled from the object that is referenced by this
reference. The object that is referenced by this reference could be any of this
proposed ones. It can be a facet or it can be another interface implementation.
There are no constraints about this.

The semantics of components of a particular type (session, entity)
residing in a compatible container type that access components of a
different type residing in a corresponding but different compatible
container type are unclear. Are there any expected or preferred
combinations? Are any disallowed or discouraged? See, for example, the
discussion under issue 4025 on automated recovery. In his replies, Mr.
Dubois seems to assume that entity components create transient (service
or session) components but not the reverse. In the telecommunications
domain, however, a session object may share access to an entity, and
then create additional entities based on external events, even though
the session itself is not persistent. Could someone please articulate
the possibilities and their utility (or lack thereof)?

It is not intended to disallow some of the combinations of the component
categories. As long as two components of any category are connected they can
interact.
As long as a component can get access to the Home Finder (i.e. using
resolve_initial_references()) it is possible for a component to get access to a
home of a particular type and to use the create() operation of that home.

I have noticed that assemblies do not follow the composition pattern. 
Thus, assemblies cannot themselves be used as building blocks for other
assemblies.  I think part of this comes from the fact that installation
and management of assemblies is mostly "magic" done behind the scenes by
various installation and support utilities.  In order to "reuse" an
existing assembly, one must copy an existing assembly definition (I
guess constructed completely by hand) to a new definition, which must
then be tailored to incorporate the new strategy and pieces.  This seems
counter-intuitive, besides being manually intensive, for if an assembly
does useful work, why would I want to expose its internal details just
to take advantage of that usefulness?  As pointed out by Mr. Dubois in
issue 3939, because all of that "magic" is not specified by various
formal interfaces, it is highly likely approaching certainty that
assemblies will only work for the particular vendor on which they were
built.  Since I believe the intention was to promote interoperability in
general and as much code automation as possible for components in
particular, it would seem that we want to restrict the "magic" by taking
the formalisms behind assemblies to another level.<p>
 
I suggest that, just as a <i>composition</i> exists to tie a component,
its home, and various configuration properties together, we can create
for the CIDL grammar productions for an <i>assembly</i> to tie multiple
compositions together.  Subsequently, an assembly could be treated as a
composition, to be used by other assemblies, only exposing selected
facets or events from its constituent entities.  I think there are a
number of advantages to this approach:  (1) It solves certain semantic
ambiguities with assemblies, for instance whether facets, receptacles,
and events are private or public to the assembly.  (2) The assembly
implementation, its XML, and its relation to its constituents and home,
can be generated automatically from the CIDL description [we have been
working on this extensively].  Our approach is to use an assembly
exactly like a composition, as the realization of a component and home
definition.  Our research efforts imply that all of the assembly
component and home code can be automatically generated - no user
tailoring will be needed. (3) Because the assembly now acts as a
component (composition), it can be reused by other assemblies without
knowledge of its internal structure.  (4) Activation of an assembly
appears the same as for any other component;  it merely requires formal
specification of previously undefined interfaces to accomplish it, thus
promoting portability and interoperability.  (5) The assembly
"deployment magic" becomes exposed through the interfaces above, thus
removing several of the deployment tools and servers/services identified
in the specification. The only real drawbacks I see are the complexity of the assembly
productions (we can really get out of control with this) and that
assemblies now have an actual code base rather than being "magical
creatures" managed by the deployment tools.  I guess these are both
two-edged swords.  There might be a run-time footprint change for all of
these extra interfaces, but those had to be lying around in other places
anyway.

In order to reuse an existing assembly, one must copy the associate component
assembly descriptor to create a new component assembly descriptor. Here,
specific vendor tools could provide a composition pattern in order to simplify the
reuse of component assembly descriptors.
The CORBA Component Model specification does not address the composition
of assemblies, i.e. assemblies are not components. If a standard for assembly
composition is strongly required by the industry, then this would be addressed by
a future RFP.

In a complex distributed environment, the implementation of highly
available and highly reliable services requires redundant placement of
software components in all their manifestations.  Assemblies provide a
nice, convenient way of specifying the deployment and activation of
components and the connections that relate them for a particular
purpose. Now, for various reasons and Fault Tolerant CORBA
notwithstanding, in corporate reality this sequence and specification
will occur in multiple places in basically identical fashion.  About the
only thing that changes are the host names and their network addresses; 
everything else from the hardware configuration to the size of the disk
drives and file systems is (and inherently must be) exactly the same
among all deployments.  This, for example, is one technique to support
geographic site failover.
 
My question is, has anyone thought of a two or more stage XML process,
one in which the package or assembly composition and deployment XML is
specified as a template or configurable, parameterized entity, and
another where the parameters have been substituted for "finalization"? 
This can occur at two distinct points in the life-cycle:  one set of
substitutions occurring when an artifact is deployed (installed?) on the
various computer systems involved, and another when the home [and
possibly individual instances] of the artifacts are activated
(instantiated?) to run on those computer systems.  My work in the
telecom and defense industries has show that deployment of anything is
rarely a singleton event;  there are always redundancies, replications,
and backups to take into account.  Templates seem to provide a nice
solution to all of the manual editing required.

The CORBA Component Model specification does not define a standard for
dealing with assembly templates. However, specific vendor tools could always
deal with assembly templates. If a standard for assembly templates is strongly
required by the industry, then this would be addressed by a future RFP.

See the CORBA Component Specification, orbos/99-07-01, and Persistent
State Service issue #4074.  Is there any reason why homes cannot support
(manage) multiple component types?  This seems like a perfect case for
polymorphism;  the only time you really need a new home type is when you
change the behavior or have some other incompatibility.  Is it possible
to do instances of homes, one per component type (perhaps instances of
components acting as managers for other components)?  I simply do not
understand why these are one-to-one with parallel but distinct
derivations.  I realize the requirements were to maximize code
generation, but I don't see that this is a conflict.

The CORBA Component model explicitly separates the component and home
concepts, i.e. a component could not be a home and a home could not be a
component. In the CCM, a home type manages only one component type and a
component type could be managed by several home types. However the CCM
does not avoid a home implementation to manage several component
implementations. In this use case, these component implementations must
implement at least the component type managed by the home type. But these
component implementations could also implement derived component types as
shown in the following IDL example:
component C1 { ... };
component C2 : C1 { ... };
valuetype K : ::Components::PrimaryKeyBase { ... };
home H1 manages C1 primarykey K { ... };
and
. CI1 is an implementation of the C1 type;
. CI2 is an implementation of the C2 type but also of the C1 type transitively as
C2 inherits from C1; and HI1 is an implementation of the H1 type and must manage at least C1
instances.
As both CI1 and CI2 implement C1 then HI1 could manage both CI1 and CI2
instances. Then it is not required to define a specific home type to manage C2
components.
Defining a home type H2 managing C2 components is only required if the IDL
designer wants to for instance:
. identity its components with a primary key completely different from K (or a
sub-type of K),
. define new explicit operations like factory and finder ones, and/or
. provide to clients a resulting H2Implicit interface, i.e. an interface that
provides standard create, finder and remove operations dedicated to the C2
type.

The definition of homes does not permit interface inheritance.  It
appears this is an oversight as the omission seems unreasonable and
counter-intuitive, especially since homes must follow a parallel
derivation hierarchy with their component types.  I have found cases in
which a home would expose the same interface as its component in which
the home subsequently delegates to a specific component instance (even a
persistent instance) however selected. (The component instance may or
may not be hidden from the client.)  Interfaces are a perfect mechanism
whereby the operational signatures could be standardized, thus
eliminating potential errors caused by changing one but not the other.
This could be accomplished using a supports clause in the inheritance
specification similar to that of valuetypes.

Allow homes to support multiple interfaces as components support multiple
interfaces. Require to update OMG IDL Grammar, the Interface Repository, and
IDL equivalent mapping for homes to explicit home interfaces.

The CCM standard indicates that all CCM Event functions will delegate to
the container. Chapter 7 of the CCM Volume 1 further dictates the
interface the container will provide to the component, called
Components::Notification::Event, referred to as the "Event Interface"
hereafter. This interface contains many problems and does not address
all the required functionality. The problems are listed below:<p>

*  The create_channel() method returns an EventConsumerBase for the
   publisher to use to publish events to the channel. It is not possible
   for the Event Interface to construct a concrete EventConsumerBase,
   specifically the interface defined as
   &lt;publishing_component&gt;EventConsumers::
   &lt;event_type&gt;Consumer (per section 5.6.6 and 5.6.7 giving the
   publisher and emitter IDL expansion). The Event::obtain_channel()
   method has the same problem
*  The subscribe() method implies that the container supplying events
   will hold the supplier proxy that will be used to send events to the
   subscriber’s EventConsumerBase. This is an inefficient model. Also,
   this model is in direct conflict with the listen() method, which
   supports a more efficient model (see next bullet).
*  The standard does not provide any documentation on when a consumer
   would call the listen() method. The standard also does not provide a
   means for the consumer’s component to realise the "csmr_name", the
   name used to find the ConsumerAdmin from the Naming Service [see
   possibly related issue #3940]. Nor does the standard indicate when
   the ConsumerAdmin would have ever been added to the Naming Service.
   It might be possible that this would work for emitters, but it does
   not work for publishers (the standard dictates that a consumer cannot
   distinguish between being connected to an emitter or a publisher).
   This method does imply that the consuming component will have a proxy
   local to its container, separate from the publishing component’s
   container (contradictory to the subscribe() method, see previous
   bullet).
*  The push() method does not provide a means to indicate which channel
   the event should be pushed to [see possibly related issue #3928].<p>

The Event Interface is a local interface ­ that is, the client will
never see this interface, and so it is possible to hide the use of this
interface inside the generated code and thus replace the interface.
Internally we have added a PortManager interface to be used in place of
the Event Interface. This interface provides better management of the
Event Channels and it also manages receptacle connections. Two
interfaces will derive from the PortManager, a TransientPortManager and
a PersistentPortManager. These two derived interfaces will permit
connections between components to be managed as defined by the type of
the container. Where meaningful, this permits the port connections to be
made persistent as part of the overall state so that connections
(specifically, notification channels) can be more reliably and robustly
managed. The CCM2Context::get_event() operation is replaced by
get_port_manager()

 I am somewhat surprised over the ExtendedIR interface in 00-11-01.
I am very aware of problems with extensibility in the Interface Repo-
sitory. In the past, a lot of problems have been caused because modi-
fications like InterfaceDef::is_abstract have been worked in and out.
We certainly desperately need a backwards-compatible Interface Repo-
sitory.

 This is unachievable with version pragmas, because then a client's
is_a inquiries with "old" Repository Ids will fail, and the client
will refuse to talk any further.

 Backward compatibility is instead achieved by not changing data types
(such as InterfaceDescription) and by not changing the signature of
existing attributes and operations.

 Adding new types that are used by new operations on existing interfaces
does not break compatibility, because the client will simply be unaware
that there are more operations than it knows of (such as describe_inter-
face_2_3).

 Whether changing interfaces sensible is debatable, surely it's more
consistent to use derived interfaces instead -- this has the least im-
pact on compatiblity.

 In that light, I wonder whether the proposal in 00-11-01 gets us any
further. It adds more fixed interfaces in another module, and this new
ExtendedIR module is just as static as the old ones have been. If any
further changes were necessary, backwards-incompatible changes were
just as necessary.

 The proposal in 00-11-01 also adds a lot of unnecessary verbose baggage
with its use of "_extended_" everywhere, and its usage of multiple inheri-
tance from the original interfaces is confusing.

 Yet there is one item from 00-11-01 that I like much better than the
proposal in 99-10-03, and that is the usage of AbstractInterfaceDef and
LocalInterfaceDef. I think that's the way to go.

 Therefore, I tend to vote against issue 3233 and its proposed resolution
in 00-11-01.

 Rather, I propose to go back to the original version instead, and

  - to add AbstractInterfaceDef, LocalInterfaceDef and the related
    container operations
  - to add an AttributeWithExceptionsDef and InterfaceDef::create_
    attribute_with_exceptions and ValueDef::* operations.

 Whether the Interface Repository should be moved to a different module
should be a separate discussion. I support the idea, but I don't think
that the implementation should be forced to offer access to the IFR
using both the CORBA:: and IR:: modules.
 Note that vendors could still offer the old interfaces in their imple-
mentation.

orbos/00-11-01 is an old working draft document which is replaced by ccm/2001-08-
01. All sub-issues listed by this issue are resolved by the ccm/2001-08-01
document.

While reviewing the ComponentIR interfaces in 00-11-01, I have found
some problems with it. (These are unrelated to the current discussion
about the Interface Repository itself.)

Many interfaces inherit Contained::describe(), which is supposed to
return information about the element. In the basic IFR, this data is
designed to contain all possible information about that type. This
is very convenient, since then a map mapping RepositoryIds to
Contained::Description contains all of the IFR's information.

By referring to InterfaceDefs rather than RepositoryIds, the client
will need to store that association elsewhere, or repeatedly invoke
the Interface Repository.


Suggested resolution:
- In ProvidesDescription, replace
    InterfaceDef interface_type
  with
    RepositoryId interface_type

- Ditto for UsesDescription

- In EventDescription, replace
    ValueDef event
  with
    RepositoryId event

- In ComponentDescription, replace
    ProvidesDefSeq provides_interfaces
    UsesDefSeq uses_interfaces
    EmitsDefSeq emits_events
    PublishesDefSeq publishes_events
    ConsumesDefSeq consumes_events
  with
    ProvidesDescriptionSeq provides_interfaces
    UsesDescriptionSeq uses_interfaces
    EmitsDescriptionSeq emits_events
    PublishesDescriptionSeq publishes_events
    ConsumesDescriptionSeq consumes_events

- In PrimaryKeyDescription, replace
    ValueDef primary_key
  with
    RepositoryId primary_key

- In HomeDescription, replace
    PrimaryKeyDef primary_key_def
    FactoryDefSeq factories
    FinderDefSeq finders
  with
    PrimaryKeyDescription primary_key
    OpDescriptionSeq factories
    OpDescriptionSeq finders


Next, all parts of the "basic" Interface Repository are mutable, but
most attributes of the Components interfaces are declared as readonly.
I propose to remove the readonly modifier from

- ProvidesDef::interface_type
- UsesDef::interface_type
- UsesDef::is_multiple
- EventDef::event
- ComponentDef::supported_interfaces
- ComponentDef::base_component
- ComponentDef::provides_interfaces
- ComponentDef::uses_interfaces
- ComponentDef::emits_events
- ComponentDef::publishes_events
- ComponentDef::consumes_events
- PrimaryKeyDef::primary_key
- HomeDef::base_home
- HomeDef::managed_component
- HomeDef::primary_key
- HomeDef::factories
- HomeDef::finders


Last but not least, there seems to be some confusion about Primary Keys.
When a Home is created with Repository::create_home, a ValueDef should
be passed, while the terminology seems to dictate a PrimaryKeyDef instead.
You can get a PrimaryKeyDef using HomeDef::create_primary_key, but that
would be a chicken-egg scenario.

Proposed resolution:

- Change the ValueDef in Repository::create_home to PrimaryKeyDef
- Move the create_primary_key() operation from HomeDef to Repository

orbos/00-11-01 is an old working draft document which is replaced by ccm/2001-08-
01. All sub-issues listed by this issue are resolved by the ccm/2001-08-01
document.

The third part of the adopted CCM submission (orbos/99-07-03)
moves all the create_..._tc operations from the ORB interface
to a new PIDL interface, CORBA::TypeCodeFactory.

This change breaks source-compatibility: source code that creates
typecodes with a pre-CORBA 3.0 ORB will need to be updated to use
a CORBA 3.0 ORB with such a TypeCodeFactory interface.

And there is no clear benefit from this update:
 - ORB is still PIDL -- it even creates an additional PIDL
   interface.
 - type code kinds are not more extensible (TCKind is still an
   enum)

I suggest to undo this update, i.e. keep the create_..._tc
operations on the CORBA::ORB interface.

All create_..._tc operations are moved back to their original CORBA::ORB
interface. The CORBA::TypeCodeFactory interface is removed to not break
source-compatibility, i.e. exciting CORBA 2.4.2 source code creating TypeCodes.
This also allows one to implement CCM without modifying existing CORBA 2.4.2
ORBs.

How to activate servants by only using the Session2Context interface from
the Extended module? It only offers operations to create references like
create_ref() and create_ref_from_id() similar to those from the POA but no
means to activate servants are available in the whole container API!

Object references and active components are managed by the container only.
This interface is not supposed to allow activation of servants or components.
Invocations on object references created through this interface are delivered by
the container to the current component that invokes this operation. A clarifying
paragraph is added.
Also, using the ObjectId type of the PortableServer module is inappropriate.
Replace with CORBA::OctetSeq.

Is there any reason to name the context interface for extended session
components as Session2Context in module Components::Extended? Why not simply
SessionContext like in the Basic module?

The intent was to remove the nested Basic and Extended modules. However,
references to the Basic and Extended modules have not been removed from the
document. This needs to be done.

The CCM MOF IR draft (ptc/99-10-05) uses UML to denote the MOF model
of the IR. Without missing elaboration, it is not possible to mentally
construct the metamodel. For example, the enumeration, primitive, and
unchangeable stereotypes don't have a well-defined relationship to MOF
concepts. It seems that the MOF chapter should use the UML MOF profile
(ad/01-02-29). In addition, it would be desirable if a normative XML
document that defines the metamodel (following the MOF DTD) is
provided.

The metamodel was updated to resolve the issue. Enumeration is
used to denote an UML enumeration type which is allowed according to the
MOF profile. Unchangeable and ordered have been removed. Primitive is
used to refer to CORBA base types.

Section 8.3.1 says "The signatures of the CORBA component operations are mapped to signatures of EJB remote interface methods following the IDL to Java mapping rules."

As far as I can see, this only works if the IDL signature has no out or inout parameters. The Holder classes for out and inout parameters cannot be used in an EJB interface signature because they need not be Serializable, which breaks the rules for an RMI compliant class. Even if they could the EJB stubs and skeletons would not implement their special return value behavior without modifications to the EJB spec.

Someone please tell me I've missed something!

The fundamental problem appears to be that EJB/RMI is not able to express the
mapping of a Component IDL signature with out or inout parameters (given RMI's
pass by value semantics). Restrict the set of Component IDL signatures to be
included in the portion of Component IDL that is to be considered by the
specification to those that do not include out or inout parameters.

Looking at ptc/99-10-04, it is not clear to me which parts of this
document are intended as normative.

For example, the introduction to chapter 66, "Component Container
Architecture", states that the presented design "is not the only
possible design choice." Consequently, it appears that the entire
chapter 66 is not intended as normative. However, looking at the
actual text, a reader might be easily confused into taking aspects of
the design as normative.

While this text was helpful in the submission to give readers an
insight how the submitters might design their implementations, it
should be removed from the specification, to really give implementors
the freedom of design choice that was apparently intended with the
submission.

The chapter 66 in ptc/99-10-04 is described in terms of "an exemplary design"
which "is not the only possible design choice" (see page 66-200). As this chapter
is not a normative part of the CCM, it is removed to allow implementors to select
their own appropriate design choices.

. I don't 
think OMG specifications should use a single term in two distinctly 
different ways. The text of the issue starts with the sentence, 
"the Components spec and valuetype spec treat "supports" exactly 
**OPPOSITE** in semantics regarding widening/narrowing." and continues 
for about 3 or 4 paragraphs. Ed's comment should go in there too.

It seems to be agreed that the issue is not a technical one, as the usage of
"supports" for components is, in syntax and semantics, the same as for
valuetypes: the component/valuetype will offer all operations and attributes from
the supported interface. In both cases, "true" inheritance is not used because
inheritance should only be used within the same type hierarchy.
The difference with respect to widening is a side effect of using interface
inheritance for supported interfaces in equivalent IDL, and this is not easy to
avoid. The CCM FTF strongly opposes introducing a new keyword instead of
"supports" here.

The Components::Navigation interface that is implemented by all
components provides introspection ("generic navigation") capabilities.
There are lots of use cases for introspection, so I wonder why there
is introspection for facets, but not for receptacles or event ports.
I suggest to add such introspection capabilities. All introspection
features should be alike as much as possible for ease of usage.

The issue is concerned with the limited and incomplete introspection support for
components (ref document ptc/99-10-04). While the CCMObject interface inherits
from the Navigation interface for introspecting facets (e.g. to get a listing of all
available facets) and the Receptacles interface for introspection and
manipulation of receptacles, there is no equivalent for event ports.
Introspection and type-generic port handling operations are required for dynamic
tools. Using information returned from the introspection operations, these tools
will be able to manipulate components (e.g. interconnect them) in a generic
manner.
This resolution describes a set of changes to the Events interface to support
generic introspection features for event ports. The types used for facet and
receptacle introspection are also updated in order to achieve a consistent
interface for all types of ports.
(1) Base type
A valuetype is added that will serve as base for all port descriptions. This is the
same as FacetDescription in the original document, containing the port name and
the Repository Id of the port type (i.e. an InterfaceDef for facets and receptacles
and an EventDef for emitters, publishers and consumers).
valuetype PortDescription
{
public FeatureName name;
public CORBA::RepositoryId type_id;
}; (2) Navigation
The Facet valuetype is renamed to FacetDescription for consistency. The
inheritance from PortDescription is adjusted.
valuetype FacetDescription : PortDescription
{
public Object ref;
};
In the Navigation interface, the superfluous operation describe_facets is
removed, types are adjusted for consistency, and also for consistency, the
provide_ prefix is changed to get_.
interface Navigation {
Object provide_facet (in FeatureName name)
raises (InvalidName);
FacetDescriptions get_all_facets ();
FacetDescriptions get_named_facets (in NameList names)
raises (InvalidName);
boolean same_component (in Object ref);
};
The semantics of all operations remain the same.
(3) Receptacles
A new valuetype ReceptacleDescription is introduced to carry information about
a receptacle port.
valuetype ReceptacleDescription : PortDescription
{
public boolean is_multiplex;
public ConnectedDescriptions connections;
};
typedef sequence<ReceptacleDescription> ReceptacleDescriptions;
The boolean value is_multiplex is TRUE if the port is a multiplex receptacle (uses
multiple), and FALSE otherwise. The connections variable holds a sequence of
ConnectionDescription values as already defined.
In the Receptacles interface, two operations are added to introspect receptacle
ports.
interface Receptacles {
ReceptacleDescriptions get_all_receptacles (); ReceptacleDescriptions get_named_receptacles (in
NameList names)
raises(InvalidName);
// other operations as before
};
The get_all_receptacles operation returns information about all receptacle ports
in the component's inheritance hierarchy as a sequence of
ReceptacleDescription values. The order in which these values occur in the
sequence is not specified. For components that do not have any receptacles
(e.g., a basic component), this operation returns a sequence of length zero.
The get_named_receptacles operation returns information about all receptacle
ports denoted by the names parameter as a sequence of ReceptacleDescription
values. The order in which these values occur in the sequence is not specified. If
any name in the names parameter is not a valid name for a receptacle in the
component's inheritance hierarchy, the operation raises the InvalidName
exception. A component that does not provide any receptacles (e.g., a basic
component) will have no valid name parameter to this operation and thus shall
always raise the InvalidName exception.
(4) Consumers
A new valuetype ConsumerDescription is introduced to carry information about a
consumer port.
valuetype ConsumerDescription : PortDescription
{
public EventConsumerBase consumer;
};
typedef sequence<ConsumerDescription> ConsumerDescriptions;
The consumer variable holds the object reference to the interface of the event
sink.
In the Events interface, two operations are added to introspect consumes ports.
interface Events {
ConsumerDescriptions get_all_consumers ();
ConsumerDescriptions get_named_consumers (in
NameList names)
raises (InvalidName);
// other operations as before
}; The get_all_consumers operation returns information about all consumer ports in
the component's inheritance hierarchy as a sequence of ConsumerDescription
values. The order in which these values occur in the sequence is not specified.
For components that do not consume any events (e.g., a basic component), this
operation returns a sequence of length zero.
The get_named_consumers operation returns information about all consumer
ports denoted by the names parameter as a sequence of ConsumerDescription
values. The order in which these values occur in the sequence is not specified. If
any name in the names parameter is not a valid name for an event sink in the
component's inheritance hierarchy, the operation raises the InvalidName
exception. A component that does not provide any consumers (e.g., a basic
component) will have no valid name parameter to this operation and thus shall
always raise the InvalidName exception.
(5) Emitters
A new valuetype EmitterDescription is introduced to carry information about an
emits port.
valuetype EmitterDescription : PortDescription
{
public EventConsumerBase consumer;
};
typedef sequence<EmitterDescription> EmitterDescriptions;
The consumer variable holds the object reference that is currently connected to
the event source, or a nil reference if there is no connection.
In the Events interface, two operations are added to introspect emits ports.
interface Events {
EmitterDescriptions get_all_emitters ();
EmitterDescriptions get_named_emitters (in
NameList names)
raises (InvalidName);
// other operations as before
};
The get_all_emitters operation returns information about all emitter ports in the
component's inheritance hierarchy as a sequence of EmitterDescription values.
The order in which these values occur in the sequence is not specified. For
components that do not emit any events (e.g., a basic component), this operation
returns a sequence of length zero.
The get_named_emitters operation returns information about all emitter ports
denoted by the names parameter as a sequence of EmitterDescription values. The order in which these values occur in the sequence is not specified. If any
name in the names parameter is not a valid name for an emitter port in the
component's inheritance hierarchy, the operation raises the InvalidName
exception. A component that does not provide any emitters (e.g., a basic
component) will have no valid name parameter to this operation and thus shall
always raise the InvalidName exception.
(6) Publishers
A new valuetype PublisherDescription is introduced to carry information about a
publishes port. Information about a subscriber is held in a new valuetype
SubscriberDescription.
valuetype SubscriberDescription
{
public Cookie ck;
public EventConsumerBase consumer;
};
typedef sequence<SubscriberDescription> SubscriberDescriptions;
valuetype PublisherDescription : PortDescription
{
public SubscriberDescriptions consumers;
};
typedef sequence<PublisherDescription> PublisherDescriptions;
The consumer variable in SubscriberDescription holds one object reference that
is currently connected to the event source, and the Cookie identifying the
subscription.
In the Events interface, two operations are added to introspect publishes ports.
interface Events {
PublisherDescriptions get_all_publishers ();
PublisherDescriptions get_named_publishers (in
NameList names)
raises (InvalidName);
// other operations as before
};
The get_all_publishers operation returns information about all publisher ports in
the component's inheritance hierarchy as a sequence of PublisherDescription
values. The order in which these values occur in the sequence is not specified.
For components that do not publish any events (e.g., a basic component), this
operation returns a sequence of length zero. The get_named_publishers operation returns information about all publisher
ports denoted by the names parameter as a sequence of PublisherDescription
values. The order in which these values occur in the sequence is not specified. If
any name in the names parameter is not a valid name for a publisher port in the
component's inheritance hierarchy, the operation raises the InvalidName
exception. A component that does not provide any publishers (e.g., a basic
component) will have no valid name parameter to this operation and thus shall
always raise the InvalidName exception.
(7) Introspecting all ports
A new valuetype ComponentPortDescription is introduced to describe all ports of
a component.
valuetype ComponentPortDescription
{
public FacetDescriptions facets;
public ReceptacleDescriptions receptacles;
public ConsumerDescriptions consumers;
public EmitterDescriptions emitters;
public PublisherDescriptions publishers;
};
A new operation is introduced on the CCMObject interface to retrieve all port
descriptions.
interface CCMObject : Navigation, Receptacles, Events
{
ComponentPortDescription get_all_ports ();
// other operations as before
};
The get_all_ports operation returns a value of type ComponentPortDescription
containing information about all facets, receptacles, event sinks, emitted events
and published events in the component's inheritance hierarchy. The order in
which the information occurs in these sequences is not specified. If a component
does not offer a port of any type, the associated sequence will have length zero.

The use of the state keyword in the Components::Enumeration valuetype,
introduced by issue 3099 and extended in issue 3418, is not correct
syntactically. Also, anonymous sequences have been deprecated, so the
definition of the Components::Enumeration state is incorrect in this sense
as well.

Amend the definition of Components::Enumeration given by both issues
3099 and 3418.

The CCM exceptions mapped from EJB standard exceptions need to be defined
explicitly in OMG IDL. The resolution to issue 3182 introduces new CCM
standard exceptions Components::CreateFailure, Components::FinderFailure
and Components::RemoveFailure but it does not define them explicitly.

Require to explicitly define the Components::CreateFailure,
Components::FinderFailure and Components::RemoveFailure exceptions.

in both documents orbos/99-07-01/6.3 and ptc/99-10-40/615.3 the language
mapping is noted as open issue.
Where are the language mappings for components ?

Use document http://www.omg.org/cgi-bin/doc?ccm/2001-11-01 as “Components
Language Mapping”.

There is no meta model for the CIDL language from orbos/99-07-01 in
orbos/99-07-02.

A metamodel for CIDL is defined.

In ccm/01-08-03, section 3.6, there is a sentence

"In isolation, the scope token represents the scope of the
specification in which it occurs."

It is not clear what an "isolated scope token" is, since the scope
token is allowed only as part of a <scoped_name>, but never appears in
isolation. The intended meaning of this sentence should be clarified.

It is apparent that the author intended “in isolation” to mean “if one considers the
significance of the scope token independently from the specification in which it
occurs” since “::” in isolation with no suffixed part of a specification has no
meaning. Since the scope token by the nature of its definition delimits the
scope(s) of the specification in which it occurs there is little need to reiterate what
is meant by the definition of “::” as a “scope token”. However, it may be helpful to
some readers to stress that the scope token is simply a scope delimiter.

After reading the definition of the import declaration, it is not at
all clear what its effect is.

Suppose the "well-known set of IDL specifications" consists of

module A {
	module B {
		interface C {
				struct S {long a;};
			};
	};
};

Now consider the import statement

import A::B;

According to the draft, "Names that occur in IDL declarations within
the importing specification may be resolved to definitions in imported
scopes." What is a "Name" in this context? Is it an <identifier>, or
is it a "<scoped_name>"?

It is unclear whether in this context, the definition

interface D : C {};

would be correct or not. The spec may be interpreted that name "C"
resolves to ::A::B::C, i.e. that the name "C" is appended to the
imported scopes, forming a fully-scoped name. If that is the intended
meaning, the text should explain how to deal with conflicts.

Alternatively, given the text "Imported IDL name scopes exist in the
same space as names defined in subsequent declarations in the
importing specification." would suggest that

interface D : B::C {};

is well-formed: "B" would be the name of the imported scope, so it
exists in the same space "D", and can thus be used for qualifications.

Furthermore, the text could be understand to mean that

interface D : ::A::B::C {};

is allowed. The "definition in the imported scope" has the name
"A::B::C", so this is the name to be used in the importing
specification.

“Name” here is meant to be an identifier name (part of the form <scoped-name>::<
identifier>). Interpretations and corresponding examples of statements
made regarding names and scopes should be discussed fully in ccm/01-08-03
section 3.20 “Names and Scoping” starting on page 3-69.

In ccm/01-08-03, a sentence says "IDL module definitions may re-open
modules defined in imported name scopes."

Now, consider the following "well-defined set of IDL definitions":

module Y{};
module A{
  module Y{};
};
module B{
  module Y{};
};

and the import statements

import A;
import B;

Clearly, A::Y and B::Y are "modules defined in imported name
scopes". Does that mean that specifying

module Y{
  interface another_interface{};
};

is now valid? If so, which namespace is extended?

It may be that this is meant to be an error (if so, where does it say
that?). In that case, consider the case that there was only a single
import:

import A;

Then, if this means that A::Y is extended, how could I specify a
re-opening of ::Y?

Alternatively, it may be that the authors thought of re-opening Y in
the form of

module A::Y{
  interface another_interface{};
};

That, of course, is illegal syntax. Yet another interpretation is that
the draft intended to allow

module A{
  module Y{
    interface another_interface{};
  };
};

However, this appears to be possible even without any import
statement.

ccm/01-08-04 says

"When a name scope is imported, the names of the enclosing scopes in
the fully-qualified pathname of the enclosing scope are exposed within
the context of the importing specification, but their contents are not
imported.  An importing specification may not re-define or re-open a
name scope which has been exposed (but not imported) by an import
statement."

Now consider the following "well-defined set of IDL specs":

module X {
	module Y {
           module Z{};
	};
};

and the following import statement

import X::Y;

Now, it appears that this declaration would make it ill-formed to
specify

module X{
   interface another_interface{};
};

since "X" is an exposed scope. That appears to be inconsistent, since
clearly, reopening "X" is allowed without the import statement.

As indicated by the author of the issue, denying the reopening of visible name
scopes is inconsistent with the behavior of a similar non-importing specification.
Conceptually, there is no issue in defining or opening name scopes that are
identical to visible name scopes since only imported scopes can be directly
referenced or reopened (in the case of modules).

I wanted to point out that the use of the name "ref" or "Ref" in
> the introspection API may be a problem because "ref" is a
> reserved word in PSDL and therefore any PSDL file that
> includes the CCM IDL file will cause compiler errors (this has
> happened to me when using the OpenORB PSDL compiler).  If at
> all possible we should change the use of "ref" to "reference"
> or something else in the final version of the spec.

All the OMG IDL definitions specified by the “CORBA 3.0 New Components
Chapters” document ptc/2001-11-03 are provided into the ptc/2001-11-03/
OMG_IDL/Components.idl file and are been correctly compiled on various
IDL2, IDL3, CIDL, and PSDL compilers.

In order to compile the Components.idl file with a compiler
compliant with OMG IDL2/IDL3/CIDL/PSDL grammars simultaneously,
it is required to apply some changes in CCM APIs:

* In ptc/2001-11-03 draft chapter 61 page 61-225, the following IDL

  valuetype FacetDescription : PortDescription { public Object facet; };

  should be replaced by

  valuetype FacetDescription : PortDescription { public Object facet_ref; };

  because 'facet' is a CIDL keyword.

* In ptc/99-10-04 chapter 62 page 62-141, the following IDL is defined

  exception Rollback { };
  // ...
  local interface Transaction {
    // ...
    void commit () raises (Rollback, NoTransaction, HeuristicMixed,
                           HeuristicRollback, Security, SystemError);
    void rollback () raises (NoTransaction, Security, SystemError);
    // ...
  };

  Here there is a conflit name between the exception Rollback
  and the operation rollback.

  In order to avoid this, the exception Rollback should be renamed
  RollbackError. Then the previous IDL should be replaced by:

  exception RollbackError { };
  // ...
  local interface Transaction {
    // ...
    void commit () raises (RollbackError, NoTransaction, HeuristicMixed,
                           HeuristicRollback, Security, SystemError);
    void rollback () raises (NoTransaction, Security, SystemError);
    // ...
  };

  In the commit operation description page 62-142, the Rollback exception
  should be replaced by RollbackError.

  In table 64-7 page 64-197, the Rollback exception of the commit operation
  should be replaced by RollbackError.

* In ptc/99-10-04 chapter 62 page 62-151, the 1st 'home' parameter
  of the HomeRegistration::register_home and unregister_home operations
  implies a parser error with a CCM IDL compiler as 'home' is a keyword.

  The 'home' parameters should be replaced by 'home_ref'
  Ditto in the following 'register_home' and 'unregister_home' 
  operation descriptions.

* In ptc/99-10-04 chapter 62 page 62-155, the following IDL

    get_oid_from_ref (in Object ref)

  should be replaced by

    get_oid_from_ref (in Object objref)

  because 'ref' is a PSDL keyword.

  In the 'get_oid_from_ref' operation description page 62-156,
  replace 'The ref parameter' by 'The objref parameter'.

* In ptc/99-10-04 chapter 62 page 62-162, the following IDL

    get_cid_from_ref (in Object ref)

  should be replaced by

    get_cid_from_ref (in Object objref)

  because 'ref' is a PSDL keyword.

  In the 'get_cid_from_ref' operation description page 62-163,
  replace '(ref)' by '(objref)'.

* In ptc/2001-11-03 draft chapter 69 page 69-551, the following IDL

    void remove_container(in Container ref) raises (RemoveFailure);

  should be read as

    void remove_container(in Container cref) raises (RemoveFailure);

  because 'ref' is a PSDL keyword.

* In ptc/2001-11-03 draft chapter 69 page 69-553, the following IDL

    void remove_home(in CCMHome ref) raises (RemoveFailure);

  should be read as

    void remove_home(in CCMHome href) raises (RemoveFailure);

  because 'ref' is a PSDL keyword.

Accept the previous required changes.

generic operations for subscribing and unsubscribing at publishing ports of components should have the same funtionality as the specific ones. Therefore the generic unsubscribe operation should return the unsubscribed consumer reference like the specific operation does. proposal: change 

void unsubscribe (in FeatureName publisher_name, in Cookie ck) raises (InvalidName, InvalidConnection); 

to 

EventConsumerBase unsubscribe (in FeatureName publisher_name, in Cookie ck) raises (InvalidName, InvalidConnection); 

Resolution:
In order to be consistent, the generic operation for unsubscribing to publisher ports of components must return the unsubscribed consumer reference like the specific generated operations do.
Moreover, the generic operation for disconnecting from receptacle ports of components must return the previously connected object reference like the specific generated operations do

The "eventtype" keyword defined in Section 3.2.4 of the "CORBA 3.0 New
Components Chapters" (ptc/2001-11-03) will make the Notification
Service IDL un-compilable because Notification Service defines a
struct called "EventType" in Section 3.1 of formal/00-06-20.

I guess one of the specs will have to change.

Resolution:
The Notification Service IDL defined in formal/00-06-20 could not be compiled with a CORBA 3.0 IDL compiler because the identifier EventType is now interpreted as the eventtype keyword. 
In OMG IDL, the only way to escape from the keyword interpretation is to put an underscore in front of identifiers. The generated code will remain the same.

The id attribute of the idl element in a
Software Package Descriptor currently
contains the Repository Id of the component.

I suggest to change this to the Repository
Id of the home, as the home implies the
component, but not vice versa. This makes
it easier for the deployment application to
find out about the home interface, e.g. for
the purpose of configuring properties.

On page 69-532 (ptc/01-11-03), the
registercomponent element of an Assembly
Descriptor is defined to optionally
contain an emitsidentifier and publishes-
identifier element, in order to register
an event source in the Naming or Trading
Service. There is also a note saying, "In
the case of events, what gets registered?"

I suggest to replace the emitsidentifier
and publishesidentifier elements with the
consumesidentifier element, and to change
the first two paragraphs to read:

"The registercomponent element is to specify
that a component, a provided interface, or
an event consumer interface should be regis-
tered with a naming service or trader.

If a consumesidentifier or publishesidentifier
is specified, then that element is registered.
If none of the above are specified, then it is
implied that the component itself is to be
registered."

Emitter or publisher ports could not be registered with the Naming or Trader services because these ports have no associated object references. In fact, only components, facets, and  event consumers have an associated object reference and could be registered with these two services. Then the description of the registercomponent element must be updated to be consistent.
Moreover, registering an object reference with the Trader Service requires to provide a trader service type name and a set of trader properties. This is reflected by the traderexport element. But the registerwithtrader only contains a set of trader properties and no trader service type name. Then the description of the registerwithtrader must be updated to be consistent

On page 69-521 (ptc/01-11-03), the connectevent
element of an Assembly Descriptor is defined as

<!ELEMENT connectevent (consumesport,
                        (emitsport |
                         publishesport))>

This does not allow for emits and publishes
ports to be connected to existing consumer
interfaces that are registered in the naming
or trading service. I suggest to change that
element in the spirit of connectinterface to

<!ELEMENT connectevent (emitsport |
                        publishesport) ,
                       (consumesport |
                        existinginterface)>

Apply the proposed change allowing for emits and publishes ports to be connected to existing consumer interfaces.
However, do not reverse consumesport and emits/publishesport to be compatible with already existing and used XML descriptors

In 01-11-03.pdf page 61-255


Given a base home definition with a primary key (H, T, K), and a derived home
definition with no primary key (H', T'), such that H' is derived from H, then the
definition of H' implicitly includes a primary key specification of type K, becoming
(H', T', K). The implicit interface for H' shall have the form specified for an
implicit interface of a home with primary key K and component type T'.


In same document section 615.3.3.6 Home I see no mention that a keyless
home that inherits from a keyed home is implicitly a keyed home and thus
the Home Implicit Executor Interface must be constructed for a keyed home
using the key type declared for the base keyed home.  Everyone agree?

A keyless home that inherits from a keyed home is implicitly a keyed home and thus the Home Implicit Executor interface must be constructed as a keyed home using the key type declared for the base keyed home.

In document 01-11-03.pdf section 69.8.2.8 the simple type element
of the property file descriptor excludes the types:


long long
unsigned long long
long double
wchar


Is there any reason why we can't add these types to the simple element?

Add long long, unsigned long long, long double, wchar, wstring, and fixed to the type attribute of the simple element in order to allow configuration of component and home attributes of these types.
Moreover remove the second occurrence of the short type.

chapter 69.4.4
        the sample componentkind definition given as an entity with
"process" lifetime seems
        unadapted as described in 69.4.5.49, we can give a best lifetime
with "container"

"process" is not a possible value for the lifetime attribute of the servant element (see formal/02-06-65 page 6-37). Possible values are component, method, transaction, or container. Then the example must be updated in order to be coherent.

chapter 69.4.5.4
        "The information obtained by (...) it allows component assembly
tools to decide WHAT ports
        on a component are capable (...)"
        it seems that the word "which" would be better than "what" in
this sentence

chapter 69.4.5.16
        this eventpolicy element is said to be child element of
corbacomponent
        in fact it can be child element of: consumes, emits, publishes
        but it's NOT a child element of corbacomponent

Correct the false sentence as eventpolicy is a child element of consumes, emits, publishes and not a child element of corbacomponent.

chapter 69.7.2.25
        the given reference to the fileinarchive element is wrong
(69.3.2.11);
        the right one is 69.3.2.12

chapter 69.7.2.38
        the processcollocation element given in this chapter lacks a
DESTINATION child element
        right one:
<!ELEMENT processcollocation
                        (usagename?
                        , impltype?
                        ,       (homeplacement
                                | extension
                                )+
                        ,destination?
                        )>
<!ATTLIST processcollocation
                        id      ID      #IMPLIED
                        cardinality CDATA "1">

As described in formal/02-06-65, page 6-49 and page 7-17, destination is a child element of processcollocation. Then the processcollocation element must be updated to be coherent.

chapter 695.4
        the elements aren't in the alphabetical order
        proxyhome must be placed before publishesidentifier

Apply the alphabetical order on the proxyhome element defined in the chapters 6 and 7 of the formal/02-06-65 document.

Productions must be renumbered : 134 -> 1, ...


In all productions, replace ...storage_home... by ...storagehome... and
...storage_type...
by storagetype...

Require to update the numbering of CIDL productions in the chapter 2 of the Adopted CORBA Components Specification (formal/02-06-65).
Require to replace all occurrences of storage_home by storagehome in CIDL productions (chapter 2 in formal/02-06-65).
Moreover, there is no occurrence of storage_type in formal/02-06-65.

 - Capital letters are not appropriated. Correct "storageHome" with
"storagehome".
    - The keyword "catalog" must be removed as it was removed from PSDL.

Replace storageHome by storagehome in Table 2-2, page 2-3, formal/02-06-65.
As the catalog keyword was removed from the Persistent State Definition Language, remove all references to the catalog concept in the Adopted CORBA Components Specification (formal/02-06-65). 

Productions 140, 141, 142 and 143 must be removed. Catalog has been
removed
 from the PSS specification.
Production 145 : <home_executor_body> refers to <stored_on_dcl> which is
defined in production 151
 as <home_persistence_dcl>. Pick one or the other and changes references
as required ...
Productions 149 and 150 are not valid any more. Remove them and add a
new production :
    <abstract_storage_home_name> ::= <identifier>
    identifier must be the name of an abstract storagehome previously
declared

As the catalog keyword was removed from the Persistent State Definition Language, remove all references to the catalog concept in the Adopted CORBA Components Specification (formal/02-06-65). 
Replace stored_on_dcl by home_persistence_dcl in the CIDL production 12 in order to be consistent.
Remove the CIDL abstract_storage_home_name and abstract_storage_home_label productions as the PSDL already defines the abstract_storagehome_name production. Replace all occurrences of the abstract_storage_home_name production by the abstract_storagehome_name production

In the CCM specification document ptc/2001-11-03 page 61-227
the 'session' word should be removed from the OMG IDL 3.0 
example, i.e.:


 component baz session {


should be replaced by:


 component baz {

1.   69.8.2.1 The properties Root Element, page 69-537
Properties Element Cardinality. Suggested change is to replace "*" with "
+".
Why does it make sense to have an empty properties file, since the
properties are
optional references in the Software Package DTD, CORBA Component DTD, and
Component Assembly DTD?


Current Format


<!ELEMENT properties
( description?
, ( simple
| sequence
| struct
| valuetype
)*
) >


Suggested New Format


<!ELEMENT properties
( description?
, ( simple
| sequence
| struct
| valuetype
)+
) >

None as this is deferred to the final report of the Components 1.1 RTF.
Revised Text:
None as this is deferred to the final report of the Components 1.1 RTF.

The name of the create operation in the AssemblyFactory Interface shall
be renamed to a more specific identifier. Create is often used in other
interfaces and this may lead to problems e.g. in inheritance relationships.


suggested change:


create -> create_assembly

Proposed resolution:


The Adopted CORBA Components Specification (formal/02-06-65)
always contains the section 4.4.1.4 at page 4-36.


However, this section was removed in the ptc/01-11-03 document
by the resolution of the issue 3937 of the Final Report of
Components December 2000 FTF (ptc/01-11-02).


Proposed revised text:


In formal/02-06-65 page 4-36, remove the section 4.4.1.4.

The Adopted CORBA Components Specification (formal/02-06-65) always contains the section 4.4.1.4 at page 4-36.
However, this section was removed in the ptc/01-11-03 document by the resolution of the issue 3937 of the Final Report of Components December 2000 FTF (ptc/01-11-02).
Moreover, the CCM2Context interface in section 4.4.1.1 page 4-33 always contains the get_event operation which was removed in document ptc/01-11-03 page 62-358.

In the Adopted CORBA Components Specification (formal/02-06-65),
page 6-4, section 6.3.2.1, the version attribute of the softpkg
element is tagged as #OPTIONAL and is tagged as #IMPLIED at page 7-5.
As #OPTIONAL is not valid in XML, then replace it by #IMPLIED.


In chapter 7, the softpkg XML DTD does not contain the
ins and objref elements which they are used by the repository
element described at page 7-4. Add them.


Proposed revised text:


In formal/02-06-65:


At page 6-4, section 6.3.2.1, replace #OPTIONAL
by #IMPLIED for the version attribute of the softpkg element.


At page 7-3, add before the humanlanguage element


    <!ELEMENT ins EMPTY >
    <!ATTLIST ins
        name CDATA #REQUIRED >


At page 7-4, add before the os element


    <!ELEMENT objref EMPTY >
    <!ATTLIST objref
        string CDATA #REQUIRED >

In the Adopted CORBA Components Specification (formal/02-06-65), page 6-4, section 6.3.2.1, the version attribute of the softpkg element is tagged as #OPTIONAL and is tagged as #IMPLIED at page 7-5.
As #OPTIONAL is not valid in XML, then replace it by #IMPLIED.
In chapter 7, the softpkg XML DTD does not contain the ins and objref elements which they are used by the repository element described at page 7-4. Add them.

The Adopted CORBA Components Specification (formal/02-06-65)
always contains some texts removed by the Components December
2000 RTF (ptc/01-11-02 and ptc/01-11-03). See at


   formal/02-06-65              ptc/01-11-03


   page 1-24 and 25             page 61-241
   page 1-26                    page 61-243
   page 1-28                    page 61-245
   page 4-37                    page 62-363
   page 6-67                    page 69-542
   page 6-72                    page 69-548
   page 8-23                    page 70-601


Remove these old texts once again.


Proposed revised text:


Following must be applied on formal/02-06-65.


At pages 1-24 and 1-25, remove


    module <module_name> {
        module <component_name>EventConsumers {
            interface <event_type>Consumer;
        };
        interface <component_name> : Components::CCMObject {
            Components::Cookie subscribe_ <source_name> (
              in <component_name>EventConsumers:: <event_type>Consumer
consumer)
              raises (Components::ExceededConnectionLimit);
            <component_name>EventConsumers:: <event_type>Consumer
              unsubscribe_<source_name> (in Components::Cookie ck)
              raises (Components::InvalidConnection);
        };
        module <component_name>EventConsumers {
            interface <event_type>Consumer :
Components::EventConsumerBase {
                void push (in <event_type> evt);
            };
        };
    };


At page 1-26, remove


    module <module_name> {
        module <component_name>EventConsumers {
            interface <event_type>Consumer;
        };
        interface <component_name> : Components::CCMObject {
            void connect_ <source_name> ( in
<component_name>EventConsumers::
                <event_type>Consumer consumer )
                raises (Components::AlreadyConnected);
            <component_name>EventConsumers:: <event_type>Consumer
disconnect_
                <source_name>() raises (Components::NoConnection);
        };
        module <component_name>EventConsumers {
            interface <event_type> Consumer :
Components::EventConsumerBase {
                void push (in <event_type> evt);
            };
        };
    };


At page 1-28, remove


    module <module_name> {
        module <component_name>EventConsumers {
            interface <event_type>Consumer;
        };
        interface <component_name> : Components::CCMObject {
            <component_name>EventConsumers:: <event_type>Consumer
get_consumer _<sink_name>();
        };
        module <component_name>EventConsumers {
            interface <event_type>Consumer :
Components::EventConsumerBase {
                void push (in <event_type> evt);
            };
        };
    };


At page 4-37, remove in Session2Context interface 
the two occurrences of PortableServer::ObjectId.


At page 6-67, remove


    Note   Of the interfaces described below, only
ComponentInstallation,
    AssemblyFactory, and Assembly are required by this specification;
the other
    interfaces are included for illustrative purposes and to support an
end-to-end scenario.


At page 6-72, remove


    exception InvalidLocation { };


At page 8-23, remove Figure 8-20.

The Adopted CORBA Components Specification (formal/02-06-65) always contains some texts removed by the Components December 2000 RTF (ptc/01-11-02 and ptc/01-11-03). See at
formal/02-06-65	ptc/01-11-03
page 1-24 and 25	page 61-241
page 1-26		page 61-243
page 1-28		page 61-245
page 4-37		page 62-363
page 6-67		page 69-542
page 6-72		page 69-548
page 8-23		page 70-601
Remove these old texts once again.

In ptc/01-11-03, page 64-410, there is the following note


    Issue   This table will be completed after the Interface Repository
chapter is ready.


Then Table 5-13 in formal/02-06-65 would be completed.

Resolution:
None as this is deferred to the final report of the Components 1.1 RTF.
Revised Text:
None as this is deferred to the final report of the Components 1.1 RTF

Both the CORBA spec (formal/02-06-01 page 3-61) and the CCM spec (formal/02-06-65 page 1-51) state that "A derived component type may not directly support an interface." Moreover the sentence you depicted is a contradiction with the formal/02-06-65 section 1.3.2.4 page 1-7.
Resolution:


In formal/02-06-65 page 1-51 and formal/02-06-01 page 3-61 replace the sentence


"A derived component type may not directly support an interface."


with


"If a derived component type directly supports one or more IDL interfaces, the component interface is derived from both  the interface of its base component type and the supported interfaces."

In OMG document formal/02-06-65, in section "1.3.3 Component Body", there
is this text:


   "Declarations for facets, receptacles, event sources, event sinks,
    and attributes all map onto operations on the component's equivalent
    interface.  These declarations and their meanings are described in
    detail below."


In the following sections, I see facets, receptacles, event sources,
and event sinks described, but I see no mention of attributes.
It would be usefult to have an example of attributes in an appropriate
place, as outlined by section 1.3.3.


In section "1.10 Configuration with Attributes", I see that configurators
are described, but I see no example of using attributes directly
to configure a component.


It would be very useful to include a small example to illustrate
how to configure a component directly by using attributes.


Diego Sevilla Ruiz <dsevilla@ditec.um.es> gave this
C++ example on the CCM mailing list ( http://moriarty.dif.um.es/mailman/listinfo/ccm ):


======================================================


component Whatever
{
        attribute long cacheMaxKb;
};


home WhateverHome manages Whatever
{
};


// C++
WhateverHome_var weh = // obtain ref
Whatever_var we = weh->create();


we->cacheMaxKb(200);


we->configuration_complete();


======================================================


I don't suggest that this example be used verbatim,
but a similar example would be useful to have in the
CCM spec.

The Convenience Document has sections 1, 3, 4, 5 essentially empty except for 'Editorial Comment: Needs to be completed'. They do need to be completed!
Even worse, section 2, Conformance, also has a similar 'needs to be completed': though it does contain some text it is nothing like a conformance statement.
I found it unclear whether the spec was providing a normative metamodel or just a normative profile: the text to be added to Section 1 (Scope)  and Section 2 (Conformance) should clarify.

OMG Issue No: 7902
The Convenience Document has sections 1, 3, 4, 5 essentially empty except for
'Editorial Comment: Needs to be completed'. They do need to be completed!
Even worse, section 2, Conformance, also has a similar 'needs to be completed':
though it does contain some text it is nothing like a conformance statement.
I found it unclear whether the spec was providing a normative metamodel or just
a normative profile: the text to be added to Section 1 (Scope) and Section 2
Section 1 “Scope”, page 1: replace the sentence “Editorial Comment:
Needs to be completed” with the following text:
”The CORBA Component Model (CCM) is a comprehensive component
architecture based on the reliable and well-proven CORBA middleware. It
contains concepts that allow multi-interface components, event based
communication, port based configuration and flexible implementation
structures. These concepts are specified in the CCM metamodel defined
in the OMG CORBA Components Specification, formal/02-06-65.
This specification provides the normative UML Profile for CORBA
Components. The Profile defines a set of UML 1.5 extensions to represent
CCM concepts like CORBA Component or CORBA Home. It is based on
the UML Profile for CORBA, formal/02-04-01 and extends this Profile to
allow the modeling of additional concepts of ComponentIDL and
Component Implementation Framework (CIF) according to the CCM OMG Issue No: 7902
This specification is compliant with the Model Driven Architecture (MDA)
defined by the OMG and provides a standard means for expressing CCM-based
applications (PSMs) using UML notation and thus to support all
kind of MDA model transformations such PIM ¡÷PSM or PSM ¡÷PSM and
also work with MOF repositories.¡¨
¡E Section 2 ¡§Conformance¡¨, page 1: replace the text:
¡§This specification is compliant with the Model Driven Architecture (MDA)
defined by the OMG. The UML Profile for CORBA Components
specification was designed to provide a standard means for expressing
CCM-based applications (PSMs) using UML notation and thus to support
all kind of MDA model transformations such PIM ¡÷PSM or PSM ¡÷PSM
and also work with MOF repositories.¡¨ with the following text:
¡§This specification defines three conformance points. Implementations
must support all these conformance points:
¡E Implementation of the UML Profile for CORBA defined in
formal/02-04-01.
¡E Implementation of the ComponentIDL Profile defined in section
8.1.
¡E
Implementation of the CIF Profile defined in section 8.2.¡¨
¡E Section 3 ¡§Normative References¡¨, page 1: add the text:
¡§The following normative documents contain provisions which, through
reference in this text, constitute provisions of this specification. For dated
references, subsequent amendments to, or revisions of, any of these
publications do not apply.
¡E Unified Modeling Language (UML) Specification, Version 1.5
¡E CORBA Components Specification, Version 3.0
¡E The UML Profile for CORBA, Version 1.0
¡E MOF Specification, Version 1.4¡¨
and add in References, page 37 the reference to the UML Profile for
CORBA:
¡§[7] The UML Profile for CORBA, OMG TC Document formal/02-04-01¡¨
¡E Section 4 ¡§Terms and Definitions¡¨, page 1: replace the text:
"Editorial Comment: Needs to be completed (or possibly eliminated).¡¨ with “artifact
An element which descibes abstractions from programming language
constructs like classes.
component
A basic metatype in CORBA which is a specialization and extension of an
interface definition.
component type
A specific, named collection of features that can be described by an IDL
component definition or a corresponding structure in an Interface
Repository.
facet
A distinct named interface provided by the component for client
interaction.
factory
A home operation which supports creation semantics.
finder
A home operation which supports search semantics.
home
A metatype that acts as a manager for instances of a specified component
type.
port
A surface feature through which clients and other elements of an
application environment may interact with a component.
receptacle
A named connection point that describes the component’s ability to use a
reference supplied by some external agent.
segment
An element which describes a segmented implementation structure for a
component implementation.”
Section 5 “Symbols”, page 1: replace the text: "Editorial Comment: Needs
to be completed (or possibly eliminated).” with
”CCM CORBA Component Model
CIF Component Implementation Framework
IDL Interface Definition Language
MDA Model Driven Architecture  PIM Platform Independent Model
PSM Platform Specific Model
UML Unified Modeling Language”

Section 7, Overview consists only of 3 bullets that are instructions to an author rather than an overview e.g. "Explain relations to BaseIDL package"

On Page 18 - Figure 11 Home mapping. To me, it doesn't seems properly that CORBAValue inherits from AssociationClass. Perhaps it make sense that the HomeDef gets an attribute with name 'primary key'. 

Resolution:
o The CORBAValue doesn't extend the metaclass AssociationClass, but
Class. Define a new stereotype <<CORBAPrimaryKey >> that extends the
metaclass Association.
o Add new relationship between CORBAHome and CORBAValue: an
Association with defined stereotype << CORBAPrimaryKey >>.
Discussion:
o Update the Table 7, page 12-13: add the stereotype
<<CORBAPrimaryKey>> for Association (see Issue 7914, page 21 (Table
5) )
o Update the following text on the page 12:
"A "CORBAHome" can be associated with a primary key (necessary for
persistent components). There is exactly one key instance for each
(persistent component, home) instance couple. To enforce this constraint,
the primary key is represented using a "CORBAValue" stereotyped
AssociationClass. The "CORBAValue" stereotype was defined in the UML
Profile for CORBA [4]." to
"A "CORBAHome" can be associated with a primary key (necessary for
persistent components). There is exactly one key instance for each
(persistent component, home) instance couple. To enforce this constraint,
the primary key is represented using a "CORBAValue" stereotyped Class.
The "CORBAValue" stereotype was defined in the UML Profile for CORBA
[7]. The relationship between home and primary key is represented by an
Association with defined stereotype "CORBAPrimaryKey".
UML Profile for CORBA Components FTF2 Disposition: Resolved
OMG Issue No: 7911
Document ptc/2004-05-14 15
o Update the example Figure 7, page 15: delete the relationship between
Key and C1Home classes and add the stereotyped with
<<CORBAPrimaryKey>> association between these both classes as
shown below:
<<CORBAComponent>>
C1
<<CORBAComponent>>
C2
<<CORBAHome>>
C1Home
<<CORBAHome>>
C2Home
<<CORBAValue>>
Key
<<CORBAInterface>>
I1 <<CORBAInterface>>
I2
<<CORBAHome>>
myHome
<<CORBAManages>>
1 *
<<CORBAManages>>
1 *
<<CORBAFinder>>
+findByName(in name:string)
<<CORBAFactory>>
+create(in name:string)
<<CORBAManages>>
1
*
<<CORBASupports>> <<CORBASupports>>
<<CORBAValue>>
PrimaryKeyBase _key : string
Components
1 <<CORBAPrimaryKey>>
1
o Update the Figure 11, page 18: according to the Issue 7914 change all
dependency stereotypes <<BaseElement>> into <<stereotype>>, add the
graphical relation "represents" between ValueDef and CORBAValue,
delete the metaclass AssociationClass and add the dependency
relationship between CORBAValue and Class. Add the new metaclass
CORBAPrimaryKey (ComponentIDLProfile package), add the graphical
relation "represents" between the association Key_Home and
CORBAPrimaryKey and add the stereotyped with <<stereotype>>
dependency relationship between CORBAPrimaryKey and Association
metaclass. The updated figure is shown below.
ComponentIDL
<<metaclass>>
ComponentDef
ComponentIDLProfile
UML
{represents}
{represents}
{represents}
{represents}
{represents}
HomeDef
FinderDef
FactoryDef
ValueDef
<<stereotype>>
CORBAHome
<<stereotype>>
CORBAManages
<<stereotype>>
CORBAFactory
<<stereotype>>
CORBAFinder
<<stereotype>>
CORBAValue
<<metaclass>>
Class
<<metaclass>>
Association
Operation
1
primary_key
*
0..1
factory *
1
finder
* homeEnd 1
components *
<< stereotype >>
<< stereotype >>
<< stereotype >>
<< stereotype >>
<< stereotype >>
homeEnd
Key_Home
<<metaclass>>
CORBAProfile
BaseIDL
<<stereotype>>
CORBAPrimaryKey
{represents}
<< stereotype >>
o Delete in section 7.1, page 3 the bullet "AssociationClass".

Section 7.2 states says that "BaseIDL that is a MOF-compliant
description of the pre-existing CORBA Interface Repository that is
already specified in the UML Profile for CORBA" - however in the
document referred to for the latter (ptc/00-10-01) there is no mention
of BaseIDL - in fact there is no metamodel only a pure profile. BTW a
more up-to-date reference would be formal/02-04-01. This spec is clearly
dependent on BaseIDL and so it's important to have a proper reference
(and this should be in Section 3). In fact the appropriate reference for
BaseIDL seems to be the CORBA components spec.
 
The front page of convenience document, and document footer, still refer
to it as a (Final) Adopted Specification

Resolution:
o Replace the text on the page 4
o Replace the document number in section 7.1 "ptc/00-10-01" with
"formal/02-04-01" and add the bullet "The UML Profile for CORBA,
Version 1.0" in the Section 3.
o Replace the the front page of convenience document and document footer
with "UML Profile for CORBA Components Specification, v1"
Discussion:
o Replace the text in section 7.2 on the page 4:
o "The first ComponentIDL Package expresses the Component Model
extensions. This package is related to the reference metamodel BaseIDL
that is a MOF-compliant description of the pre-existing CORBA Interface
Repository that is already specified in the UML Profile for CORBA (see
Import dependencies between UML, CORBA and CCM packages). The
CIF Package contains metaclasses and associations for definition the
programming model for constructing component implementations, and is
based on the reference ComponentIDL metamodel." with
"This package is dependent upon the BaseIDL Package which is a MOFcompliant
metamodel of the base CORBA IDL. Since these extensions are
derived from the previously-existing IDL base, it was not possible to define
UML Profile for CORBA Components FTF2 Disposition: Resolved
OMG Issue No: 7912
Document ptc/2004-05-14 17
a MOF-compliant metamodel for the extensions without defining a MOFcompliant
metamodel for the IDL base. Therefore, the BaseIDL
metamodel was specified and explained in the CORBA Components
Specification, section 8.1.1 "BaseIDL Package". The UML Profile for
CORBA is based on this metamodel. The ComponentIDL metamodel
concepts are specified and explained in the CORBA Components
Specification, section 8.1.2 "ComponentIDL Package". This document
gives only the short introduction of the ComponentIDL Package in section
8.1.1.
The CIF Package contains metaclasses and associations for definition the
programming model for constructing component implementations. This
CIF Package depends on the ComponentIDL Package since its
main purpose is to enable the modeling of implementations for
components specified using the ComponentIDL definitions. The
short introduction of the CIF Package content is given in section 8.2.1
this document.
The XMI format for the exchange of CCM metadata is provided in the
CORBA Components Specification, sections 8.3.1 and 9.4.1."

The Report should reference the document number of the Final Adopted
Spec as the base document.
 
 - Issue 7628: the final line of the resolution is too vague "add the
package...and update relations"
 
 - There should be accompanying MOF XMI (for the metamodel) and UML XMI
(for the profile).

Resolution:
o This report references the document number ptc/04-10-07 as the base
document
o MOF XMI is included in the CORBA Components Specification (formal/02-
06-65), sections 8.3.1 and 9.4.1.
Generate UML XMI and provide it to OMG.
Discussion:
o Add the sentence to the section 7.2, page: "The XMI format for the
exchange of CCM metadata is already defined in the CORBA
Components Specification, sections 8.3.1 and 9.4.1."
Add the sentence to the section 8 "CCM Profile Definition", page 5: "The
UML "virtual" metamodel of all stereotype and tagged value declarations
for the CCM Profile is provided in the OMG documents ptc/2005-01-02
(Rose model file) or ptc/2005-01-03 (XML file)".

Should use the proper notation for expressing Profiles.  The
presentation of the Profile (e.g. in Table 1) is confusing in mixing
references to the equivalent metamodel with references to the reference
metamodel (UML) being extended by the Profile. Though the diagrams in
the separate section 8.1.3 make things a lot clearer.

 Figure 1 - the import dependencies should be shown with an 'import'
stereotype

Resolution:
o Add the <<import>> stereotype.
Discussion:
o Add <<import>> stereotypes for all three Dependencies Figure 1, page 3
as follows

7.1, line1:  It's not strictly true to say that the CCM Profile
'specializes' the UML Core package: the latter is the reference
metamodel for the former.

Resolution:
o The expression is not correct: change the text
Discussion:
o Replace the word "specializes" with "depends on" in the section 7.1, first
sentence, page 3.

 - Figure 2: the arrows are not correct: they should represent a valid
MOF 1.4 Package relationship (one of clustering, generalization,
nesting, import). More seriously, since ComponentIDL is nested within
metamodel CCM it is not allowed to have an import/cluster relationship
with an external metamodel (BaseIDL in this case): MOF constraint [C49]
states that "Nested Packages cannot import or cluster other Packages or
Classes.".

Resolution:
o Update the Figure 2: delete the stereotyped with <<metamodel>> CCM
package
o The arrows should be changed in dependency arrows: the ComponentIDL
Package is dependent upon the BaseIDL Package, the CIF Package is
dependent upon the ComponentIDL Package.
o Change the Figure 2 caption
Discussion:
o Update the Figure 2 and figure caption as follows:
BaseIDL
<<metamodel>>
ComponentIDL
<<metamodel>>
CIF
<<metamodel>>
Figure 2: Package structure of CCM metamodels
o Update the text in section 7.2, page 4
"As shown in Figure 2 the whole CCM concept space represented by the
package CCM with the stereotype <<metamodel>> consists of further
packages ComponentIDL and CIF (Component Implementation
Framework). The first Package ComponentIDL expresses the Component
Model extensions. This package is related to the reference metamodel
BaseIDL that is a MOF-compliant description of the pre-existing CORBA
UML Profile for CORBA Components FTF2 Disposition: Resolved
OMG Issue No: 7917
Document ptc/2004-05-14 33
Interface Repository that is already specified in the UML Profile for
CORBA (see Import dependencies between UML, CORBA and CCM
packages). The CIF Package contains metaclasses and associations for
definition the programming model for constructing component
implementations, and is based on the reference ComponentIDL
metamodel." with the following text:
"As shown in Figure 2 the whole CCM concept space is represented by
three metamodel Packages: BaseIDL, ComponentIDL and CIF
(Component Implementation Framework).
The ComponentIDL Package expresses the Component Model extensions
to CORBA IDL. This package is dependent upon the BaseIDL Package
which is a MOF-compliant metamodel of the base CORBA IDL. Since
these extensions are derived from the previously-existing IDL base, it was
not possible to define a MOF-compliant metamodel for the extensions
without defining a MOF-compliant metamodel for the IDL base. Therefore,
the BaseIDL metamodel was specified and explained in the CORBA
Components Specification, section 8.1.1 "BaseIDL Package". The UML
Profile for CORBA is based on this metamodel. The ComponentIDL
metamodel concepts are specified and explained in the CORBA
Components Specification, section 8.1.2 "ComponentIDL Package". This
document gives only the short introduction of the ComponentIDL Package
in section 8.1.1.
The CIF Package contains metaclasses and associations for definition the
programming model for constructing component implementations. This
CIF Package depends on the ComponentIDL Package since its main
purpose is to enable the modeling of implementations for components
specified using the ComponentIDL definitions. The short introduction of
the CIF Package content is given in section 8.2.1 this document.
The XMI format for the exchange of CCM metadata is provided in the
CORBA Components Specification, sections 8.3.1 and 9.4.1.".

7.2, sentence 3: it is confusing to refer to BaseIDL as the
'reference metamodel' since that terminology has a specific meaning for
Profiles which does not apply here.

Resolution:
o Change the sentence: "This package is related to the reference
metamodel BaseIDL" to "This package is dependent upon the BaseIDL
Package".
Discussion:
o Already covered by Issue 7912.

8.1.1 the heading is 'IDL metamodel' but the caption is 'IDL3
Metamodel', and in 7.2 it is 'ComponentIDL'.

Resolution:
o change the 8.1.1 heading
o change the figure caption
o change the second sentence on the page 6 "The IDL3 language has…" in
"The ComponentIDL (known also as IDL3) language has…"
Discussion:
o Update the heading 8.1.1 (page 5) "IDL metamodel" with "ComponentIDL
metamodel"
o Update the figure caption (Figure 3, page 5) "IDL3 Metamodel" with
"ComponentIDL metamodel"
o Replace the second sentence, page 6 "The IDL3 language has…" with
"The ComponentIDL (known also as IDL3) language has…"
Disposition: Resolved

 8.1.1, 8.2.1: the description of the metamodel is very skimpy: for
example there is no description anywhere about what FinderDef is. There
should be a separate section for each class with a description of each
attribute/reference. Conversely the text also talks about 'component
types' which have 'attributes' (and ports) - this has no obvious
correspondence with the metamodel (are the attributes in the BaseIDL
package?). Likewise the text refers to a component being able to inherit
from one other interface - this is not depicted.
 
 - most of the OCL constraints make use of 'isStereotyped()' which is
not OCL, UML nor defined in this specification.
 
 - Table 10: most of the Tags seem to have no correspondence in the
metamodel e.g. containerType.

Resolution:
o This specification defines the UML Profile for CCM and not the CCM
metamodel. The CCM Metamodel was already defined and detailed
expressed in the CORBA Components Specification, OMG document
formal/02-06-65.
o The CORBA component (see ComponentIDL metamodel, class
ComponentDef) inherits from the CORBA interface (see ComponentIDL
metamodel, class InterfaceDef), and the interface has attributes and
operations (see BaseIDL metamodel in formal/02-06-65)
o A component definition may optionally support one or more interfaces, or
in the case of extended components, inherit from a component that
supports one or more interfaces. This is shown in the ComponentIDL
metamodel by the association "supportsItf" between ComponentDef and
InterfaceDef metaclasses (see page 331 in formal/02-06-65).
o The OCL constraint 'isStereotyped()' is already covered by the Issue 7914:
UML Profile for CORBA Components FTF2 Disposition: Resolved
OMG Issue No: 7920
Document ptc/2004-05-14 37
The operation isStereotyped determines whether the ModelElement has
a Stereotype whose name is equal to the input name.
isStereotyped : (stereotypeName : String) : Boolean;
self.stereotype.name = stereotypeName"
o Delete the tags that are not in the metamodel: to use these tags the CCM
metamodel has to be extended.
Discussion:
o Update the Table 10 ( page 20): delete the following tags from the table:
containerType, containerImplType, servantLifetimePolicy,
transactionPolicy, securityPolicy, eventPolicy and persistenceMechanism