Issue 5508: 69.8.2.8 The simple Element, page 69-538
Issue 5509: 69.8.2.7 The range Element, pages 69-537/538
Issue 5510: 69.8.2.3 The choices Element, page 69-537
Issue 5511: 69.8.2.9 The sequence Element
Issue 5512: Test Property - add a test property definition to the properties DTD
Issue 5513: Add the capability to define a component artifact property
Issue 5514: 69.3 Software Package Descriptor
Issue 5515: 69.3.2.15 The implementation Element, pages 69-478/479
Issue 5516: 69.8.2.7 The code Element, pages 69-474
Issue 5517: 69.3.2.15 The implementation Element, pages 69-478/479
Issue 5518: 69.3.2.25 The propertyfile Element, page 69-482
Issue 5519: 69.3.2.14 The idl Element, page 69-478
Issue 5520: Descriptor
Issue 5521: 69.3.2.2 The author Element, page 69-474
Issue 5522: Component Artifact Dependency
Issue 5523: Device Artifact Dependency
Issue 5524: Uses Relationships
Issue 5576: 69.3 AssemblyFactory Interface
Issue 5589: Description for the impltype Element?
Issue 5590: Checking XML DTD elements related to the trader service
Issue 5591: Using Configurator on CCMHome or any CORBA objects?
Issue 5594: [CCM] Interface Repository Metamodel
Issue 5639: A new exception specification is needed for CCM2Context::req_passivate()
Issue 5684: Issue on the description of the consumesidentifier element
Issue 5688: Derived component supported interface restriction (formal/2002-06-65)
Issue 5769: HomeConfigurator should not extend CCMHome
Issue 5852: Generic port connections
Issue 5858: CCM IDL style inconsistency
Issue 5870: multiple lifetime policies declaration issue
Issue 5871: 3.2.7 Compositions with Managed Storage
Issue 5898: CCM spec: insufficient examples of component attributes
Issue 5900: Section 6.4.5.52 (page 6-38)
Issue 5902: Section 6.4.5.10 (page 6-26)
Issue 5903: Section 6.4.5.26 and Section 6.4.5.30 should be moved to section 6.3
Issue 5909: Session2Context interface
Issue 5910: issue on component supporting abstract interfaces
Issue 5918: CCM Spec: attributes are listed in the ports section?
Issue 5936: context interface for home implementation
Issue 5937: 'local executor mapping'
Issue 5943: page 1-20 second bullet of the description of the disconnect operation
Issue 5944: page 1-20 the description of the get_connection operation
Issue 5945: page 1-20 and page 1-21 - editorial
Issue 5508: 69.8.2.8 The simple Element, page 69-538 (components-ftf)
Click here for this issue's archive.
Source: Raytheon (Mr. Gerald Lee Bickle, Gerald.L.Bickle(at)raytheon.com)
Nature: Uncategorized Issue
Severity:
Summary:
2. 69.8.2.8 The simple Element, page 69-538
Simple Extensions and Changes
a) Enumerations - Add an optional enumerations element to the simple
definition.
This allows a simple enumeration property to be defined. Each enumeration
label
has an associated value. The values are all of the same simple type.
Change simple element to:
<!ELEMENT simple
( description?
, value
, choices?
, enumerations?
, defaultvalue?
) >
Define new enumerations element
<!ELEMENT enumerations
( enumeration+
)>
<!ELEMENT enumeration EMPTY>
<!ATTLIST enumeration
label CDATA #REQUIRED
value CDATA #IMPLIED>
b) Short appears twice in the simple type attribute definition. Remove
second
occurrence.
<!ELEMENT simple
( description?
, value
, choices?
, defaultvalue?
) >
<!ATTLIST simple
name CDATA #IMPLIED
type ( boolean
| char
| double
| float
| short -- 1st occurrence
| long
| objref
| octet
| short -- 2nd occurrence
| string
| ulong
| ushort
) #REQUIRED >
c) Units - add an optional units element to indicate the units of
measurement for
a simple property.
<!ELEMENT simple
( description?
, value
, choices?
, units?
, defaultvalue?
) >
<!ELEMENT units (#PCDATA)>
d) Property Kind - The properties file for a component should not be
restricted to
only initial configuration properties. A component has many different types
of
properties and when defining a component one should be able to define these
types of properties in a generic way. Add a kind element or attribute for a
property definition. A component has readonly, writeonly, and readwrite
properties. Simple properties can also be used for a component factory's
create
options parameter (home) or executable parameters/arguments. Only simple
properties can be used for executable parameters.
New simplekind element
<!ELEMENT simplekind EMPTY>
<!ATTLIST simplekind
kindtype (configure_writeonly | configure_readwrite | execparam |
query_readonly | factoryparam) "configure_readwrite">
Change simple definition to:
<!ELEMENT simple
( description?
, value
, choices?
, simplekind*
, defaultvalue?
) >
The propertykind can be an optional element or attribute for the stuct and
sequence elements.
New propertykind element
<!ELEMENT propertykind EMPTY>
<!ATTLIST propertykind
kindtype (configure_writeonly | configure_readwrite |
query_readonly | factoryparam) "configure">
Change Struct and Sequence to
<!ELEMENT struct
( description?
, ( simple
| sequence
| struct
| valuetype
)*
, propertykind?
) >
<!ATTLIST struct
name CDATA #IMPLIED
type CDATA #REQUIRED >
<!ELEMENT sequence
( description?
, ( simple*
| struct*
| sequence*
| valuetype*
)
, propertykind?
) >
<!ATTLIST sequence
name CDATA #IMPLIED
type CDATA #REQUIRED >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
Range Element - why is the min and max order not specified? <!ELEMENT range (value, value) > I understand the software logic can do a compare to determine the min and max values, but it seems the following definition would be easier to understand from human reader. Change Range to <!ELEMENT range EMPTY> <!ATTLIST range min CDATA #REQUIRED max CDATA #REQUIRED>
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
Choices Element - It appears multiple ranges do not make sense for a simple
definition. If so, then remove the range element from the choices element
definition
and make range an optional element for a simple.
Current definition
<!ELEMENT choices ( choice | range )+
Change to
<!ELEMENT choices ( choice )+
<!ELEMENT simple
( description?
, value
, choices?
, range?
, defaultvalue?
) >
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
Simple Sequence -The current definitions for sequence allow invalid
definitions to be
built but be syntactically correct. A better definition for a simple
sequence would be as
follows:
Current sequence element
<!ELEMENT sequence
( description?
, ( simple*
| struct*
| sequence*
| valuetype*
)
) >
<!ATTLIST sequence
name CDATA #IMPLIED
type CDATA #REQUIRED >
Change to
Add a new simplesequence element:
<!ELEMENT simplesequence
( description?,
, values?
, choices?
, range?
, enumerations?
, units?
)>
<!ATTLIST simplesequence
name CDATA #IMPLIED
type ( boolean | char | double | float | short | long | objref |
octet | string | ulong
| ushort ) #REQUIRED
<!ELEMENT values
( value+
)>
Change sequence to:
<!ELEMENT sequence
( description?
, ( simplesequence
| struct*
| sequence*
| valuetype*
)
) >
<!ATTLIST sequence
name CDATA #IMPLIED
type CDATA #REQUIRED >
One does not have to keep repeating the same simple definition. This
definition
then has the added advantage where simple name attribute can now be made
mandatory.
<!ELEMENT simple
( description?
, value
, choices?
, defaultvalue?
) >
<!ATTLIST simple
name CDATA #REQUIRED
type ( boolean
| char
| double
| float
| short
| long
| objref
| octet
| string
| ulong
| ushort
) #REQUIRED >
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
This allows one to define test properties for a component in a generic way. The Test property is based upon simple element. Add new test element <!ELEMENT test ( description , inputvalue? , resultvalue )> <!ATTLIST test name CDATA #REQUIRED> <!ELEMENT inputvalue ( simple+ )> <!ELEMENT resultvalue ( simple+ )> Change properties element to: <!ELEMENT properties ( description? , ( simple | sequence | struct | test | valuetype )+ ) >
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
7. Component Artifact - Add the capability to define a component artifact
property. For
example, a logical device component artifact could be used to specify the
capacity for
a device or the characteristic of a device. The artifacts for a component
are referenced
by a component's implementation dependency for using or deployed on
relationships.
The component artifact property could be defined in two ways: 1) a new
element
called artifact or modifying the simple definition with optional new
artifact element.
Artifacts are simple types. The action element defines the action that can
be
performed on an artifact. When a dependency references an artifact with a
specified value this is the action that can be performed against a
component's
artifact. The ID is a DCE UUID to guarantee uniqueness of the artifact
within the
system; so 2 different artifacts, which are different, are not viewed to be
the same
artifact when they are not. The action denoted as external indicates the
artifact is
managed by the component. A referenced value for an artifact would have to
be
applied against the component.
Example 1 of New Artifact Element
<!ELEMENT artifact
( description?
, simple
, action
)>
<!ATTLIST artifact
id ID #REQUIRED>
<!ELEMENT action EMPTY>
<!ATTLIST action
type ( eq | ne | gt | lt | ge | le | external ) "external">
Change properties element to
<!ELEMENT properties
( description?
, ( simple
| sequence
| struct
| artifact
| valuetype
)+
) >
Example 2 of Modified Simple Element with new Artifact element
<!ELEMENT simplekind EMPTY>
<!ATTLIST simplekind
kindtype (configure_writeonly | configure_readwrite | execparam |
query_readonly | factoryparam | artifact) "configure_readwrite">
<!ELEMENT simple
( description?
, value
, choices?
, simplekind*
, artifact?
, defaultvalue?
) >
<!ELEMENT artifact
( action
)>
<!ATTLIST artifact
id ID #REQUIRED
action ( eq | ne | gt | lt | ge | le | external ) "external">
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
69.3.2.1 The softpkg Root Element, page 69-473
Softpkg Element Cardinality. Why does it make sense to have an empty
softpkg
file or to allow multiple elements such as title, pkgtype, description,
license, or to
have no implementations? Suggested changes are to place the correct
cardinality
on the softpkg elements to be similar to the CORBA Component and Component
Assembly Descriptor definitions. The suggested elements cardinality changes
will
make parsing the XML much simpler and reduce code footprint, and the XML
more understandable.
Current Format
<!ELEMENT softpkg
( title
| pkgtype
| author
| description
| license
| idl
| propertyfile
| dependency
| descriptor
| implementation
| extension
)* >
<!ATTLIST softpkg
name ID #REQUIRED
version CDATA #OPTIONAL >
Suggested New Format for Softpkg
- Zero or one title ? for example, a book only has one title, not
multiple titles.
- One or more authors ? for example, a book can have multiple authors,
but at
least one.
- Zero or one description, the CAD and CORBA Components DTDs define the
description this way.
- Zero or one package type.
- Zero or one property file reference. Why are multiple property files
needed?
- One or more implementations, since the softpkg is an implementation
for a
component definition then it must have at least one implementation.
- Zero or more dependencies for all implementations.
- Zero or more descriptors for all implementations. An implementation
may
contain multiple different components.
- Zero or more IDL files for all implementations.
- Zero or more extensions.
<!ELEMENT softpkg
( title?
, author+
, description?
, propertyfile?
, license?
, pkgtype?
, implementation+
, ( idl
| dependency
| descriptor
| extension
)*
)>
<!ATTLIST softpkg
name ID #REQUIRED
version CDATA #IMPLIED >
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
Implementation Element Cardinality. Why does it make sense to have an empty
implementation or to allow multiple elements such as code, description,
humanlanguage, or to have no code? Suggested changes are to place the
correct
cardinality on the implementation elements. The suggested elements
cardinality
changes will make parsing the XML much simpler and reduce code footprint,
and the
XML more understandable.
Current Format
<!ELEMENT implementation
( description
| code
| compiler
| dependency
| descriptor
| extension
| programminglanguage
| humanlanguage
| os
| propertyfile
| processor
| runtime
)* >
<!ATTLIST implementation
id ID #IMPLIED
variation CDATA #IMPLIED >
Suggested New Format for implementation
- Zero or one description, the CAD and CORBA Components DTDs define the
description this way.
- Zero or one property file reference. Why are multiple property files
needed?
- One code element is required for a given implementation
- Zero or one complier element. A given source code element is compiled
by a
specific compiler. Specifying the compiler is optional.
- Zero or one programminglanguage element. Specifying the
programminglanguage is optional.
- Zero or one humanlanguage element. Specifying the humanlanguage is
optional.
- Zero or more dependencies for a specific implementation.
- Zero or more descriptors for a specific implementation. An
implementation
may contain multiple different components.
- Zero or more runtimes. A given code element may be compatible with
multiple runtime environments.
- Zero or more os. A given code element may be compatible with multiple
operating systems.
- Zero or more processors. A given code element may be compatible with
multiple processors.
- Zero or more extensions.
<!ELEMENT implementation
( description?
, code
, compiler?
, humanlanguage?
, programminglanguage?
, propertyfile?
, ( dependency
| descriptor
| extension
| os
| processor
| runtime
| usescomponent
)*
)>
<!ATTLIST implementation
id ID #IMPLIED
variation CDATA #IMPLIED >
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
a) Add the optional stacksize and priority elements to code element definition. The stack size and priority are options parameters for an operating system's execute() operation. The stack size is the memory space needed by the executable and the OS priority for the executable. Data types for the values of these options are unsigned long. Priority number should be based upon industry standard such as POSIX. Current Format <!ELEMENT code ( ( codebase | fileinarchive | link ) , entrypoint? , usage? ) > <!ATTLIST code type CDATA #IMPLIED > New Format for code <!ELEMENT code ( ( codebase | fileinarchive | link ) , entrypoint? , stacksize? , priority? , usage? ) > <!ATTLIST code type CDATA #IMPLIED > <!ELEMENT stacksize (#PCDATA)> <!ELEMENT priority (#PCDATA)> b) Other valid values for type attribute Additional valid values for the type attribute are: "KernelModule", "SharedLibrary", and "Driver".
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
Add license element to implementation element. Why is the license element restricted to the softpkg level only? This is saying all implementations have the same license. Cannot each implementation have its own different license? Suggest adding license element to implementation element. Current Format <!ELEMENT implementation ( description | code | compiler | dependency | descriptor | extension | programminglanguage | humanlanguage | os | propertyfile | processor | runtime )* > <!ATTLIST implementation id ID #IMPLIED variation CDATA #IMPLIED > New Format <!ELEMENT implementation ( description | code | compiler | dependency | descriptor | extension | license | programminglanguage | humanlanguage | os | propertyfile | processor | runtime )* > <!ATTLIST implementation id ID #IMPLIED variation CDATA #IMPLIED >
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
Propertyfile clarification is needed for consistent behavior. The only statement made about propertyfile is that the implementation's propertyfile has precedence over the same propertyfile types at the softpkg level. Why are multiple property files needed at the softpkg and implementation levels? If more than one propertfile exist at any level, which property file has precedence in the list? If multiple property files exists are they merged together? Are the softpkg's descriptor element property files merge with the softpkg property files and which one has precedence? Are the implementation's descriptor property files merge with the implementation property files, and which one has precedence? Are implementation property files merge with the softpkg property files?
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
a) Add idl element to implementation element. Why is idl only at the softpkg level? This is saying that all implementations use the same IDL. This is inconsistent with descriptor element. An implementation can specify a descriptor, why not idl? Cannot an implementation use a specific IDL for its implementation? b) Why is IDL defined in the software package descriptor instead of the CORBA Component descriptor?
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
How does the Assembly Descriptor support multiple components within an implementation?
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
Change the format of author to group related authors together from a
company. One
does not need the capability to list multiple companies and web sites
together in the
author element, since there can be many authors listed in the softpkg
element. The
suggested elements cardinality changes will make parsing the XML much
simpler
and reduce code footprint, and the XML more understandable.
Current format
<!ELEMENT author
( name
| company
| webpage
)* >
New format
<!ELEMENT author
( name*
, company?
, webpage?
)>
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
An implementation may request a dependency on a specific component based upon its artifacts. Add artifactdependency to the dependency element. Current Format <!ELEMENT dependency ( softpkgref | codebase | fileinarchive | localfile | name | valuetypefactory ) > <!ATTLIST dependency type CDATA #IMPLIED action (assert | install)"assert"> New Format <!ELEMENT dependency ( softpkgref | codebase | fileinarchive | localfile | name | valuetypefactory ) , artifactdependency* > <!ATTLIST dependency type CDATA #IMPLIED action (assert | install)"assert"> <!ELEMENT artifactdependency EMPTY> <!ATTLIST artifactdependency artifactrefid CDATA #REQUIRED artifactvalue CDATA #REQUIRED> Note: This concept is tied to the concept of component artifact property issue. The artifactrefid is a reference to a component's artifact property defined in a component's property file. The artifactvalue is the dependency value being requested or needed.
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
A component's implementation may have additional dependencies on a device's
artifacts (e.g., capacity and/or characteristics) to ensure the right type
of device is
chosen for deployment and/or the device has sufficient capacities for
deployment. To
allow for this capability add a deviceartifactdependency element to the
implementation element.
Current Format
<!ELEMENT implementation
( description
| code
| compiler
| dependency
| descriptor
| extension
| programminglanguage
| humanlanguage
| os
| propertyfile
| processor
| runtime
)* >
<!ATTLIST implementation
id ID #IMPLIED
variation CDATA #IMPLIED >
New Format
<!ELEMENT implementation
( description
| code
| compiler
| dependency
| descriptor
| extension
| programminglanguage
| humanlanguage
| os
| propertyfile
| processor
| runtime
| deviceartifactdependency
)* >
<!ATTLIST implementation
id ID #IMPLIED
variation CDATA #IMPLIED >
<!ELEMENT deviceartifactdependency EMPTY>
<!ATTLIST deviceartifactdependency
artifactrefid CDATA #REQUIRED
artifactvalue CDATA #REQUIRED>
Note: This concept is tied to the concept of component artifact property
issue. The
artifactrefid is a reference to a component's artifact property defined in
a
component's property file. The artifactvalue is the dependency value being
requested or needed.
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
The softpkg element only deals with deployed on and library load dependency
relationships for implementations. Component implementations may also have
specific using relationships with another component, such as a device
within the
system. This relationship can be stated at the softpkg or implementation
level.
Current Format
<!ELEMENT softpkg
( title
| pkgtype
| author
| description
| license
| idl
| propertyfile
| dependency
| descriptor
| implementation
| extension
)* >
<!ATTLIST softpkg
name ID #REQUIRED
version CDATA #IMPLIED >
<!ELEMENT implementation
( description
| code
| compiler
| dependency
| descriptor
| extension
| programminglanguage
| humanlanguage
| os
| propertyfile
| processor
| runtime
)* >
<!ATTLIST implementation
id ID #IMPLIED
variation CDATA #IMPLIED >
New Format
<!ELEMENT softpkg
( title
| pkgtype
| author
| description
| license
| idl
| propertyfile
| dependency
| descriptor
| implementation
| extension
| usescomponent
)* >
<!ATTLIST softpkg
name ID #REQUIRED
version CDATA #IMPLIED >
<!ELEMENT implementation
( description
| code
| compiler
| dependency
| descriptor
| extension
| programminglanguage
| humanlanguage
| os
| propertyfile
| processor
| runtime
| usescomponent
)* >
<!ATTLIST implementation
id ID #IMPLIED
variation CDATA #IMPLIED >
<!ELEMENT usescomponent
( artifactdependency+
)>
<!ATTLIST usescomponent
id ID #REQUIRED
type CDATA #REQUIRED>
<!ELEMENT artifactdependency EMPTY>
<!ATTLIST artifactdependency
artifactrefid CDATA #REQUIRED
artifactvalue CDATA #REQUIRED>
Note: This concept is tied to the concept of component artifact property
issue. The
artifactrefid is a reference to a component's artifact property defined in
a
component's property file. The artifactvalue is the dependency value being
requested or needed.
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
Suggested changes to the AssemblyFactory interface.
AssemblyFactory Issues.
1. Ease of use Issue. After the create operation is performed, one is
force to call lookup to get the Assembly that just got just created. Why is
a cookie returned by the create operation instead of an Assembly? Is the
reason because of security? If the interface were more open this would
still allow a secure implementation to be implemented.
Suggested change is to return an Assembly instead of a Cookie. Change
destroy operation to take in an Assembly parameter instead of Cookie.
Change lookup operation to take in a name parameter. These changes
make it consistent with the other CCM interfaces, such as Container,
KeyLessCCMHome, ComponentServer, and ServerActivator.
2. Multiple users Issue. For multiple users, how does a client know what
assemblies are created. Add a get_assemblies operation that returns a list
of assemblies. These changes make it consistent with other CCM interfaces,
such as Container, ComponentServer, and ServerActivator.
3. User-friendly identifier for Assembly Instance issue. Add an input
name parameter that can be assigned to the Assembly instance that gets
created. Add a read only name or label attribute to the Assembly interface.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
In formal/02-06-65, page 6-54, there is the following text
Placeholder for future version.
The section 6.7.2.33 would be written.
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
In ptc/01-11-03, page 69-533, there is the following note
Issue The trader elements have to be reviewed to make
sure that they serve the purpose intended.
Also, consider using a property file.
XML DTD elements related to the trader service would be checked
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
In ptc/01-11-03, page 69-545, there is the following note Issue The Configurator interface takes an argument of type CCMObject and therefore cannot be used to configure component homes. I see no reason not to widen the type to CORBA::Object so that the Configurator can be used for objects other than CCMObjects. The StandardConfigurator is after all a basic name value pair configurator that simply executes calls on mutator operations resulting from attribute declarations. J.S.E. The Configurator interface could be updated to allow configuration of any CORBA objects.
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
in the BaseIDL there is a class StructDef which has the Attribute members of Type Field. How can I model a IDL struct with more than one entry? I think there should be a aggregation from StructDef (1<>----->*) to the Field class (Page 8-10 of the CCM Spec). *) With EnumDef there is the same problem, I guess a assotiation from EnumDef to string (1<>----->*) would solve it (Page 8-10 of the CCM Spec). *) Also with ExceptionDif and its attribute members (Page 8-11 of the CCM Spec).
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
Document ptc/2001-11-03, CORBA Component Model
----------------------------------------------
62.4.1.1 The CCM2Context Interface
....
local interface CCM2Context : CCMContext
{
HomeRegistration get_home_registration ();
void req_passivate () raises (PolicyMismatch);
CatalogBase get_persistence (in _TypeId catalog_type_id)
raises (PersistenceNotAvailable);
};
....
req_passivate
The req_passivate operation is used by the component to inform the container
that it wishes to be passivated when its current operation completes. To be
valid, the component must have a servant lifetime policy of component or
container. If not, the PolicyMismatch exception shall be raised.
----------------------------------------------
What happens if req_passivate() operation is not called in the scope of a
callback operation?
I think that req_passivate() can only make sense if called in the context of
a callback operation. The IllegalState exception is appropriate for this
case.
The IDL might then look like this :
void req_passivate () raises (IllegalState,PolicyMismatch);
and the following sentence might be appended to the paragraph above:
"If this operation is issued outside of the scope of a callback operation,
the IllegalState exception is returned."
This addition will ease implementation of CCM2Context objects based on
POACurrent : implementing container and component servant lifetime policies
on a POA with RETAIN servant retention policy and the other servant lifetime
policies on a POA with NON_RETAIN servant retention policy can rely entirely
on the POACurrent.
Proposed resolution:
In the Adopted CORBA Components Specification (formal/02-06-65),
section 6.7.2.15, page 6-50, replace 'consumingcomponent' by
'consumesport'.
Proposed revised text:
In formal/02-06-65 page 6-50, replace
A child of consumingcomponent
by
A child of consumesport
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."
Document formal/02-06-05 on page 1-49 states the following:
"The implementation of a component type's home object may optionally support the
HomeConfiguration interface. The HomeConfiguration interface is derived from
Components::CCMHome. In general, the HomeConfiguration interface is
intended for use by an agent deploying a component implementation into a container,
or an agent deploying an assembly."
The first statement does not offer a clear interpretation when considering the language mapping for homes. If the implementation of a component type's home optionally supports HomeConfigurator how is this information defined in IDL? Should the component type's home definition support HomeConfiguration? This would seem to be the proper interpretation but that leads to problems in the language mapping of the defined home. In section 3.3.3.6 on page 3-45
Home Explicit Executor Interface
The home explicit executor callback interface is defined by the following rules:
1. For each home <home name>, a local explicit executor interface with the same
name as the home, but with a prefix of "CCM_" and a postfix of "Explicit" is
defined.
2. The explicit executor interface contains all attributes and operations declared by the
home.
3. If the home has a base with a name of <base name>, the explicit executor
interface inherits CCM_<base name>Explicit. If the home does not have a base,
the explicit executor interface inherits Components::HomeExecutorBase.
4. If the home has supported interfaces, they are inherited by the explicit executor
interface.
5. Additional operations are added to the explicit executor interface for factories and
finders, see below.
Item 4 would imply that the home explicit executor must include operations defined in both HomeConfigurator and CCMHome since HomeConfigurator extends CCMHome. This is clearly not the intended behavior of the home explicit executor since it specifically excludes any direct inheritance of CCMHome.
Resolution
The inheritance of CCMHome by HomeConfiguration should be removed since it is implied that every home will extend CCMHome and home definitions in IDL would then be able to explicitly support HomeConfiguration without the extra baggage of the CCMHome interface. Furthermore, the language mapping does not properly handle a component home that supports HomeConfiguration (if it extends CCMHome) since the component executor would include all CCMHome operations. The language mapping would work fine if HomeConfiguration did not extend CCMHome.
Replace text in formal/02-06-05 on page 1-49
The implementation of a component type's home object may optionally support the
HomeConfiguration interface. The HomeConfiguration interface is derived from
Components::CCMHome. In general, the HomeConfiguration interface is
intended for use by an agent deploying a component implementation into a container,
or an agent deploying an assembly.
with
The implementation of a component type's home object may optionally support the
HomeConfiguration interface. In general, the HomeConfiguration interface is
intended for use by an agent deploying a component implementation into a container,
or an agent deploying an assembly.
Replace IDL in formal/02-06-05 on page 1-49
module Components {
interface HomeConfiguration : CCMHome {
void set_configurator (in Configurator cfg);
void set_configuration_values (
in ConfigValues config);
void complete_component_configuration (in boolean b);
void disable_home_configuration();
};
};
with
module Components {
interface HomeConfiguration {
void set_configurator (in Configurator cfg);
void set_configuration_values (
in ConfigValues config);
void complete_component_configuration (in boolean b);
void disable_home_configuration();
};
};I propose to introduce generic operations that allow
interconnecting ports regardless of their type. This
would ease generic programming.
The first part of the proposal is to allow generic
usage of the "connect" and "disconnect" operations
that are (currently) in the Receptacles interface,
i.e. to extend the functionality to not only work
on receptacles, but also on event source ports
(emits and publishes keywords).
The names "connect" and "disconnect" are appropriate
for any kind of port, and their signatures are the
same as "subscribe" and "unsubscribe" in the Events
interface.
The second part of the proposal is to introduce a
new operation "get_port" into the CCMObject interface.
This operation would take a FeatureName parameter and
return the object reference associated with that
facet or event sink.
So I propose the following steps:
1.) Allow connect, disconnect and get_connections to
operate on event source ports, and introduce a
get_port operation.
This change would be backwards compatible.
2.) Move connect, disconnect and get_connections from
the now inappropriate Receptacles interface into
the CCMObject interface. This step might cause
minor, easily fixable breakage for software that
widens an object reference to Receptacles instead
of CCMObject. (I don't think any such software
exists, it's more of a theoretical issue.)
3.) Discourage, then remove the "subscribe" and
"unsubscribe" operations in the Events interface.
They don't offer any more type safety than connect
and disconnect.
I believe that these changes would also be of interest
for slimming down CCM for the Lightweight CCM RFP, and
in light of the Streams for CCM RFP (which will likely
add another port type that needs interconnecting).
This change does not have any impact on component
implementations. The change to CCM implementations
(ORBs) is neglegible (I would expect a day to make
these changes in MicoCCM, another day to test them).
If there is general agreement on this issue, I will
draft the text updates.
* document : formal/02-06-65
* chapter : 1.5.2.4
* text in question :
module Components
{
valuetype Cookie
{
private CORBA::OctetSeq cookieValue;
};
};
* Issues :
1. Naming style used in this definition violates rules defined in
"OMG IDL Style Guide" (ab/98-06-03).
2. Naming style used in this definition is inconsistent with other parts
of the CCM IDL, for example:
module Components
{
valuetype PortDescription
{
public FeatureName name;
public CORBA::RepositoryId type_id;
};
valuetype FacetDescription : PortDescription
{
public Object facet_ref;
};
}
* suggested resolution : replace `cookieValue' with `cookie_value'
In section 4.2.5 of the CCM spec formal/02-06-65, it is said that "Servant lifetime policies may be defined for each segment within a component", but there is no way to do it. Lifetime policy is declared in the CCD descriptor of the component, as an attribute of the "servant" XML element, and is implicitly applied on all the segments of the component(when it is segmented) !
Suggested resolution: to leave the servant element as it is, expressing a DEFAULT lifetime policy, and to add the same servant element as an optional child of the segment element. This will specify the lifetime policy of the segment and override the defautl one. DTD has to be changed as follows :
<!ELEMENT segment
( segmentmember+
, containermanagedpersistence?
, extension*
>
<!ATTLIST segment
name CDATA #REQUIRED
segmenttag CDATA #REQUIRED >
becomes:
<!ELEMENT segment
( segmentmember+
, servant?
, containermanagedpersistence?
, extension*
>
<!ATTLIST segment
name CDATA #REQUIRED
segmenttag CDATA #REQUIRED >
Need to reflect the change in the PSS specification, in which the catalog is not user-defined anymore. The example and the cidl syntax (chapter 2) need to be changed too.
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.
1. Section 6.4.5.52 (page 6-38): It says the the "storagehome" element is a child element of "segment" where it should really say it is a child element of "containermanagedpersistence" instead.
Section 6.4.5.10 (page 6-26): one of the child elements of the "containermanagedpersistence" element is "psstransactionpolicy" where it should have been "psstransaction" instead (see Section 6.4.5.40 on page 6-34 and Section 7.2 on page 7-6 and 7-7).
To maintain a consistent style and to provide a detailed description in an XML element's first appearance, Section 6.4.5.26 and Section 6.4.5.30 should be moved under Section 6.3 and changed to referring them back to the corresponding subsections like Section 6.4.5.29 does.
The Session2Context interface allows developers to create an object reference from an octet sequence (object id). The the Entity2Context allows developers to create an object reference from a ComponentId. Neither the Session2Context nor the the Entity2Context allows the developer to infer the octet sequence or ComponentId that is associated with an operation invocation on a component. In other words, a developer may use a context to create multiple references that are subsequently invoked by a client. When the client invokes an operation on the reference the component code will be required to satisfy the operation invocation (either through the monolithic or the locator language mapping strategy). There is no information, however, as to which of the created references is being invoked by a client. To resolve the ambiguity the component developer must be able to use the context to provide the current octet sequence or ComponentId corresponding to the reference that is currently being invoked.
Resolution:
Replace the following text in formal/02-06-05 on page 4-37
local interface Session2Context : SessionContext, CCM2Context {
Object create_ref (in CORBA::RepositoryId repid);
Object create_ref_from_oid (
in PortableServer::ObjectIdCORBA::OctetSeq oid,
in CORBA::RepositoryId repid);
PortableServer::ObjectId
CORBA::OctetSeq get_oid_from_ref (in Object objref)
raises (IllegalState, BadComponentReference);
};
with
local interface Session2Context : SessionContext, CCM2Context {
Object create_ref (in CORBA::RepositoryId repid);
Object create_ref_from_oid (
in PortableServer::ObjectIdCORBA::OctetSeq oid,
in CORBA::RepositoryId repid);
PortableServer::ObjectId
CORBA::OctetSeq get_oid_from_ref (in Object objref)
raises (IllegalState, BadComponentReference);
CORBA::OctetSeq get_current_oid ()
raises (IllegalState);
};
and add the operation description
get_current_oid
The get_current_oid operation is used by the component to extract the oid
associated with the current operation invocation. This operation must be called
within an operation invocation. If not, the IllegalState exception shall be raised.
Also, replace the following text in formal/02-06-05 on page 4-44
local interface Entity2Context : EntityContext, CCM2Context {
ComponentId get_component_id ()
raises (IllegalState);
ComponentId create_component_id (
in FacetId target_facet,
in SegmentId target_segment,
in SegmentDescrSeq seq_descrs);
ComponentId create_monolithic_component_id (
in FacetId target_facet,
in StateIdValue sid);
Object create_ref_from_cid (
in CORBA::RepositoryId repid,
in ComponentId cid);
ComponentId get_cid_from_ref (
in Object objref) raises (BadComponentReference);
};
with
local interface Entity2Context : EntityContext, CCM2Context {
ComponentId get_component_id ()
raises (IllegalState);
ComponentId create_component_id (
in FacetId target_facet,
in SegmentId target_segment,
in SegmentDescrSeq seq_descrs);
ComponentId create_monolithic_component_id (
in FacetId target_facet,
in StateIdValue sid);
Object create_ref_from_cid (
in CORBA::RepositoryId repid,
in ComponentId cid);
ComponentId get_cid_from_ref (
in Object objref)
raises (BadComponentReference);
ComponentId get_current_cid ()
raises (IllegalState);
};
and add the operation description
get_current_cid
The get_current_cid operation is used by a persistent component to retrieve the
ComponentId associated with the current operation invocation. This operation must be called
within an operation invocation. If not, the IllegalState exception shall be raised.The following information is sent in order for the specification to
clearly state if components and local interfaces can support abstract
interfaces (the specification is confusing on this point).
CORBA 3.0.1 does not explicitely states if a component can support an
abstract interface, thus it can be considered that it is possible. If so
a big problem arises as local interfaces inheriting abstract ones is
confusing in the specification.
In addition, it is neither explicitely stated that provides and uses
declarations can or cannot be of types defined through abstract
interfaces. It does not seem to make sense for a port to be an abstract
type. Facets will never be used by value, and an operation cannot
(should not) return the reference of a facet or a valuetype (which would
be in favor of provides to be defined using abstract interfaces).
** Problem
Consider the following definitions which are correct regarding
formal/02-12-06:
/* omg idl3 */
abstract interface I { void foo () ; } ;
component C supports I {
} ;
The mapping to OMG IDL2 of these definitions is not correct right now as
they become:
/* omg idl2 */
abstract interface I { void foo () ; } ;
interface C : Components::CCMObject, I { } ;
local interface CCM_C : I { } ;
According to formal/02-12-06, the last line may not be correct. Local
interfaces may not inherit abstract interfaces (section 10.5.28). (I use
may as it is confusing and can lead to various understanding of the
spec.)
** Potential solutions:
1. State in the CORBA 3.0.1 that components cannot support abstract
interfaces. In favor: Could ne considered as a minor change. Against: a
component reference cannot be returned by an operation that can return
an object by value or by reference. This solution looks cleaner that the
second one from a software engineering point of view.
2. Clearly state that components and local interfaces can support
abstract interfaces. This use may be surprising from a software
engineering point of view, but may be important for some users. This
bring back the debate "quality vs powerfulness".
In any case, I think it should be clearly stated if local interfaces may
or may not inherit abstract ones.
In section 1.1.2 of the CCM specification: 1.1.2 Ports =========== ..... The component model supports four basic kinds of ports: - Facets - Receptacles - Event sources - Event sinks - Attributes Well, that list includes five things, not four. So, is an attribute considered a port or not? The wording in this section needs to be clarified in the CCM specification, because it is not clear if an attribute is a port or not.
The home interface could have freely defined operations or can support an interface with such operations. A home context interface may help to implement such operations. E.g. a home implementation needs this context interface to determine its own object reference. suggestion: Add a home context interface that is similar to the component context interface. Add a set_context operation at the HomeExecutorBase interface.
@@ It seems to me that generating 'local executor mapping' for supported
by a component interfaces is not needed. Even though spec doesn't say
directly that it's needed or not there are plenty of examples where it is
shown generated.
@@ According to the spec the following IDL is valid
interface I;
component C
{
provides I i;
};
while this is not:
interface I;
component C
{
uses I i;
};
Any reason for that?
@@ According to the spec Home cannot be forward-declared. Any reason
for that?
@@ The following CIDL is legal according to the spec:
interface I;
component C
{
provides I i;
};
home H manages C
{
};
composition session Impl
{
home executor H_Exec
{
implements H;
manages C_Exec;
};
};
However there is no way to generate valid local executor mapping for this
CIDL. The resolution would be to require all forward-declared interfaces
used by component's provides declarations to be defined before composition
for this component is seen. I.e. the following CIDL would be a corrected
version:
interface I;
component C
{
provides I i;
};
home H manages C
{
};
interface I {};
composition session Impl
{
home executor H_Exec
{
implements H;
manages C_Exec;
};
};
@@ The following legal according to the spec IDL:
module M
{
module Components
{
struct EnterpriseComponent {};
};
component C {};
};
would result in local executor mapping that looks something like this:
module M
{
module Components
{
struct EnterpriseComponent {};
};
component C {};
};
module M
{
local interface C : Components::EnterpriseComponent {};
};
which is illegal IDL. The resolution would be to require names like
Components::EnterpriseComponent to be fully qualified e.g.
::Components::EnterpriseComponent.
I found some minor editorial issues in the spec (referring to the document 02-06-65). - page 1-20 second bullet of the description of the disconnect operation. An 'and' is missing. This bullet should look like: "If the receptacle is a simplex receptacle and there is no current connection, then the NoConnection exception is raised."
page 1-20 the description of the get_connection operation refers to a ConnectionDescription struct. In fact it is a ConnectionDescription valuetype
-page 1-20 and page 1-21 the names of the operations get_all_receptacles get_named_receptacles are written with italic font. This seems to be a mistake.