Issue 5958: References to DataTypes not valid MOF (deployment-ftf) Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com) Nature: Uncategorized Issue Severity: 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 Resolution: Revised Text: Actions taken: June 19, 2003: received issue Discussion: End of Annotations:===== Subject: References to DataTypes not valid MOF Date: Thu, 19 Jun 2003 10:09:19 -0400 Thread-Topic: References to DataTypes not valid MOF Thread-Index: AcM2bGAmXnTdvprHQMyfQHdBKcTw7A== From: "Pilhofer, Frank" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h5JE8qkM002738 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. X-Sender: giddiv@postel X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 29 Jun 2003 16:35:27 -0400 To: deployment-ftf@omg.org From: Victor Giddings Subject: Editorial or issue? I'm not sure this is a problem or if I am missing something else. In section 6.3 (page 111 of mars/03-06-03), there is a statement that a kind attribute is added to the ComponentPortDescription class, but it doesn't appear in the UML diagram. Is this a problem? Victor Giddings mailto:victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 295 6501 Victor Giddings mailto:victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 295 6501 Subject: RE: Editorial or issue? Date: Mon, 30 Jun 2003 09:24:00 -0400 Thread-Topic: Editorial or issue? Thread-Index: AcM+fajQYSt8p6ojEdeMjQCgyTbmFwAjLHLw From: "Pilhofer, Frank" To: "Victor Giddings" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h5UDMokM008903 > > I'm not sure this is a problem or if I am missing something else. In > section 6.3 (page 111 of mars/03-06-03), there is a statement > that a kind attribute is added to the ComponentPortDescription class, > but it doesn't appear in the UML diagram. Is this a problem? > Hi Victor, in that diagram, the "kind" appears as a composition association between ComponentPortDescription and CCMComponentPortKind. The issue about it is that references to data types are not allowed in MOF. We should fix this as part of issue 5958. Frank Date: Mon, 30 Jun 2003 17:13:33 +0200 From: Andreas Hoffmann Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: de, en, en-us, en-gb To: Victor Giddings CC: "Pilhofer, Frank" , deployment-ftf@omg.org Subject: Re: Editorial or issue? Pilhofer, Frank wrote: I'm not sure this is a problem or if I am missing something else. In section 6.3 (page 111 of mars/03-06-03), there is a statement that a kind attribute is added to the ComponentPortDescription class, but it doesn't appear in the UML diagram. Is this a problem? Hi Victor, in that diagram, the "kind" appears as a composition association between ComponentPortDescription and CCMComponentPortKind. The issue about it is that references to data types are not allowed in MOF. We should fix this as part of issue 5958. Frank Hello Victor, to answer your general question: I think if a diagram needs to be changed an issue should be raised. In this particular case this can be fixed as part of issue 5958 as Frank already wrote. Regards Andreas ==================================================================== Andreas Hoffmann Fraunhofer FOKUS - Research Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 D - 10589 Berlin Phone: +49 30 3463-7392 Fax: +49 30 3463-8392 Email: andreas.hoffmann@fokus.fraunhofer.de ==================================================================== X-Sender: giddiv@postel X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 30 Jun 2003 17:58:57 -0400 To: deployment-ftf@omg.org From: Victor Giddings Subject: Re: Editorial or issue? At 05:13 PM 6/30/2003 +0200, Andreas Hoffmann wrote: Pilhofer, Frank wrote: I'm not sure this is a problem or if I am missing something else. In section 6.3 (page 111 of mars/03-06-03), there is a statement that a kind attribute is added to the ComponentPortDescription class, but it doesn't appear in the UML diagram. Is this a problem? Hi Victor, in that diagram, the "kind" appears as a composition association between ComponentPortDescription and CCMComponentPortKind. The issue about it is that references to data types are not allowed in MOF. I guess if I were trying to impress y'all, I could claim that I missed it because I knew it wasn't an association. But it would be more honest to admit I just missed it. I also understand the issue now (and concur with the proposed resolution.) Thanks for the clarification. We should fix this as part of issue 5958. Frank Hello Victor, to answer your general question: I think if a diagram needs to be changed an issue should be raised. In this particular case this can be fixed as part of issue 5958 as Frank already wrote. Understood. However, doesn't this mean that proposed resolutions for vote would have to including the revised diagram (instead of just a description of the proposed change)? Regards Andreas Thanks. Victor Giddings mailto:victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 295 6501