Deployment and Configuration of component-based Distributed Applications Avatar
  1. OMG Specification

Deployment and Configuration of component-based Distributed Applications — Open Issues

  • Acronym: DEPL
  • Issues Count: 60
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
DEPL4-1 XML Schema of Deployment spec doesn't honour constraints present in model DEPL 1.0b1 open
DEPL-59 ExternalReferneceEndpoint, SubcomponentPortEndpoint, .. DEPL 1.0b1 open
DEPL-57 ExternalReferneceEndpoint DEPL 1.0b1 open
DEPL-58 Constraint Definition DEPL 1.0b1 open
DEPL-56 6.4.17 ComponentPortDescription (03) DEPL 1.0b1 open
DEPL-54 replace the update operation DEPL 1.0b1 open
DEPL-53 MonolithicImplementationDescription Execute Parameters PSM DEPL 1.0b1 open
DEPL-52 6.4.14 MonolithicImplementationDescription DEPL 1.0b1 open
DEPL-55 6.4.17 ComponentPortDescription (01) DEPL 1.0b1 open
DEPL-50 DataValue typo DEPL 1.0b1 open
DEPL-51 Dangling references to "label" attribute DEPL 1.0b1 open
DEPL-48 No need for MIME reference DEPL 1.0b1 open
DEPL-45 Troublesome paragraph issue DEPL 1.0b1 open
DEPL-47 Persistence confusion in deployment spec DEPL 1.0b1 open
DEPL-49 Inconsistent naming of ValueType and EnumType attributes DEPL 1.0b1 open
DEPL-46 Deployment issue: editorial clarification in para 3 in 9.5.8 DEPL 1.0b1 open
DEPL-42 3. Technical - Interconnect DEPL 1.0b1 open
DEPL-43 Editorial - Renaming Suggestion DEPL 1.0b1 open
DEPL-44 Rockwell Collins listed as submitter DEPL 1.0b1 open
DEPL-41 2. Editorial - Consistency DEPL 1.0b1 open
DEPL-40 Editorial - Consistency DEPL 1.0b1 open
DEPL-38 Any string content clarification DEPL 1.0b1 open
DEPL-39 Alternative Locations DEPL 1.0b1 open
DEPL-35 Need global unique identifier scheme compliant with MOF 2.0 standard DEPL 1.0b1 open
DEPL-34 typo page 131 DEPL 1.0b1 open
DEPL-36 There is no ObjectSeq type in orb.idl DEPL 1.0b1 open
DEPL-37 Index base clarification DEPL 1.0b1 open
DEPL-32 typo page 127 DEPL 1.0b1 open
DEPL-33 page 131: Inconsistency DEPL 1.0b1 open
DEPL-31 page 99: the deployRequirement association DEPL 1.0b1 open
DEPL-30 6) typo page 89 DEPL 1.0b1 open
DEPL-29 typo page 98 DEPL 1.0b1 open
DEPL-28 Capability class DEPL 1.0b1 open
DEPL-27 targetManager association DEPL 1.0b1 open
DEPL-25 Submission allows multiple objects with identical names (unique identifiers DEPL 1.0b1 open
DEPL-26 page 16 : in the Table 1 DEPL 1.0b1 open
DEPL-21 Base64 encoding DEPL 1.0b1 open
DEPL-23 Scope chapter is empty DEPL 1.0b1 open
DEPL-24 Terms and Definitions chapter is empty DEPL 1.0b1 open
DEPL-20 Move shared classes to common DEPL 1.0b1 open
DEPL-22 Any mapping in XML is too verbose DEPL 1.0b1 open
DEPL-19 PIM or PSM for CCM DEPL 1.0b1 open
DEPL-17 Naming of subpackages DEPL 1.0b1 open
DEPL-18 Typo in OCL for Capability DEPL 1.0b1 open
DEPL-15 .Package, Component, Component Implementation Description elements, etc DEPL 1.0b1 open
DEPL-16 The install and uninstall operations should be decoupled DEPL 1.0b1 open
DEPL-11 Use optional attributes for optional values DEPL 1.0b1 open
DEPL-10 References chapter is empty DEPL 1.0b1 open
DEPL-12 No Traceability if optional labels are blank DEPL 1.0b1 open
DEPL-13 Should be able to create Applications dynamically DEPL 1.0b1 open
DEPL-14 The CCM XML is totally replaced with new Schema XML DEPL 1.0b1 open
DEPL-9 createPackage operation for RepositoryManager DEPL 1.0b1 open
DEPL-7 XMI should be used for schema generation DEPL 1.0b1 open
DEPL-8 Missing explanation for selectRequirement in SubcomponentInstantiationDescr DEPL 1.0b1 open
DEPL-5 Inconsistent use of label attribute in DeploymentPlan DEPL 1.0b1 open
DEPL-6 References to DataTypes not valid MOF DEPL 1.0b1 open
DEPL-1 Sequence metatype DEPL 1.0b1 open
DEPL-4 Dependency relationships are not a MOF construct DEPL 1.0b1 open
DEPL-3 Misuse of ComponentPackageReference for Implementation Dependencies DEPL 1.0b1 open
DEPL-2 MOF requires Associations to be Named DEPL 1.0b1 open

Issues Descriptions

XML Schema of Deployment spec doesn't honour constraints present in model

  • Key: DEPL4-1
  • Legacy Issue Number: 7354
  • Status: open  
  • Source: Vanderbilt University ( Krishnakumar Balasubramanian)
  • Summary:

    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" />

  • Reported: DEPL 1.0b1 — Thu, 13 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExternalReferneceEndpoint, SubcomponentPortEndpoint, ..

  • Key: DEPL-59
  • Legacy Issue Number: 7283
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Fri, 30 Apr 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExternalReferneceEndpoint

  • Key: DEPL-57
  • Legacy Issue Number: 7279
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Fri, 30 Apr 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Constraint Definition

  • Key: DEPL-58
  • Legacy Issue Number: 7282
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Fri, 30 Apr 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.4.17 ComponentPortDescription (03)

  • Key: DEPL-56
  • Legacy Issue Number: 6604
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Wed, 12 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

replace the update operation

  • Key: DEPL-54
  • Legacy Issue Number: 6597
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Tue, 11 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MonolithicImplementationDescription Execute Parameters PSM

  • Key: DEPL-53
  • Legacy Issue Number: 6436
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: DEPL 1.0b1 — Wed, 5 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.4.14 MonolithicImplementationDescription

  • Key: DEPL-52
  • Legacy Issue Number: 6392
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Wed, 29 Oct 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.4.17 ComponentPortDescription (01)

  • Key: DEPL-55
  • Legacy Issue Number: 6602
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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?

  • Reported: DEPL 1.0b1 — Wed, 12 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DataValue typo

  • Key: DEPL-50
  • Legacy Issue Number: 6387
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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".

  • Reported: DEPL 1.0b1 — Tue, 21 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Dangling references to "label" attribute

  • Key: DEPL-51
  • Legacy Issue Number: 6388
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Tue, 21 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

No need for MIME reference

  • Key: DEPL-48
  • Legacy Issue Number: 6385
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Tue, 21 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Troublesome paragraph issue

  • Key: DEPL-45
  • Legacy Issue Number: 6382
  • Status: open  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

    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?

  • Reported: DEPL 1.0b1 — Tue, 21 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Persistence confusion in deployment spec

  • Key: DEPL-47
  • Legacy Issue Number: 6384
  • Status: open  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Wed, 22 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent naming of ValueType and EnumType attributes

  • Key: DEPL-49
  • Legacy Issue Number: 6386
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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".

  • Reported: DEPL 1.0b1 — Tue, 21 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Deployment issue: editorial clarification in para 3 in 9.5.8

  • Key: DEPL-46
  • Legacy Issue Number: 6383
  • Status: open  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Wed, 22 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

3. Technical - Interconnect

  • Key: DEPL-42
  • Legacy Issue Number: 6267
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Tue, 9 Sep 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial - Renaming Suggestion

  • Key: DEPL-43
  • Legacy Issue Number: 6268
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: DEPL 1.0b1 — Tue, 9 Sep 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rockwell Collins listed as submitter

  • Key: DEPL-44
  • Legacy Issue Number: 6270
  • Status: open  
  • Source: Rockwell Collins ( David Fitkin)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Wed, 17 Sep 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

2. Editorial - Consistency

  • Key: DEPL-41
  • Legacy Issue Number: 6266
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Tue, 9 Sep 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial - Consistency

  • Key: DEPL-40
  • Legacy Issue Number: 6265
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Tue, 9 Sep 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any string content clarification

  • Key: DEPL-38
  • Legacy Issue Number: 6052
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Tue, 12 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Alternative Locations

  • Key: DEPL-39
  • Legacy Issue Number: 6053
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Wed, 27 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need global unique identifier scheme compliant with MOF 2.0 standard

  • Key: DEPL-35
  • Legacy Issue Number: 6047
  • Status: open  
  • Source: Rockwell Collins ( David Fitkin)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

typo page 131

  • Key: DEPL-34
  • Legacy Issue Number: 6046
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is no ObjectSeq type in orb.idl

  • Key: DEPL-36
  • Legacy Issue Number: 6048
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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; }

    ;

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Index base clarification

  • Key: DEPL-37
  • Legacy Issue Number: 6051
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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).

  • Reported: DEPL 1.0b1 — Tue, 12 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

