Issue 9241: Operation::ownedParameter should be ordered in XMI? (uml2-rtf) Source: Fulcrum Analytics, Inc. (Mr. Richard Vermillion, rvermillion(at)fulcrumanalytics.com) Nature: Uncategorized Issue Severity: Summary: In the latest XMI file (included as part of Ballot 12) the ownedParameter attribute of Core::Constructs::Operation redefines Core::Constructs::BehavioralFeature::ownedParameter -- I'm assuming that this redefinition is a result of the merge of Basic. However, in Operation, the ownedParameter attribute is not ordered. Since both BehavioralFeature::ownedParameter and Core::Basic::Operation::ownedParameter are ordered, it seems strange for Core::Constructs::Operation's not to be ordered. A check of the drafts and ballots does not seem to address this issue or explain why it would be the case. Is it a mistake? Resolution: Infra::Core::{Basic,Constructs}::Operation::ownedParameter {isOrdered=true} in UML 2.2 CMOF. Revised Text: None. Disposition: Closed No Change Revised Text: Actions taken: January 15, 2006: received issue April 26, 2010: closed issue April 26, 2010: closed issue Discussion: End of Annotations:===== m: Richard Vermillion Subject: Operation::ownedParameter should be ordered in XMI? Date: Sun, 15 Jan 2006 19:41:57 -0500 X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: Symantec AntiVirus Scan Engine In the latest XMI file (included as part of Ballot 12) the ownedParameter attribute of Core::Constructs::Operation redefines Core::Constructs::BehavioralFeature::ownedParameter -- I'm assuming that this redefinition is a result of the merge of Basic. However, in Operation, the ownedParameter attribute is not ordered. Since both BehavioralFeature::ownedParameter and Core::Basic::Operation::ownedParameter are ordered, it seems strange for Core::Constructs::Operation's not to be ordered. A check of the drafts and ballots does not seem to address this issue or explain why it would be the case. Is it a mistake? -rv Richard Vermillion CTO & EVP, Fulcrum rvermillion@fulcrm.com http://www.fulcrm.com/ smime10.p7s Subject: RE: Operation::ownedParameter should be ordered in XMI? Date: Sun, 15 Jan 2006 19:03:05 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Operation::ownedParameter should be ordered in XMI? Thread-Index: AcYaNbSaGwxf/J+BSh6a5/60MTNE0wAC6gKw Priority: Urgent From: "Pete Rivett" To: "Richard Vermillion" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k0G2txDb026749 (Richard you should email uml2-rtf@omg.org not uml-rtf) Well spotted - though this is a problem in the spec not in the XMI alone. See below. Pete > -----Original Message----- > From: Richard Vermillion [mailto:rvermillion@fulcrumanalytics.com] > Sent: Monday, January 16, 2006 12:42 AM > To: uml-rtf@omg.org > Subject: Operation::ownedParameter should be ordered in XMI? > > In the latest XMI file (included as part of Ballot 12) the > ownedParameter attribute of Core::Constructs::Operation redefines > Core::Constructs::BehavioralFeature::ownedParameter -- I'm assuming > that this redefinition is a result of the merge of Basic. No I don't think so: it's ordered in Basic also. The redefinition is semi-explicit - i.e. it appears in Fig 66 (of ptc/04-10-14)(there is no explicit {redefines}) nor is it mentioned in the Associations section of Operation. But in both Infrastructure and Superstructure there is no {ordered} on the redefinign property. So the XMI is consistent with the spec (though elsewhere in the spec e.g. semantics of CallAction it states that "Parameters on behaviors and operations are totally ordered lists." and in fact the orderign is required to match to pins. This mistake originates from the Adopted specifiaction - though this part of the spec was changed by Issue 7344, {ordered} was not there in the original either. > > However, in Operation, the ownedParameter attribute is not ordered. > > Since both BehavioralFeature::ownedParameter and > Core::Basic::Operation::ownedParameter are ordered, it seems strange > for Core::Constructs::Operation's not to be ordered. A check of the > drafts and ballots does not seem to address this issue or > explain why > it would be the case. Is it a mistake? Yes it is clearly a mistake - well spotted. Unfortunate since, as I say above, the ordering is relied upon for action processing. > > -rv > > Richard Vermillion > CTO & EVP, Fulcrum > rvermillion@fulcrm.com > http://www.fulcrm.com/ > > > > Cc: From: Richard Vermillion Subject: Re: Operation::ownedParameter should be ordered in XMI? Date: Mon, 16 Jan 2006 02:11:42 -0500 To: "Pete Rivett" X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: Symantec AntiVirus Scan Engine Apologies for the uml-rtf e-mail. I think I was the victim of a spurious auto-complete in my mail program. Pete, after I sent the e-mail I noticed what you mention below, namely that the Operations diagrams in the specifications do not show {ordered} on the ownedParameter end of the association. So it's not just an XMI issue, but a spec issue as well. Since it appears to be an explicit redefinition (rather than a merge- induced one) I would ask whether it's truly necessary. It is defined both in Core::Constructs::BehavioralFeature and in Core::Basic::Operation the same way, namely as an ordered, unique, composite collection of Parameter elements. Is the property required in Core::Constructs::Operation, or is it simply a left-over from the whole formalParameter, returnResult mess that was cleared up in previous ballots? If it is necessary, it would be helpful to understand why (and it would be nice to make it ordered as well). If not, getting rid of it would seem the right thing to do. Thanks for responding so quickly, -rv Richard Vermillion CTO & EVP, Fulcrum rvermillion@fulcrm.com http://www.fulcrm.com/ On Jan 15, 2006, at 10:03 PM, Pete Rivett wrote: ----------------------------------------- (on mx01.fulcrumanalytics.com) email-body was scanned and no virus found --------------------------------------------------------- (Richard you should email uml2-rtf@omg.org not uml-rtf) Well spotted - though this is a problem in the spec not in the XMI alone. See below. Pete -----Original Message----- From: Richard Vermillion [mailto:rvermillion@fulcrumanalytics.com] Sent: Monday, January 16, 2006 12:42 AM To: uml-rtf@omg.org Subject: Operation::ownedParameter should be ordered in XMI? In the latest XMI file (included as part of Ballot 12) the ownedParameter attribute of Core::Constructs::Operation redefines Core::Constructs::BehavioralFeature::ownedParameter -- I'm assuming that this redefinition is a result of the merge of Basic. No I don't think so: it's ordered in Basic also. The redefinition is semi-explicit - i.e. it appears in Fig 66 (of ptc/04-10-14)(there is no explicit {redefines}) nor is it mentioned in the Associations section of Operation. But in both Infrastructure and Superstructure there is no {ordered} on the redefinign property. So the XMI is consistent with the spec (though elsewhere in the spec e.g. semantics of CallAction it states that "Parameters on behaviors and operations are totally ordered lists." and in fact the orderign is required to match to pins. This mistake originates from the Adopted specifiaction - though this part of the spec was changed by Issue 7344, {ordered} was not there in the original either. However, in Operation, the ownedParameter attribute is not ordered. Since both BehavioralFeature::ownedParameter and Core::Basic::Operation::ownedParameter are ordered, it seems strange for Core::Constructs::Operation's not to be ordered. A check of the drafts and ballots does not seem to address this issue or explain why it would be the case. Is it a mistake? Yes it is clearly a mistake - well spotted. Unfortunate since, as I say above, the ordering is relied upon for action processing. -rv Richard Vermillion CTO & EVP, Fulcrum rvermillion@fulcrm.com http://www.fulcrm.com/ smime11.p7s