${taskforce.name} Avatar
  1. OMG Task Force

Deployment FTF — All Issues

  • Key: DEPL
  • Issues Count: 78
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
DEPL-78 No type safety when external packages are referenced DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-76 MonolithicImplementationDescription Attributes DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-75 Technical sections 2.3.3 and 2.3.4 DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-77 Deployment Behavior DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-74 page 91: In the sequence diagram DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-72 ComponentExternalPortEndpoint definition is not unique enough DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-71 Suggestion is to break ComponentExternalPortEndpoint DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-73 Add "replace" parameter to installPackage DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-70 ExternalReferneceEndpoint need to indicate the type of interface DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-68 For ExternalReferneceEndpoint add provider boolean attribute DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-66 Missing definition for connection in chapter 5: DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-63 property name issue DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-62 6.4.17 ComponentPortDescription (02) DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-67 Semantics of IDL generated from Deployment & Configuration Specification DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-65 Misuse of XMI Proxy Links DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-61 Domain Information DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-69 For ExternalReferneceEndpoint add optional port name attribute DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-60 The submission only gives one choice for managing node resources DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-64 Subcomponents Package Inconsistency DEPL 1.0b1 DEPL 1.0 Resolved closed
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

No type safety when external packages are referenced

  • Key: DEPL-78
  • Legacy Issue Number: 7557
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

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

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

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

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

    Proposed resolution:

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

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

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

    In section 6.4.8.4, ComponentPackageReference Semantics, replace the
    existing text

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

    with

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

  • Reported: DEPL 1.0b1 — Thu, 1 Jul 2004 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 02:08 GMT

MonolithicImplementationDescription Attributes

  • Key: DEPL-76
  • Legacy Issue Number: 6435
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    6.4.14 MonolithicImplementationDescription

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

  • Reported: DEPL 1.0b1 — Wed, 5 Nov 2003 05:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Technical sections 2.3.3 and 2.3.4

  • Key: DEPL-75
  • Legacy Issue Number: 6269
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Tue, 9 Sep 2003 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Deployment Behavior

  • Key: DEPL-77
  • Legacy Issue Number: 6598
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 01:53 GMT

page 91: In the sequence diagram

  • Key: DEPL-74
  • Legacy Issue Number: 6039
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 01:53 GMT

ComponentExternalPortEndpoint definition is not unique enough

  • Key: DEPL-72
  • Legacy Issue Number: 7286
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Sun, 30 Apr 2000 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Suggestion is to break ComponentExternalPortEndpoint

  • Key: DEPL-71
  • Legacy Issue Number: 7285
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Sun, 30 Apr 2000 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add "replace" parameter to installPackage

  • Key: DEPL-73
  • Legacy Issue Number: 7302
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

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

    Proposed resolution:

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

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

    to

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

  • Reported: DEPL 1.0b1 — Wed, 5 May 2004 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExternalReferneceEndpoint need to indicate the type of interface

  • Key: DEPL-70
  • Legacy Issue Number: 7284
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Sun, 30 Apr 2000 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

For ExternalReferneceEndpoint add provider boolean attribute

  • Key: DEPL-68
  • Legacy Issue Number: 7280
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Sun, 30 Apr 2000 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing definition for connection in chapter 5:

  • Key: DEPL-66
  • Legacy Issue Number: 7242
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Andreas Hoffmann)
  • Summary:

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

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

  • Reported: DEPL 1.0b1 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

property name issue

  • Key: DEPL-63
  • Legacy Issue Number: 6632
  • Status: closed  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Tue, 18 Nov 2003 05:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.4.17 ComponentPortDescription (02)

  • Key: DEPL-62
  • Legacy Issue Number: 6603
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Wed, 12 Nov 2003 05:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of IDL generated from Deployment & Configuration Specification

  • Key: DEPL-67
  • Legacy Issue Number: 7278
  • Status: closed  
  • Source: Vanderbilt University ( Krishnakumar Balasubramanian)
  • Summary:

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

    struct SharedResource

    { string name; ::CORBA::StringSeq resourceType; ::CORBA::ULongSeq nodeRef; SatisfierProperties property; }

    ;

    typedef sequence < SharedResource > SharedResources;

    struct Resource

    { string name; ::CORBA::StringSeq resourceType; SatisfierProperties property; }

    ;

    typedef sequence < Resource > Resources;

    struct Node

    { string name; string label; ::CORBA::ULongSeq sharedResourceRef; ::CORBA::ULongSeq connectionRef; Resources resource; }

    ;

    struct Domain

    { string UUID; string label; SharedResources sharedResource; Nodes node; Interconnects interconnect; Bridges bridge; }

    ;

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

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

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

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

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

    struct Node;

    typedef Sequence<Node> Nodes;

    struct SharedResource

    { string name; ::CORBA::StringSeq resourceType; Nodes nodeRef; SatisfierProperties property; }

    ;

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

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

    Any clarifications on this would be really helpful.

  • Reported: DEPL 1.0b1 — Sun, 30 Apr 2000 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Misuse of XMI Proxy Links

  • Key: DEPL-65
  • Legacy Issue Number: 7164
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

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

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

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

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

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

    Proposed resolution:

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

    6.4.x ComponentPackageImport

    6.4.x.1 Description

    Imports a package via an URL.

    6.4.x.2 Attributes

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

    6.4.x.3 Associations

    None.

    6.4.x.4 Semantics

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

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

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

    with

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

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

    In 6.4.7.3 (SubcomponentInstantiationDescription associations), add

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

    In 6.4.7.4 (SubcomponentInstantiationDescription constraints), replace

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

    with

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

    context SubcomponentInstantiationDescription inv:
    Set

    {self.package, self.importedPackage, self.reference}

    ->size() =
    1

    In 6.5.1.5 (RepositoryManager semantics), add

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

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

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

  • Reported: DEPL 1.0b1 — Tue, 16 Mar 2004 05:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Domain Information

  • Key: DEPL-61
  • Legacy Issue Number: 6599
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

For ExternalReferneceEndpoint add optional port name attribute

  • Key: DEPL-69
  • Legacy Issue Number: 7281
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Sun, 30 Apr 2000 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The submission only gives one choice for managing node resources

  • Key: DEPL-60
  • Legacy Issue Number: 5968
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Wed, 18 Jun 2003 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Subcomponents Package Inconsistency

  • Key: DEPL-64
  • Legacy Issue Number: 7163
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

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

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

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

    Proposed resolution:

    In 6.4.7.3 (associations for SubcomponentInstantiationDescription),
    change

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

    to

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

  • Reported: DEPL 1.0b1 — Tue, 16 Mar 2004 05:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • 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