typo page 127

  • Key: DEPL-32
  • Legacy Issue Number: 6044
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 131: Inconsistency

  • Key: DEPL-33
  • Legacy Issue Number: 6045
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    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, ...".

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 99: the deployRequirement association

  • Key: DEPL-31
  • Legacy Issue Number: 6043
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    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).

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

6) typo page 89

  • Key: DEPL-30
  • Legacy Issue Number: 6042
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

typo page 98

  • Key: DEPL-29
  • Legacy Issue Number: 6041
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Capability class

  • Key: DEPL-28
  • Legacy Issue Number: 6040
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

targetManager association

  • Key: DEPL-27
  • Legacy Issue Number: 6038
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Submission allows multiple objects with identical names (unique identifiers

  • Key: DEPL-25
  • Legacy Issue Number: 6027
  • Status: open  
  • Source: Rockwell Collins ( David Fitkin)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Tue, 29 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 16 : in the Table 1

  • Key: DEPL-26
  • Legacy Issue Number: 6037
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    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

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Base64 encoding

  • Key: DEPL-21
  • Legacy Issue Number: 5993
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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).

  • Reported: DEPL 1.0b1 — Tue, 8 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Scope chapter is empty

  • Key: DEPL-23
  • Legacy Issue Number: 6025
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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 ...»."

  • Reported: DEPL 1.0b1 — Mon, 28 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Terms and Definitions chapter is empty

  • Key: DEPL-24
  • Legacy Issue Number: 6026
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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, ...

  • Reported: DEPL 1.0b1 — Mon, 28 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Move shared classes to common

  • Key: DEPL-20
  • Legacy Issue Number: 5986
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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."

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any mapping in XML is too verbose

  • Key: DEPL-22
  • Legacy Issue Number: 6024
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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>

  • Reported: DEPL 1.0b1 — Mon, 28 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

