Issue 5953: Sequence metatype
Issue 5954: MOF requires Associations to be Named
Issue 5955: Misuse of ComponentPackageReference for Implementation Dependencies
Issue 5956: Dependency relationships are not a MOF construct
Issue 5957: Inconsistent use of label attribute in DeploymentPlan
Issue 5958: References to DataTypes not valid MOF
Issue 5959: XMI should be used for schema generation
Issue 5960: Missing explanation for selectRequirement in SubcomponentInstantiationDescr
Issue 5961: createPackage operation for RepositoryManager
Issue 5962: References chapter is empty
Issue 5963: Use optional attributes for optional values
Issue 5964: No Traceability if optional labels are blank
Issue 5965: Should be able to create Applications dynamically
Issue 5966: The CCM XML is totally replaced with new Schema XML
Issue 5967: .Package, Component, Component Implementation Description elements, etc
Issue 5969: The install and uninstall operations should be decoupled
Issue 5983: Naming of subpackages
Issue 5984: Typo in OCL for Capability
Issue 5985: PIM or PSM for CCM
Issue 5986: Move shared classes to common
Issue 5993: Base64 encoding
Issue 6024: Any mapping in XML is too verbose
Issue 6025: Scope chapter is empty
Issue 6026: Terms and Definitions chapter is empty
Issue 6027: Submission allows multiple objects with identical names (unique identifiers
Issue 6037: page 16 : in the Table 1
Issue 6038: targetManager association
Issue 6040: Capability class
Issue 6041: typo page 98
Issue 6042: 6) typo page 89
Issue 6043: page 99: the deployRequirement association
Issue 6044: typo page 127
Issue 6045: page 131: Inconsistency
Issue 6046: typo page 131
Issue 6047: Need global unique identifier scheme compliant with MOF 2.0 standard
Issue 6048: There is no ObjectSeq type in orb.idl
Issue 6051: Index base clarification
Issue 6052: Any string content clarification
Issue 6053: Alternative Locations
Issue 6265: Editorial - Consistency
Issue 6266: 2. Editorial - Consistency
Issue 6267: 3. Technical - Interconnect
Issue 6268: Editorial - Renaming Suggestion
Issue 6270: Rockwell Collins listed as submitter
Issue 6382: Troublesome paragraph issue
Issue 6383: Deployment issue: editorial clarification in para 3 in 9.5.8
Issue 6384: Persistence confusion in deployment spec
Issue 6385: No need for MIME reference
Issue 6386: Inconsistent naming of ValueType and EnumType attributes
Issue 6387: DataValue typo
Issue 6388: Dangling references to "label" attribute
Issue 6392: 6.4.14 MonolithicImplementationDescription
Issue 6436: MonolithicImplementationDescription Execute Parameters PSM
Issue 6597: replace the update operation
Issue 6602: 6.4.17 ComponentPortDescription (01)
Issue 6604: 6.4.17 ComponentPortDescription (03)
Issue 7279: ExternalReferneceEndpoint
Issue 7282: Constraint Definition
Issue 7283: ExternalReferneceEndpoint, SubcomponentPortEndpoint, ..
Issue 5953: Sequence metatype (deployment-ftf)
Click here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:
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 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.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.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.
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 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
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."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 packageThere 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.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.
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.
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.
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
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.
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
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
Discussion: During the RTF meetings and telephone conferences the RTF agreed on a general solution outline. This is to split the interface in question into uninstallation/ installation and XML parsing features at PIM level. They may be mapped on a joint interface at PSM level. Since a concrete text proposal for resolution is not yet available, this issue is deferred to the next Deployment RTF
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.
It should read "context Capability", not "context Capacity".
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".
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."
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 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>
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 ...»."
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, ...
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.
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
2) page 65 : according to the UML diagram, the targetManager association described in the ApplicationManager class should only be described in the DomainApplicationManager class .
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.
Discussion: During the RTF meetings and telephone conferences the RTF agreed on a general solution outline. Since a concrete text proposal for resolution is not yet available, this issue is deferred to the next Deployment RTF.
) typo page 98: "A ComponentImplementation is an abstract class that contains the defines the attributes and association..."
6) typo page 89: The attribute of the ComponentImplementation class is written capacityt
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).
Discussion: During the RTF meetings and telephone conferences the RTF agreed on a general solution outline. Since a concrete proposal for resolution is not yet available, this issue is deferred to the next Deployment RTF
8) typo page 127: "Regular associations in the UML models (not aggreagations) ..."
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, ...".
10) typo page 131: the 'reason' fields of the exceptions are all written 'reaon'.
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.
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 {
typedef sequence<Object> Endpoints;
};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).
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.
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.Throughout the document not all roles are described in the text. For example section 2.5.3 interconnect
During the RTF meetings and telephone conferences the RTF agreed that this issue needs to be solved. Since a concrete proposal for resolution is not yet available, this issue is deferred to the next Deployment RTF.
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.
During the RTF meetings and telephone conferences the RTF agreed that this issue needs to be solved. Since a concrete proposal for resolution is not yet available, this issue is deferred to the next Deployment RTF.
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.
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
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.
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?
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.
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.
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.
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".
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".
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.
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.
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
During the RTF meetings and telephone conferences the RTF agreed that a concrete text proposal is needed for resolving this issue. Since such proposal is not yet available this issue is deferred to the next Deployment RTF.
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.
During the RTF meetings and telephone conferences the RTF agreed on a general solution outline. A concrete text proposal is needed for resolving this issue. Since such proposal is not yet available this issue is deferred to the next Deployment RTF.
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?
During the RTF meetings and telephone conferences the RTF agreed on a general solution outline. However, further discussion is needed on the proposed resolution. Thus, this issue is deferred to the next Deployment RTF
For a port definition allow the capability to optional supply port characteristic and capability properties.
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.
During the RTF meetings and telephone conferences the RTF agreed that further information from the poster of this issue is needed. Thus, this issue is deferred to the next Deployment RTF.
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.
During the RTF meetings and telephone conferences the RTF agreed that a concrete text proposal is needed for resolving this issue. Since such proposal is not yet available this issue is deferred to the next Deployment RTF.
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.
During the RTF meetings and telephone conferences the RTF agreed that a concrete text proposal is needed for resolving this issue. Since such proposal is not yet available this issue is deferred to the next Deployment RTF.