The ComponentPackageReference element (6.4.8) allows to reference
an external package (to be resolved during planning by searching
repositories), for example to instantiate a subcomponent instance
from, in an assembly.

However, there is no type safety here; an assembly design tool has
no way of validating that the ports (which are referenced by
connections within the assembly) actually exist in the component
interface of the referenced component.

Actually, there is little point in ComponentPackageReference having
an optional "requiredType"; there should always be a mandatory type
that the referenced package must support.

To an assembly design tool, just having the "requiredType" repository
id is insufficient for validation, the full
ComponentInterfaceDescription
is necessary.

Proposed resolution:

In section 6.4.8.2, ComponentPackageReference Attributes, delete the
"requiredType" attribute.

Add a "requiredType" composition association to ComponentInterface-
Description, with multiplicity 1..1.

In section 6.4.8.3, ComponentPackageReference Constraints, delete the
constraints, and replace with "No constraints." (Rationale: when type
conformance is mandatory, the existing constraing will always be met.)

In section 6.4.8.4, ComponentPackageReference Semantics, replace the
existing text

The planner will search one or more repositories for package
configurations that satisfy all requirements.

with

The planner will search one or more repositories for package
configurations that support the requiredType, and that match the
requiredUUID and requiredName attributes, if present.

No Data Available

Commit and releaseResources based upon a deployment plan. This should be a
separate interface. For systems or domains implementations that need this
behavior a component could exist that provides this behavior. Not all
systems need to formally create a deployment plan (XML) to do deployment.

No Data Available

6.4.14 MonolithicImplementationDescription

This description should have additional well-defined optional attributes
such as entry point name, stack size, and process priority. Keep these
elements separate from execParameters. ExecParameters should be parameters
that are passed to the main process or entry point and used by the entry
point or main process implementation. These should be defined at the PIM
level.

No Data Available

2.3.3 ComponentPackageDescription
2.3.4 ComponentImplementationDescription
There should be a constraint stated for the configproperties? What should
they relate to?

No Data Available

3) page 91: In the sequence diagram, the time when is called the
commitRessources operation on the TargetManager instance is not clear for
me. It seems that the operation begins before the end of the
DomainApplication's activity period (call to "startLaunch").

No Data Available

Section 9.5.8, "Transformation Exceptions and Extensions" in the
"PSM for CCM to PSM for CCM for XML Transformation" chapter, contains
the text:

If the link attribute of a ComponentPackageDescription proxy that
is part of a SubcomponentInstantiationDescription element does not
contain a fragment identifier, then the referenced file can be
either a Component Package Descriptor or a package (i.e. a ZIP
file with the ".cpk" extension containing the package).

This was added for better modularity, to allow a package to "import"
another package, maybe from some external location. On second thought,
considering the implementation impact, this does not seem like such
a good idea, because it overloads an XMI proxy object with a second
meaning: either do what XMI says, or import a package.

It is also self-contradictory with the preceding sentence, which gives
clear semantics to linking to an XML document without a fragment
identifier.

I suggest to replace this with an explicit importing mechanism: add a
new class to the Component Data Model called "ComponentPackageImport",
and use it in the SubcomponentInstantiationDescription. This resolution
clarifies how to reuse packages.

Proposed resolution:

Add a new class "ComponentPackageImport" to the Component Data Model.

6.4.x ComponentPackageImport

6.4.x.1 Description

Imports a package via an URL.

6.4.x.2 Attributes

location: String [1..*]
Alternative locations of the package that is to be imported.

6.4.x.3 Associations

None.

6.4.x.4 Semantics

A ComponentPackageImport can be used instead of a
PackageConfiguration
to import a package, rather than providing the package "inline."

In 6.4.7.1 (SubcomponentInstantiationDescription description), replace
the
second paragraph,

The SubcomponentInstantiationDescription links to a package that
provides
implementations for the sub-component that is to be instantiatiated.
There
is either a link to a ComponentPackageDescription in case a package
recursively contains packages for its sub-components, or there is a
link
to a ComponentPackageReference that contains the requiredType of a
component
interface. Users of the Component Data Model will have to contact a
Repository (possibly via a search path) in order to find a package
that
implements this interface.

with

The SubcomponentInstantiationDescription specifies a package to
instantiate
a subcomponent from, and configures this subcomponent instance. The
package
can be provided in one of three ways:

• The package can be provided inline, as part of the same package,
  using a
  PackageConfiguration.
• A package can be imported, using a ComponentPackageImport. The
  imported
  package may be part of the enveloping package, or it may be
  referenced
  from an external location. This allows reusing packages.
• A package can be referenced indirectly, using a
  ComponentPackageReference.
  Users of the Component Data Model will have to contact a
  Repository
  (possibly via a search path) in order to find an appropriate
  package.

In 6.4.7.3 (SubcomponentInstantiationDescription associations), add

importedPackage: ComponentPackageImport [0..1]
Imports a package by reference.

In 6.4.7.4 (SubcomponentInstantiationDescription constraints), replace

There can be either a package or a reference, but not both.

with

A package to supply an implementation for this subcomponent is
either
included, imported, or referenced:

context SubcomponentInstantiationDescription inv:
Set

->size() =
1

In 6.5.1.5 (RepositoryManager semantics), add

The installPackage and createPackage operations recursively resolve
all
imported packages: in all SubcomponentInstantiationDescription
elements,
ComponentPackageImport elements are replaced with
PackageConfiguration
elements, containing the data that was loaded from the imported
package.
PackageConfiguration elements returned from findConfigurationByName
or
findConfigurationByUUID do not contain ComponentPackageImport
elements.

In 9.5.8 (Transformation Exceptions and Extensions), delete the second
sentence of the last paragraph, which reads

If the link attribute of a ComponentPackageDescription proxy that
is part of a SubcomponentInstantiationDescription element does not
contain a fragment identifier, then the referenced file can be
either a Component Package Descriptor or a package (i.e. a ZIP
file with the ".cpk" extension containing the package).

No Data Available

In 6.4.7, (SubcomponentInstantiationDescription), an assembly can point
to another package to provide an instance of a subcomponent, using the
"package" reference to ComponentPackageDescription.

The resolution to issue 6047 changed the main "work product", the
package,
to contain a PackageConfiguration as the toplevel item, rather than a
ComponentPackageDescription.

For consistency, I suggest that SubcomponentInstantiationDescription
reference PackageConfiguration, too.

Proposed resolution:

In 6.4.7.3 (associations for SubcomponentInstantiationDescription),
change

package: ComponentPackageDescription [0..1]
Describes a package that provides an implementation for this
subcomponent instance.

to

package: PackageConfiguration [0..1]
The package that provides an implementation for this
subcomponent instance.

No Data Available

see the following definition in the IDL generated from the Target Data
Model using UML Profile for CORBA, and have some issues with semantics when
interpreting the following generated IDL mapping from the model:

struct SharedResource

;

typedef sequence < SharedResource > SharedResources;

struct Resource

;

typedef sequence < Resource > Resources;

struct Node

;

struct Domain

;

The idea of the above IDL is to represent the following semantics:

A Domain is composed of Nodes (among other things). A Domain can also
contain a list of the resources that are shared among the different nodes
in the domain. There is also an association between the Nodes of the domain
and the SharedResources in a domain. Basically, the nodes of the domain
contain a list of the resources that they share with other nodes, and the
each shared resource keep track of the nodes that share it.

Please refer to Fig 6-4 Target Data Model Overview, in the document:

http://www.omg.org/cgi-bin/doc?ptc/2004-03-10

Ideally one should be able to represent this in IDL like this:

struct Node;

typedef Sequence<Node> Nodes;

struct SharedResource

;

except that this is invalid IDL. The alternative mapping that is generated
doesn't seem to make sense. What should I fill in as values for the
::CORBA::ULongSeq in struct SharedResource? Why did it get mapped to an
CORBA::ULongSeq? Is it intended that these unsigned longs will refer to the
gasp pointers of the actual nodes in my parsed DOM tree with Domain as
root? If so, it will not work with 64-bit machines. How is one supposed to
refer a IDL struct member i.e, node inside a Domain using unsigned long?
The only identifier that is unique among all nodes in a Domain is it's
name. But unsigned long just doesn't make sense to me.

The above illegal IDL definition which directly includes Nodes after just
forward declaring node would work if Node was mapped to a valuetype. But I
don't know if that is a feasible solution.

Any clarifications on this would be really helpful.

No Data Available

The resolution for issue #6026 added several definitions to chapter 5 ("Terms and Definitions"). The definitions 5.10, 5.13, and 5.23 refer directly or implicitely to the term "connection" (between components). However, this term is not defined in chapter 5 yet.

Proposed resolution:
Don't change current definitions but add an appropriate definition for connection.

No Data Available

Make the getAllResources and getAvailableResources a separate interface.
For systems or domains implementations that need this behavior a component
could exist that provides this behavior. Not all systems need to formally
create a domain. Some systems provide this information based upon their
components. The issue, if a domain is distributed that contains distributed
components that manage this information how does the domain map to these
elements?

No Data Available

The submission only gives one choice for managing node resources, which
is always done by the domain (target manager). There is no capability of
allowing a node/device to manage its resources and its states, and to
indicate which node resources can be managed at the domain and which ones
at the node or device level. Recommendation is add the capability in the
description elements to indicate if the resources are managed by the
node/device or by the domain, and operations to the node/device to manage
this capability

No Data Available

Suggestion is to break ComponentExternalPortEndpoint from
AssemblyConnectionDescription as a separate definition for the assembly
external port definitions

No Data Available

SubcomponentPortEndpoint, ComponentExternalPortEndpoint, and
ExternalReferneceEndpoint need to indicate the type of interface.
Rational: UML 2.0 defines ports that can be associated with many required
and provider interfaces

No Data Available

The "name" attribute of the Property class must be a URN, so to be consistent
we should rename the attribute global_name, and insist that it is a URN

No Data Available

The OLD CCM DTD and SCA had the concept of connection ID for a required
port. This was useful when a required port allowed multiple connections to
it with the same interface, so it could distinguish the connection being to
it. Add the flexibility in the Port definition of optional stating
connection ids for a required port and allow the component assembly
definition for a port connection to optional state a connection id to be
used. For a required port, instead of stating connection IDs, it could
optionally state the maximum number of connections per interface type for a
required port. When not stated it is assumed to be one.

No Data Available

For ExternalReferneceEndpoint add optional port name attribute to
indicate the port that is used to connect to or to retrieve an interface
from the ExternalReferenceEndpoint. Rationale for change is to allow for
components to be connected to ExternalReferenceEndpoint that are
components. An example is a SWRadio use case for an I/O device resident in
the SWRadio, where the I/O Device has required and provider ports.

No Data Available

For ExternalReferneceEndpoint add provider boolean attribute to
indicate the role of the ExternalReferenceEndpoint. Rationale for change
is to allow for components to be connected to ExternalReferenceEndpoint or
an ExternalReferenceEndpoint to be connected to an assembly component. An
example is a SWRadio use case for an I/O device resident in the SWRadio,
where the I/O Device has required and provider ports.

No Data Available

ExternalReferneceEndpoint, SubcomponentPortEndpoint,
ComponentExternalPortEndpoint needs to indicate the type of port/interface.
Rational: This allows the deployment machinery or planner not to process
all the components component descriptor files to determine the type of
port/interface.

Constraint Definition lacks the requirement of what constitutes a
valid connection. For a connection there must be at least one required
port/interface and at least one provider port/interface.

For ExternalReferneceEndpoint add a navigable association to
Requirement with multiplicity being "*". Rationale for change is to allow
for PSMs to qualify the requirements needed for an
ExternalReferenceEndpoint. An example is a SWRadio use cases for this are:
a. To be able to specify a service needed that the domain is aware of.
b. To be able specify a device that deployment machinery used for the
deployment of a component.
c. To be able to specify a service that was chosen by the deployment
machinery that was specified for a component deployment requirement.

The RepositoryManager has two operations to install packages in the
Repository: installPackage() and createPackage(). But while the latter
has a "replace" parameter, to decide whether an existing package (with
the same installationName) shall be replaced or not, the former doesn't.
I don't see why this difference should exist.

Proposed resolution:

In section 6.5.1.2 (RepositoryManager operations), add a third "replace"
parameter of boolean type to the installPackage operation. Thus, change

installPackage (installationName: String, location: String)
Installs a package in the repository, under the given installation
name. Raises the NameExists exception if a configuration by this
name already exists. Raises the PackageError exception if an
internal error is detected in the package.

to

installPackage (installationName: String, location: String, replace:
Boolean)
Installs a package in the repository, under the given installation
name. If the replace parameter is true, an existing
PackageConfiguration
with the same name is replaced. If the replace parameter is false,
and if
a package with the same name exists in the repository, the
NameExists
exception is raised. Raises the PackageError exception if an
internal
error is detected in the package.

No Data Available

Hi,

The Deployment & Configuration XML Schema defines a Property element like:

<xsd:complexType name="Property">
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element name="name" type="xsd:string" />
<xsd:element name="value" type="Deployment:Any" />
<xsd:element ref="xmi:Extension" />
</xsd:choice>
<xsd:attribute ref="xmi:id" use="optional" />
<xsd:attributeGroup ref="xmi:ObjectAttribs" />
</xsd:complexType>
<xsd:element name="Property" type="Deployment:Property" />

This allows for the following invalid Property file to be passed silently
by the XML Schema validator:

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<Deployment:Property
xmlns:Deployment="http://www.omg.org/Deployment"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.omg.org/Deployment Deployment.xsd">
<name>ORBSvcConf</name>
<value>
<type>
<kind>tk_string</kind>
</type>
<value>
<string>Foo</string>
</value>
</value>
<value>
<type>
<kind>tk_short</kind>
</type>
<value>
<long>123</long>
</value>
</value>
</Deployment:Property>

The model in 6.10.8 has a containment association with a cardinality one
for value. The schema generated from that model doesn't match the semantics
in the model. This is just an example. There are a lot of elements where
the semantics imposed by the schema are different from what is described in
the model. I am curious as to why this is allowed. It can be easily fixed
by changing the schema to:

<xsd:complexType name="Property">
<xsd:sequence minOccurs="0" maxOccurs="1">
<xsd:element name="name" type="xsd:string" />
<xsd:element name="value" type="Deployment:Any" />
<xsd:element ref="xmi:Extension" minOccurs="0" />
</xsd:sequence>
<xsd:attribute ref="xmi:id" use="optional" />
<xsd:attributeGroup ref="xmi:ObjectAttribs" />
</xsd:complexType>
<xsd:element name="Property" type="Deployment:Property" />

ComponentExternalPortEndpoint definition is not unique enough. A
component can have the same port name. This definition needs to be
qualified by a component as done for SubcomponentPortEndpoint.

No Data Available

For a port definition allow the capability to optional supply port
characteristic and capability properties.

The diagram for the SubcomponentInstantiationDescription shows
a composition relationship to Requirement called selectRequirement
that is not mentioned in the class' Associations section.

Proposed resolution:

In section 3.4, "Component Data Model", in the description of the
SubcomponentInstantiationDescription class, add the following text
to the "Associations":

selectRequirement: Requirement [*]
Expresses selection requirements on the implementation that
will be chosen for the subcomponent. During planning, these
selection requirements are matched against implementation
capabilities in the ComponentImplementationDescription elements
that are part of the referenced package

This is a new issue for the Deployment FTF:

Instead of introducing a new set of rules, the existing rules
for XMI 2.0 Schema Production should be used.

Proposed resolution:

In section 6.1, "Introduction", change the last paragraph to read,

The M1 mapping is realized using the UML Profile for CORBA, the
M2 mapping is realized using the XML Metadata Interchange (XMI)
Version 2 specification, chaper 2, "XML Schema Production."

In section 6.5, "PIM for CCM to PSM for CCM for XML Transformation",
change the first paragraph to read

This section defines transformation T3 (as described in the
introduction). It transforms the PIM for CCM into a PSM for CCM
for XML that can be used to generate a concrete XML schema using
the mapping rules described in chapter 2, "XML Schema Production"
of the XML Metadata Interchange (XMI) Version 2 specification.

Change the Generic Transformation Rules to read

Data model elements, annotated with the «Description» or
«enumeration» stereotype (or a stereotype that inherits from it),
are used to generate XML schema for persistent storage of metadata.

Management model elements, annotated with the «Manager» or
«Exception» stereotype, are not part of the PSM for CCM for XML,
they are mapped to IDL only.

All classes in the PSM for CCM for XML are annotated with the
"org.omg.xmi.contentType" tag set to the value "complex".

All attributes are annotated with the "org.omg.xmi.element"
tag set to "true".

All packages are annotated with the "org.omg.xmi.nsURI" tag
set to "http://www.omg.org/DnC" and the "org.omg.xmi.nsPrefix"
tag set to the value "DnC".

In the Special Transformation Rules section, in the description for
the Any type, delete the Note that reads "Investigate whether the Any
type that is part of XMI is sufficient."

In the Others subsection of the Special Transformation Rules, add the
following paragraph:

The location attribute of the ImplementationArtifactDescription
class and the idlFile attribute of the ComponentInterfaceDescription
class contain URIs pointing to a file. URIs that consist of a
relative path (using the rel_path branch in the URI BNF) are
interpreted relative to the directory that the current document
is in. URIs that consist of an absolute path (using the abs_path
branch in the URI BNF) are interpreted relative to the current
package.

Change the Transformation Exceptions and Extensions section to read

Metadata for a component package is usually spread out across several
XML files, which we call descriptors. Certain associations are expected
to be expressed by links within the same document, others are expected
to link across documents. XMI takes care of both patterns by way of
"proxies," which do not contain nested elements but a link attribute
(either "href" or "xlink:href") referencing the target element by URI.
A schema produced using the XMI rules for schema production allows
proxies to appear anywhere.

Composition associations in the model express that the class at the
composite end owns and contains the class at the part end. In an XML
file, the element that defines the class at the part end usually
directly contains the definition for the class at the composite
end. Since the default multiplicity on the near end of a composite
association is one to one, the contained item cannot be legally
contained in another element. It is possible to store it by itself
in a separate file, though.

For non-composite associations between classes with a common owner
(composite end of composition), the definition of the class at the
source end of the association must contain a proxy linking to the
element at the target end of the association. The definition of the
class at the source end cannot contain the definition of the element
at the target end, because it is owned by the common owner, and its
identity cannot be duplicated.

Non-composite associations between classes that do not have a common
owner are usually expressed by the element definining the class at
the source end containing a proxy that links to an external document.
Direct containment is possible but may result in duplicated data.

While tools can decide to either combine information into a single
XML document or to place information into arbitrary files, using XMI
proxies to link to that information, it is expected that some model
elements usually appear as the outermost document element of a
standalone XML file. These commonly used descriptors are assigned
descriptive terms and standard file extensions.

• A Component Package Descriptor contains a ComponentPackageDescription
  document element; it has the ".cpd" file extension.

• A Component Implementation Descriptor contains a
  ComponentImplementationDescription document element; it has the
  ".cid" file extension.

• An Implementation Artifact Descriptor contains an
  ImplementationArtifactDescription document element; it has the
  ".iad" file extension.

• A Component Interface Descriptor contains a
  ComponentInterfaceDescription document element; it has the
  ".ccd" (CORBA Component Descriptor) file extension.

• A Domain Descriptor contains a Domain document element; it has
  the ".cdd" (Component Domain Descriptor) file extension.

• A Deployment Plan Descriptor contains a DeploymentPlan document
  element; it has the ".cdp" (Component Deployment Plan) file
  extension.

• A Toplevel Package Descriptor contains a
  ToplevelPackageDescription document element; it has the
  "package.pcd" file name.

• Package files use the ".cpk" extension.

Spreading information across files according to these patterns
allow better reuse, for example by extracting an implementation
from a package.

Proxies follow the linking semantics specified by XMI. If a URI
reference does not contain a fragment identifier (the "#id_value"
part), then the target of the reference is the outermost document
element of an descriptor file. If the link attribute of a
ComponentPackageDescription proxy that is part of a
SubcomponentInstantiationDescription element does not contain
a fragment identifier, then the referenced file can be either
a Component Package Descriptor or a package (i.e. a ZIP file
with the ".cpk" extension containing the package).

If a proxy's URIs consists of a relative path (using the rel_path
branch in the URI BNF), then it is interpreted relative to the
directory that the current document is in. URIs that consist of
an absolute path (using the abs_path branch in the URI BNF) are
interpreted relative to the current package.

If a proxy's URI reference is a relative path, then the referenced
file is looked for in the same directory as the document that
contains the referencing element. If the URI reference is an absolute
path, then the referenced file is looked for in the same package as
the document that contains the referencing element.

For backward compatibility, if the target of a proxy link does not
exist, it will also be looked for under a top level "meta-inf"
directory.

Change the Mapping to XML section to read

After applying the transformations defined in this section, an XML
Schema is generated by applying the rules set forth in the XML
Metadata Interchange specifcation, chapter 2, "XML Schema Production."

Delete section 6.6, "Mapping Discussion."

Delete chapter 7, "Mapping to XML Schema."

This is a new editorial issue for the Deployment FTF:

The SatisfierProperty class contains a reference to a DataType
(SatisfierPropertyKind), which is not legal MOF. "kind" should
be listed as an attribute.

Proposed resolution:

In section 3.10, "Common Elements", for the SatisfierProperty
class, move "kind" from Associations to Attributes. While at it,
also correct the typo that shows kind to have zero to many multi-
plicity. The correct multiplicity is exactly one, as shown in the
diagram.

In section 6.3, "PIM to PIM for CCM Transformation", update the
diagram for ComponentInterfaceDescription to show "kind" as an
attribute, removing the association to CCMComponentPortKind.

In the same section, update the diagram for PlanSubcomponentPort-
Endpoint to show "kind" as an attribute, also removing the asso-
ciation to CCMComponentPortKind

Elements of the DeploymentPlan use the "label" attribute and
describe it as a unique identifier, which is inconsistent with
the description of the label attribute in the modeling
conventions.

Proposed resolution:

Elements of the DeploymentPlan do not need a "human readable
label". They should have "name" and "source" attributes. The
Planner can generate unique names for all elements, and use
the "source" attribute to provide traceability, by filling it
with location data for the source element in the Component
Data Model. In an error condition, the exception can indicate
the name of the faulty item in the Deployment Plan, a user can
then locate this element by name, read the source attribute,
and thus trace the error to the original element.

In section 3.8, "Execution Data Model", in the Attributes
section for the ArtifactDeploymentDescription class, delete
the "label" attribute, and add "name" and "source" attributes:

• name: String A unique identifier for this element of
  the DeploymentPlan
• source: String [*] Identifies the ImplementationArtifact-
  Description elements that caused this
  artifact to be part of the deployment.

Replace the third paragraph of the Semantics section ("A Planner
can generate a human readable label ...") with

A Planner may compose a human readable value for the source
attribute by combining the label attributes of packages,
implementations, assembly subcomponents and Implementation-
ArtifactDescription elements, describing a "path" of the
artifact's origins in the Component Data Model. The source
attribute may have more than one element, since Artifact-
DeploymentDescription elements may be shared among instance
deployments, if the same implementation artifact is part of
multiple component implementations. In case of an error, a
user can use this information to track the problem and
identify its source.

A Planner must generate a name that is unique among the top-
level elements in a DeploymentPlan.

In the Attributes section for the MonolithicDeploymentDescrip-
tion class, delete the "label" attribute, and add "name" and
"source" attributes:

• name: String A unique identifier for this element of
  the DeploymentPlan
• source: String [*] Identifies the MonolithicImplementation-
  Description elements that caused this
  component to be part of the deployment.

Replace the second paragraph of the Semantics section ("A
Planner can generate a human readable label ...") with

A Planner may compose a human readable value for the source
attribute by combining the label attributes of packages,
implementations, assembly subcomponents and MonolithicImple-
mentationDescription elements, describing a "path" of the
component implementation's origins in the Component Data
Model. The source attribute may have more than one element,
since MonolithicDeploymentDescription elements may be shared
among instance deployments, if the same component implementation
artifact is deployed more than once. In case of an error, a
user can use this information to track the problem and
identify its source.

A Planner must generate a name that is unique among the top-
level elements in a DeploymentPlan.

In the Attributes section for the InstanceDeploymentDescrip-
tion class, delete the "label" attribute, and add "name" and
"source" attributes:

• name: String A unique identifier for this element of
  the DeploymentPlan
• source: String Identifies the MonolithicImplementation-
  Description elements that caused this
  component to be part of the deployment.

Replace the first paragraph of the Semantics section ("A Planner
can generate a human readable label ...") with

A Planner may compose a human readable value for the source
attribute by combining the label attributes of packages,
implementations, assembly subcomponents and MonolithicImple-
mentationDescription elements, describing a "path" of the
component implementation's origins in the Component Data
Model. In case of an error, a user can use this information
to track the problem and identify its source.

A Planner must generate a name that is unique among the top-
level elements in a DeploymentPlan.

In the Attributes section for the PlanConnectionDescription
class, delete the "label" attribute, and add "name" and "source"
attributes:

• name: String A unique identifier for this element of
  the DeploymentPlan
• source: String [*] The labels of all AssemblyConnection De-
  scription elements that were combined into
  this PlanConnectionDescription.

Add to the Semantics section:

A Planner may compose a human readable value for the source
attribute by combining the label attributes of package imple-
mentations, assembly subcomponents and AssemblyConnectionDe-
scription elements, describing a "path" of the connection's
origins in the Component Data Model. The source attribute may
have more than one element, since a connection in the "flatte-
ned" plan might be a combination of multiple connection segments
on different levels of the assembly hierarchy. In case of an
error, a user can use this information to track the problem
and identify its source.

A Planner must generate a name that is unique among the top-
level elements in a DeploymentPlan.

In the Attributes section for the PlanPropertyMapping class,
delete the "label" attribute, and add "name" and "source"
attributes:

• name: String A unique identifier for this element of
  the DeploymentPlan
• source: String [*] The labels of all AssemblyConnection De-
  scription elements that were combined into
  this PlanConnectionDescription.

Add to the Semantics section:

A Planner may compose a human readable value for the source
attribute by combining the label attributes of package imple-
mentations, assembly subcomponents and AssemblyPropertyMapping
elements, describing a "path" of the mapping's origins in the
Component Data Model. The source attribute may have more than
one element, since a mapping in the "flattened" plan might be
a combination of multiple mapping "segments" on different
levels of the assembly hierarchy. In case of an error, a user
can use this information to track the problem and identify its
source.

A Planner must generate a name that is unique among the top-
level elements in a DeploymentPlan.

In section 3.11, "Exceptions", rename the "label" attribute to
"name" in the ResourceNotAvailable, PlanError, StartError and
StopError exceptions.

For consistency, also make a similar change in the PackageError
exception: delete the "label" attribute, and add a "source"
attribute:

• source: String Identifies a location in the package
  where the error occured.

Change the Semantics section to read:

The implementation of the RepositoryManager interface should
compose a human readable value for the source attribute from
the label attributes of elements in the hierarchy defined by
the PackageConfiguration, ComponentPackageDescription, Compo-
nentImplementationDescription, SubcomponentInstantiationDe-
scription, AssemblyConnectionDescription, AssemblyProperty-
Mapping and ImplementationArtifactDescription elements so
that a user can locate the problem as precisely as possible.

This is an editorial issue for the Deployment FTF:

MOF requires that all associations and association ends be
named. The model conventions section should mention default
names even if they are suppressed in the diagrams.

Proposed resolution:

In section 3.3, "Model Diagram Conventions", rewrite paragraphs
4 ("Role names on association ends ..."), 5 ("Role names at the
navigable end ..."), 6 ("If a role names is suppressed ...") and
7 ("If an association name is suppressed ...") to read

Role names on associations are made explicit wherever they are
expected to appear in generated code, e.g. as an interface's
attribute name.

Role names at the navigable end of a derived association are
normally suppressed. Therefore, if the role name at the navigable
end of an association is suppressed, the association is derived.

If a role name is suppressed at the end of an association, the
name of the type at the association end, starting with a lowercase
character, is used as the role name. This is the same implicit
rule as in OCL.

Implicit association names are used throughout the model. For
unidirectional associations, the name of the class at the source
plus an underscore plus the name of the navigable end is used as
the name of the association. For bidirectional associations, the
concatenation of the class names at both ends, in alphabetical
order, with an underscore inbetween, is used as the name of the
association.

This is an issue for the Deployment FTF:

The sequence metatype is not required in MOF. Parameter and
attribute multiplicities should be used instead.

Proposed resolution:

In section 3.3, "Model Diagram Conventions", delete paragraphs 9
("This specification is aligned with MOF 1.4 ...") and 10 ("Note-
Instances of the Sequence metaclass ...") and the diagram preceding
paragraph 9.

Add paragraph:

"This specification uses the notation of placing the multiplicity
in square brackets after the type, as in "label: String [1]". If
the multiplicity is omitted from an attribute, parameter or return
value, the default of one to one is used."

Throughout the document, replace all occurences of the Sequence
type with the new notation.

In section 6.4, "PIM for CCM to PSM for CCM for IDL Transformation",
in the Generic Transformation Rules subsection, rewrite paragraphs
3 ("Wherever the multiplicity at the navigable end of a navigable
association ...") and 4 ("A similar rule is applied for all uses of
the Sequence data type ...") to read:

Wherever the multiplicity of an attribute, parameter or return
value is not exactly one (but 0..1, 1..* or *), a new class is
introduced to represent a sequence of the type of the attribute,
parameter or return value. The sequence class has the <<CORBA-
Sequence>> stereotype, and its name is the english plural of
the name of the type. The sequence class has a composition
association with the element class that is navigable from the
sequence to the element. The composition is qualified with the
index of the sequence. The attribute, parameter or return value
is then replaced with an attribute, parameter or return value,
respectively, with the same name as before, but with the type
being the newly introduced sequence class and the exactly one
(1..1) multiplicity.

A similar rule is applied to all navigable association or
composition ends whose multiplicity is not exactly one (but
0..1, 1..* or *): a new class is introduced to represent a
sequence of the class at the navigable end, this sequence
class is defined as described above. The original association
or composition end is then replaced with a navigable association
or composition end, with the same role name as before, at the
new sequence class, with a multiplicity of exactly one (1..1).
According to the rules in the UML Profile for CORBA, these
associations and compositions will then map to a structure
member in IDL, its type being a named sequence of the
referenced type.

Excepted from the two rules above are attributes, parameters,
return values or navigable association or composition ends
where the type is String, unsigned long or Endpoint, Instead
of defining new sequence types, the existing types in the
CORBA package are being used; see below.

In section 6.4, "PIM for CCM to PSM for CCM for IDL Transformation",
in the Special Transformation Rules subsection, rewrite the items
for "Sequence(String)", "Sequence(unsigned long)" and "Sequence(End-
point)" to talk about "Sequence of String", "Sequence of unsigned
long" and "Sequence of Endpoint", respectively.

This is a new editorial issue for the Deployment FTF:

The ImplementationArtifactDescription class makes use of a
dependency relationship (to ImplementationArtifact), which is
not a MOF construct. The dependency should be removed from the
core model and moved to a non-normative package instead. Also,
as a meta-concept, ImplementationArtifact should not be part
of the ComponentDataModel.

Proposed resolution:

In section 3.4, "Component Data Model", in the description of the
ImplementationArtifactDescription, remove the <<describes>> depen-
dency to ImplementationArtifact from the diagram. Remove the
ImplementationArtifact class.

In section 3.12, "Relations to Other Standards", add Implemen-
tationArtifactDescription to the diagram, and show its dependency
on ImplementationArtifact. Paste the description and semantics
for ImplementationArtifact from the text that was cut from section
3.4.

At the beginning of section 3.12, add the explanation

This section relates some classes in this platform independent
model to classes from other packages. This section is explanatory
and non-normative.

The ComponentImplementationDescription class references the
ComponentPackageReference class to express dependencies on
implementations that have to exist in the target environment.
Because of the different semantics, a new class should be
introduced instead.

Proposed resolution:

In section 3.10, "Common Elements", add an ImplementationDepen-
dency class as follows:

ImplementationDependency

Description

Expresses a dependency that an implementation has on the
target environment. Before this implementation can be
deployed, an application of the required type must exist
(it must have finished launching) in the target environment.

Attributes

• requiredType: String The interface type of which an
  application must exist.

Associations

No associations.

Constraints

No constraints.

Semantics

When launching an application, the ExecutionManager and
DomainApplicationManager verify that applications of the
required type are already executing.

In section 3.4, "Component Data Model", in the Associations
section for the ComponentImplementationDescription class, update
the type of the dependsOn association to be ImplementationDepen-
dency:

• dependsOn: ImplementationDependency [*] Expresses a depen-
  dency on another package; implementations of the referenced
  interfaces must be deployed in the target environment before
  this implementation can be deployed.

In section 3.8, "Execution Data Model", in the Associations
section for the DeploymentPlan class, update the type of the
dependsOn association to be ImplementationDependency.

2.The CCM XML is totally replaced with new Schema XML. Companies have
invested a great about of money in implementing the existing CCM XML. So I
don't think the XML should be totally replaced. I think the XML should have
been extended where changes need to be made to address Deployment &
Configuration needs. There should be two PSMs, one for DTDs XML and one for
Schema XML both derived from the same PIM. This PIM should have been based
from the CCM XML and extended/modified where necessary. The JTRS SCA is
based upon the CCM XML and the SCA made some D&C extensions. I am not
expecting the SCA extensions to be adapted as standard within the OMG but
the concepts. Some of these SCA concepts are in the D&C submission.
Recommendation is add a XML DTD PSM definition and use similar names that
were in the CCM XML DTD to reduce impact. Lets not reinvent the wheel
unnecessary.

Should be able to create Applications dynamically solely based upon the
Component Package Description. Submission was to address both static and
dynamic deployment. Only static being addressed in specification based upon
existing deployment plan. A system can determine how to deploy the
component based upon the component's deployment requirements and domain
target environment capabilities. Recommendation is to add an Application
Factory concept that is associated with a Component Package Description
that can create an application that determines the deployment plan
dynamically. The Application that gets created is the same Application type
created from a Domain Application Factory. This deployment behavior was in
the previous CCM specification and in the current SCA. The appropriate name
for this should be Domain Application Factory but this is name already in
use the specification. I suggest renaming Domain Application Factory to a
different name since it is based upon a specific deployment plan, so this
name can be used for above behavior. The above Application Factory concept
could be used to support any deployment plan since it has to obey the
component package description

Some attributes (like UUIDs and labels) are described as
optional. In the model, optional attributes (multiplicity 0..1)
should be used for them; this has the advantage that no empty
elements are needed in XML documents; optional attributes could
still be mapped to empty (but non-optional, i.e. non-sequence)
strings in the PSM for CCM for IDL.

Proposed resolution:

Make all occurences of "label" and "UUID" attributes optional by
changing "label: String" to "label: String [0..1]", likewise for
UUID. The default value is set to "" (the empty string).

In section 6.4, "PIM for CCM to PSM for CCM for IDL Transformation",
add a paragraph that reads

For all attributes of type String with multiplicity 0..1, update
the multiplicity to 1..1. If the value is missing in an XML re-
presentation of the model, the empty string is used as the default
value.

References to specific versions of MOF, UML, XMI, UML Profile to
CORBA, URIs etc. should be mentioned.

Proposed resolution:

Add "normative" references to:

• CORBA Components 3.0
• HTTP 1.1 (RFC 2616)
• MIME (RFC 2045)
• MOF 1.4
• UML 1.5
• UML Profile for CORBA
• Uniform Resource Identifiers (RFC 2396)
• Uniform Resource Names (RFC 2141)
• XML Metadata Interchange 2.0
• Extensible Markup Language
• XML Schema
• ZIP File Format

Add "non-normative" references to:

• MOF 2.0 Core Proposal
• UML 2.0 Infrastructure submission
• UML 2.0 Superstructure submission
• UML Profile for QoS submission

Use these references throughout the document wherever appropriate.

The Execution Data Model explains that the Planner may construct
label attributes from the Component Data Model's label attributes.
This is problematic, and does not provide traceability if the
original label attributes are empty. An alternative is to name
each subelement. This is easy e.g. in the ComponentAssemblyDes-
cription, by changing the label attribute to name. For the
implementations in a package, or for artifacts in a monolithic
implementation, a qualified association could be used, were they
available in MOF (they are not); new classes would have to be
introduced, such as a NamedComponentImplementationDescription
class that is contained by the ComponentPackageDescription, has
a name attribute and a reference to the "real" ComponentImple-
mentationDescription.

Proposed resolution:

In the elements of a ComponentAssemblyDescription (Subcomponent-
instantiationDescription, AssemblyConnectionDescription, Assembly-
PropertyMapping), change the "label" attribute to a "name" attri-
bute, and clarify that the name must be unique among these ele-
ments.

Introduce a new class NamedComponentImplementationDescription
with a 1..1 association to ComponentImplementationDescription.
Edit ComponentPackageDescription by making its 1..* "implements"
relationship point to the new class.

Introduce a new class NamedImplementationArtifactDescription
with a 1..1 association to ImplementationArtifactDescription.
Edit MonolithicImplementationDescription by making its 1..*
"primaryArtifact" relationship point to the new class. Edit
ImplementationArtifactDescription by making its 0..* "dependsOn"
relationship point to the new class.

Throughout the ExecutionDataModel, clarify that these names are
used (instead of labels) to generate a human readable path that
identifies the source element.

There is no way for a client to put a package into the reposi-
tory at runtime, without creating an XML-based, ZIP'd package.
It might be useful to have a createPackage (name, label, package,
baseURL) in the Repository Manager. This method would do less
than the installPackage methods. Relative URLs in the package
would be interpreted according to the baseURL.

Proposed resolution:

In section 3.5, "Component Management Model", add a createPackage
operation to the RepositoryManager interface:

createPackage (name: String, label: String,
package: ComponentPackageDescription,
baseLocation: String)

Installs a ComponentPackageDescription in the repository,
assigning the given name and label to the new Package-
Configuration. Relative locations in elements of the package
are interpreted according to the baseLocation. Raises the
PackageError exception if an internal error is detected
in the package.

Subject:
Submission allows multiple objects with identical names (unique identifiers, UUID, URI).

Problem:
This creates an enormous potential risk for object identification errors, by allowing duplicate identities to exist. Risks include problems reclaiming resources, naming service references, etc. Some examples of this area of concern are provided below, there might be other instances that have not been identified in this list.

MOF 2.0 document states
8.3. Classifier requirements for instantiation
Names must be unique within Class, Package, and Operation

Examples:
6.4.3.4 Constraints
If the UUID attribute is not the empty string, then it must contain a unique identifier for the package; packages with the same non-empty UUID must be identical.

6.4.4.4 Constraints
If the UUID attribute is not the empty string, then it must contain a unique identifier for the implementation; implementations with the same non-empty UUID must be identical.

6.4.15.4 Constraints
If the UUID field is non-empty, then it must contain a unique identifier for the artifact; artifacts with the same non-empty UUID must be identical.

6.4.17.4 Constraints
If the UUID field is non-empty, then it must contain a unique identifier for the interface; interfaces with the same non-empty UUID must be identical.

Proposed Resolution:
Correct requirements to disallow any use of duplicate (identical) identifiers in all defined name spaces.

Reformatting the submission to match the ISO format created an
empty "Terms and Definitions" chapter. We must fill it with some
content.

>From the template:

"For the purposes of this specification, the following terms and
definitions apply /the terms and definitions given in [list of
other documents] and the following apply. The Terms and definitions
clause is an optional element giving definitions necessary for
the understanding of certain terms used in the specification.
The term and definition list is introduced by a standard wording
(above), which shall be modified as appropriate."

This chapter should probably define concepts like Component,
Component Package, Assembly, Repository, Domain, ...

The current mapping for the Any type in the PSM for CCM for XML
(section 9.5.4, page 117 in ptc/03-07-08) is very verbose, for
example an execution parameter property looks like

<execParameter>
<name>entrypoint</name>
<value>
<type>
<simple>
<type>string</type>
</simple>
</type>
<value>
<value>
<value>main</value>
</value>
</value>
</value>
</execParameter>

While not quite "broken," the mapping could be simplified - and
made less intimidating to those who prefer looking at XML code in
a text editor - by not separating the DataType from the DataValue,
but by combining them. An updated UML diagram for a better mapping
of the Any type is attached - it would eliminate the DataValue
type. By including an "Opaque" element of "base64Binary" type,
this mapping includes a potential resolution for 5993.

According to this updated mapping, the execution parameter above
would look like

<execParameter>
<name>entrypoint</name>
<value>
<simple>
<type>string</type>
<value>main</value>
</simple>
</value>
</execParameter>

in the last telecon, there was some concern about the MIME
reference, which is used from the XML mapping, which explains,
"For convenience, if the data type is a sequence or array of
octet, the value is represented by a single SimpleValue
element that holds, in the value attribute, the data in
Base64 encoding."

An alternative would be to add a new "BinaryValue" element to
the DataValue element; the BinaryValue could then be declared
to have the "base64Binary" type that is predefined by the XML
Schema spec. The one argument in favor of that is that we could
then depend on XML to define that element's contents (rather
than referencing MIME separately).

The install and uninstall operations should be decoupled from the XML
parsing interface. There may be systems that don't offer this capability of
a visible XML parser but still need the capability to install and
uninstall

3.Package, Component, Component Implementation Description elements, etc.
have no informational attributes such as description, author, title,
version. Why were these attributes left out at the PIM level?
Recommendation is to add these elements to PIM and PSM

Reformatting the submission to match the ISO format created an
empty "Scope" chapter. We must fill it with some content.

>From the template:

"A paragraph or two. The Scope clause shall appear at the beginning
of each specification and define, without ambiguity, the subject of
the specification and the aspect(s) covered. It indicates the limits
of applicability of the specification or particular parts of it. It
shall not contain requirements. The scope shall be succinct so that
it can be used as a summary for bibliographic purposes. It shall be
worded as a series of statements of fact. Forms of expression such
as «This specification defines [establishes] [gives guidelines for]
[defines terms] [specifies] ...» shall be used. Statements of
applicability of the standard shall be introduced by the wording
«This specification is applicable to ...»."

4) page 96: Is it intentional that Capability class is not present in the
figures describing the profile? I have the same question with the
Requirement class.

2) page 65 : according to the UML diagram, the targetManager association
described in the ApplicationManager class should only be described in the
DomainApplicationManager class .

There are two typos in the names of packages as mentioned in the
Model Diagram Conventions: it should be Component and Exception
(singular) instead of Components and Exceptions.

Proposed resolution:

In section 3.3, "Model Diagram Conventions," change the second
sentence of the first paragraph from

All classes are part of the Deployment and Configuration package,
which contains the Components, Target, Execution, Common and
Exceptions subpackages.

to read

All classes are part of the Deployment and Configuration package,
which contains the Component, Target, Execution, Common and
Exception subpackages.

In the PSM for CCM chapter, should the result of the T1 trans-
formaion be called PIM for CCM or PSM for CCM? I believe there
was a majority for "PSM" at the OMG meeting in Paris.

Proposed resolution: Change all occurences of "PIM for CCM" to
"PSM for CCM".

It should read "context Capability", not "context Capacity".

The ComponentExternalPortEndpoint and ExternalReferenceEndpoint
classes are used by both the Component Data Model and Execution
Data Model. They should therefore appear in the Common package.

Proposed resolution:

In section 3.4, "Component Data Model", cut the ComponentExternal-
PointEndpoint and ExternalReferenceEndpoint classes. Paste them
into section 3.10, "Common Elements."

1) page 16 : in the Table 1 (D& C Model Segmentation Summary), the crossing
between "Execution Model" and "Management Model" should be " Execution
Management Model " instead of " Target Execution Model

Paragraph 1 of 9.5.1 of document ptc/03-10-01 could be interpreted to mean
that persistence was somehow required. Since this is not normative, the wording should be fixed to avoid such an implication;

Old paragraph:

Data model elements, annotated with the «Description» or «enumeration» stereotype (or a stereotype that inherits from it), are used to generate an XML schema for persistent storage of metadata.

Proposed new paragraph:

Data model elements, annotated with the «Description» or «enumeration» stereotype (or a stereotype that inherits from it), are used to generate an XML schema for representing metadata in XML documents for distribution, interchange or persistence. The only normative use of such XML-based metadata in this specification is for installing component packages using the RepositoryManager's installPackage operation.

Paragraph 2 of section 9.5.8 (of document ptc/03-10-01) is very confusing. While it is not normative, it is worth making clearer.
(Original defect identified by Kevin Richardson).

Existing paragraph:

Composition associations in the model express that the class at the composite end owns and contains the class at the part end. In an XML file, the element that defines the class at the part end usually directly contains the definition for the class at the composite end. Since the default multiplicity on the near end of a composite association is one to one, the contained item cannot be legally contained in another element. It is possible to store it by itself in a separate file, though.

Proposed improved paragraph:

Composition associations in UML express that the class at the composite end (the containing class) owns and contains the class at the part end (the contained class). It is typical, in XML documents, for instances of contained classes to be embedded within the instance of the containing class. However, it is also possible to store contained instances by themselves in a separate file by using a proxy (using "href" or "xlink:href") to reference the contained instance in a separate file.
Since the multiplicity on the composite end of a composite association is always one to one in this specification, contained instances can only have a single such proxy reference.

Deployment & Configuration Technical Issue
6.4.14 MonolithicImplementationDescription

The deployRequirement relationship is too broad. A component implementation
needs to able to specify
resources required (used by) a component and a resource deployed on
requirement.

Also in the ComponentAssemblyDescription you need to be able to reference
these (both types) resources so a component in the
assembly can connect to these resources.

These are concepts in the SCA that are not in the D & C specification.

In the adopted specification, some classes used "label" attributes
for identification purposes to support traceability. Issue 5964
changed these classes to have "name" instead of "label" attributes.
However, some references to the "label" attributes still exist in
the document.

Proposed resolution:

In section 6.4.9.1, remove the paragraph that reads

A label can optionally be associated with the AssemblyCon-
nectionDescription. Assembly design tools might use this label
to visualize the connection.

In section 6.8.3.1, change the fifth sentence of the first paragraph
from

The MonolithicDeploymentDescription contains a human-readable
label and references ArtifactDeploymentDescription elements for
all artifacts that are part of the deployment.

to read

The MonolithicDeploymentDescription references ArtifactDeploy-
mentDescription elements for all artifacts that are part of
the deployment.

In section 6.11.1.1, update the diagram for the PackageError
exception.

While the problematic paragraph (para 3 in 9.5.8) in the solution to issue 5959 raised by Kevin could possibly be clarified by the proposed text below, the first 4 paragraphs of section 9.5.8 are not normative anyway, but simply elaborate certain flexibilities of the standard XMI MOF-to-XML-schema mapping. Thus while replacing the paragraph might help readers understand it, we might want to consider deleting all these paragraphs since there is no normative content.

Any opinions about whether to use this (better?) paragraph or nuke all four of them?

After Reviewing the official submission for this document, it was discovered that
Rockwell Collins is still listed as a copywrite holder on this document.
Rockwell Collins withdrew as submitter and should nolonger be listed.

In section 9.5.5, the name of the "type" attribute of the ValueType
class is inconsistent. The attribute holding the Repository Id is
named "typeId" elsewhere. Also, the "members" attribute of the
EnumType is inconsisting with the model diagram conventions for
use of the plural, should be "member".

Proposed resolution:

In section 9.5.5, change the name of the "type" attribute of the
ValueType class to "typeId". Change the name of the "members"
attribute of the EnumType class to "member".

The resolution for issue 5962 added references. This included a
reference to RFC 2045 (MIME) for the description of Base64 encoding.
At the same time, the resolution for issue 6024 makes use of Base64
implicit by using the XML data type xsd:base64Binary. Therefore,
there is no need having a normative reference to MIME.

Proposed resolution:

In section 4.1, Remove normative reference to MIME.

6.7.1. Target Manager

The Target manager serves 3 purposes, deployment behavior, domain
information, and registration information. Three different actors use this
component.

Issue 1:

To be consistent with other interfaces for registering and unregistering
information with the domain. I would replace the update operation
with two operations, register node and unregister node. The register node
takes in an abstract nodeManager (needs to be added to spec) and node's xml
profile descriptor. This provides a more open interface and can easily
accommodate extensions by the type of node manager registering and type of
profile information. This allows domains to extend the behavior as
necessary without changing the specification. This needs to be a separate
interface. The separate interface again provides the capability of
extending the registration interface with system/domain specific
registration needs. This also may affect the domain profile definition
since a node can a profile associated with it. For systems or domains
implementations that need this behavior a component could exist that
provides this behavior. Not all systems need to formally register their
information.

Add another subsection to 9.7 miscellaneous and call it Execute Parameters

The specification should make a recommendation and state some well-defined
execparameters that are passed to a process or entry when a component is
manifest by a process. The deployment machinery needs to be able to obtain
the object reference for this component. The execparameters that need to be
specified are:
1. NamingContext of where the component's object reference is to be
placed.
2. Naming Service IOR to be used for this registration
3. Component instance identifier

For SupportedType attribute, how can one distinguish between the interfaces
provided and required for a port when a port is both a provider and a user?

In section 9.6.6, the DataValue class has an attribute named
"ulonglong" with the type being "xsd:ulong". That is a typo, the
type should be "xsd:unsignedLong".

Proposed resolution:

In the diagram of section 9.6.6, change "xsd:ulong" to
"xsd:unsignedLong".

2.3.4 ComponentImplementationDescription
Why do call a single implementation of one component monolithic? An
assembly is more monolithic. A better name would be
ComponentSingleImplementation

On page 115, section 9.4.6 claims that there is an ObjectSeq
type defined in the CORBA module. That is not true. There are
lots of sequences of basic types, but no ObjectSeq.

Proposed resolution:

Delete section 9.4.6.

Using the generic transformation rules and the special rule
for the mapping of the Endpoint class, a Sequence(Endpoint)
will then map to an Endpoints sequence that contains Object
elements, ultimately resulting in the following IDL:

module Deployment

;

Problem:
"UUID names" need to be defined as hierarchical in nature to create global uniqueness, while still supporting a simple local uniqueness. This should be accomplished using the URI approach defined by W3C as referenced in MOF 2.0. This approach provides an unambiguous solution that is scalable.

The following MOF 2.0 excerpt references the W3C URI uniqueness as a solution.

P1_01_MOF-Architecture.fm ad/2002-12-10 1-18
7. MOF 2.0 models the concept of identity. The lack of this capability in MOF, UML, CWM etc., made interoperability of metadata difficult to implement. The submitters understand that modeling identity is not easy, but we plan to show its usefulness in a simple domain - identity of metadata first. A key design goal is to make it easy to map this model of identity to W3C identity and referencing mechanisms such as the URI.

The following excerpt from the W3C URI spec introduces the concept of an absolute URI. Using this absolute URI as a tentative solution would resolve the current naming and uniqueness concerns. An objects globally unique name would consist of its local name space name prefixed with the names of all objects in its containment hierarchy.

Berners-Lee, et. al. Standards Track [Page 10]
RFC 2396 URI Generic Syntax August 1998
3. URI Syntactic Components

The URI syntax is dependent upon the scheme. In general, absolute
URI are written as follows:

<scheme>:<scheme-specific-part>

An absolute URI contains the name of the scheme being used (<scheme>)
followed by a colon (":") and then a string (the <scheme-specific-
part>) whose interpretation depends on the scheme.

The URI syntax does not require that the scheme-specific-part have
any general structure or set of semantics which is common among all
URI. However, a subset of URI do share a common syntax for
representing hierarchical relationships within the namespace. This
"generic URI" syntax consists of a sequence of four main components:

<scheme>://<authority><path>?<query>

each of which, except <scheme>, may be absent from a particular URI.
For example, some URI schemes do not allow an <authority> component,
and others do not use a <query> component.

absoluteURI = scheme ":" ( hier_part | opaque_part )

URI that are hierarchical in nature use the slash "/" character for
separating hierarchical components. For some file systems, a "/"
character (used to denote the hierarchical structure of a URI) is the
delimiter used to construct a file name hierarchy, and thus the URI
path will look similar to a file pathname. This does NOT imply that
the resource is a file or that the URI maps to an actual filesystem
pathname.

hier_part = ( net_path | abs_path ) [ "?" query ]

net_path = "//" authority [ abs_path ]

abs_path = "/" path_segments

URI that do not make use of the slash "/" character for separating
hierarchical components are considered opaque by the generic URI
parser.

opaque_part = uric_no_slash *uric

uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
"&" | "=" | "+" | "$" | ","

We use the term <path> to refer to both the <abs_path> and
<opaque_part> constructs, since they are mutually exclusive for any
given URI and can be parsed as a single component.

Proposed resolution:
Require the use of unique component identifiers, these identifiers cannot be optional, duplicate, or blank/empty. All objects requiring identity management, or providing containment must have unique identifiers constructed using URI format and character content guidelines.

NOTE: there could be both a "relative" local unique identifier, and a global unique identifier (absolute). All objects need the local unique, but not all objects need the absolute global identifier. This point requires further discussion.

Use all unique component identifiers involved in an individual components containment hierarchy to produce a globally unique identifier for it. The W3C URI specification provided above states that this approach using identifiers with separator characters can be used for resources that are not related to file systems. These identifiers are intended to be global identifiers, and not necessarily paths to objects. It could be assumed that a well defined name would provide object locator information if properly used.

The FTF team should feel free to define exactly this global identifier constructed using unique namespace identifiers and "separator characters". The scheme should be described, but left available for implementers to define.

It should be possible to supply alternative URI locations for
artifacts.

Here's another issue that I'd like to put on record before it
gets forgotten. It goes back to the discussion on HTTP. At the
moment, NodeManagers are essentially forced to use HTTP for
downloading artifacts from the Repository, since (a) that is
the "least common denominator" as defined by the specification
and (b) the Repository can offer only a single location.

The proposed solution enables the RepositoryManger to supply
multiple alternative locations for an artifact, one of which
must be a HTTP URI. Other locations could use more optimal
(including non-standard) transports that a NodeManager could
use if supported. (Otherwise, the NodeManager would fall back
to HTTP.)

Proposed resolution:

In section 6.3, "Model Diagram Conventions," change the text
for the standard "location" attribute from

location: references an entity outside of the model. The
location attribute is of type String, its value must comply
to the URI syntax.

to

location: references an entity outside of the model. The
location attribute is of type String, its value(s) must
comply to the URI syntax. Multiple alternative locations
to the same entity may be supplied (multiplicity 1..*);
applications can then choose any of these locations to
access the entity (e.g. choosing a local file URI over
a http reference).

In section 6.4.15.2 (ImplementationArtifactDescription
attributes), change the location attribute to

location: String [1..*] Alternative locations to the
ImplementationArtifact.

In section 6.8.2.2 (ArtifactDeploymentDescription attributes),
change the location attribute to

location: String [1..*] Alternative locations where the
artifact can be loaded from. Copied from Implementation-
ArtifactDescription.

In section 9.3.1 (ComponentInterfaceDescription), change the
idlFile attribute from

idlFile: String

to

idlFile: String [*]

and change the second sentence from

If it is not the empty string, it contains a URL that
references an IDL file that contains the definition for
this component or home.

to

The idlFile attribute, if present, contains alternative URIs
that reference an IDL file containing the component's (or
home's) interface definition.

In section 9.7.5, change the fourth (last) paragraph from

If a RepositoryManager supports URL schemes in addition to
http, it shall offer a configuration parameter that allows
user selection of the scheme(s) that will be used in
ImplementationArtifactDescription elements.

to

The RepositoryManager must supply a "http" URI as part of
the location attribute in the ImplementationArtifactDescription
element. A RepositoryManager may optionally include other
alternative locations to provide NodeManger implementations
with a choice of transports to use for downloading artifacts.

According to section 9.5.6, "the SimpleValue element is used for
primitive values, enum values and object references. Its value
attribute contains a stringified representation of the primitive
value."

It goes on, "for char, wchar, string, wstring types, the value
attribute holds an unquoted literal (i.e. no single or double
quotes, and no leading L prefix) that conforms to the IDL
syntax and semantics chapter."

This was intended to allow inclusion of escaped characters such
as \x0d. However, that is unnecessary, as XML is perfectly able
to process Unicode and escape arbitrary (and markup) characters
in itself, such as

Proposed resolution:

Replace the 10th sentence of the first paragraph of section 9.5.6,

For char, wchar, string, wstring types, the value attribute
holds an unquoted literal (i.e. no single or double quotes,
and no leading L prefix) that conforms to the IDL syntax and
semantics chapter.

to read

For the char and wchar types, the value attribute holds a
string of length 1.

The second paragraph of 9.4.1 (Generic Transformation Rules for the
PIM for CCM to PSM for CCM for IDL Transformation) reads, in part,

To avoid redundancy and circular graphs, non-composite associations
between classes with a common owner are expressed by an ordinal
attribute [...] The value of this attribute is the index of the
target element in its container.

It should be clarified that the index is zero-based.

Proposed resolution:

In section 9.4.1, second paragraph, amend the second sentence to
read,

The value of this attribute is the index of the target element
in its container, with the index of the first element being 0
(zero).

The Interconnect between nodes is more than a reference to a node.
Interconnections between nodes or devices usually entail specific node's
ports that participate in the interconnection.

Throughout the document association names are not consistent. Some
association names are verb phrases and some are noun phrased.
Suggest being consistent by using noun phrases for association role names.
This seems to be common practice in industry. Sections 2.3.3 and 2.3.4 are
examples where verb phrases are being used.

10) typo page 131: the 'reason' fields of the exceptions are all written
'reaon'.

page 131: Inconsistency: A sentence in the §3.4 page 7 is "The included
IDL is normative due to the lack of tools to perform the mapping
automatically." and at page 131 an other one says, "This chapter contains
IDL that has been produced from the PIM using these rules. It is
non-normative, ...".

7) page 99: the deployRequirement association described in the
ComponentAssembly stereotype doesn't appear in the diagrams. It is certainly
a consequence of the point 4).

6) typo page 89: The attribute of the ComponentImplementation class is
written capacityt

Throughout the document not all roles are described in the text. For
example section 2.5.3 interconnect

) typo page 98: "A ComponentImplementation is an abstract class that
contains the defines the attributes and association..."

8) typo page 127: "Regular associations in the UML models (not
aggreagations) ..."