PIM or PSM for CCM

  • Key: DEPL-19
  • Legacy Issue Number: 5985
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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".

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming of subpackages

  • Key: DEPL-17
  • Legacy Issue Number: 5983
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in OCL for Capability

  • Key: DEPL-18
  • Legacy Issue Number: 5984
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

.Package, Component, Component Implementation Description elements, etc

  • Key: DEPL-15
  • Legacy Issue Number: 5967
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: DEPL 1.0b1 — Wed, 18 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The install and uninstall operations should be decoupled

  • Key: DEPL-16
  • Legacy Issue Number: 5969
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: DEPL 1.0b1 — Wed, 18 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use optional attributes for optional values

  • Key: DEPL-11
  • Legacy Issue Number: 5963
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

References chapter is empty

  • Key: DEPL-10
  • Legacy Issue Number: 5962
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

No Traceability if optional labels are blank

  • Key: DEPL-12
  • Legacy Issue Number: 5964
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Should be able to create Applications dynamically

  • Key: DEPL-13
  • Legacy Issue Number: 5965
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: DEPL 1.0b1 — Wed, 18 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The CCM XML is totally replaced with new Schema XML

  • Key: DEPL-14
  • Legacy Issue Number: 5966
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Wed, 18 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

createPackage operation for RepositoryManager

  • Key: DEPL-9
  • Legacy Issue Number: 5961
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

XMI should be used for schema generation

  • Key: DEPL-7
  • Legacy Issue Number: 5959
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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."

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing explanation for selectRequirement in SubcomponentInstantiationDescr

  • Key: DEPL-8
  • Legacy Issue Number: 5960
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent use of label attribute in DeploymentPlan

  • Key: DEPL-5
  • Legacy Issue Number: 5957
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

References to DataTypes not valid MOF

  • Key: DEPL-6
  • Legacy Issue Number: 5958
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequence metatype

  • Key: DEPL-1
  • Legacy Issue Number: 5953
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • 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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Dependency relationships are not a MOF construct

  • Key: DEPL-4
  • Legacy Issue Number: 5956
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Misuse of ComponentPackageReference for Implementation Dependencies

  • Key: DEPL-3
  • Legacy Issue Number: 5955
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF requires Associations to be Named

  • Key: DEPL-2
  • Legacy Issue Number: 5954
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT