Issue 6404: UML 2 Super / Package Templates / StringExpression inconsistency (uml2-superstructure-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: The text for NamedElement (as specialized) on page 560 refers to a "string expression" type. Figure 438, however, only shows the type Expression. (Furthermore, the reference Rose metamodel does include a StringExpression type, indicating that the metamodel in figure 438 may be incorrect.) This inconsistency needs to be resolved. Resolution: see above Revised Text: Actions taken: October 31, 2003: received issue March 8, 2005: closed issue Discussion: The diagram in figure 438 is incorrect and does not match the text. The correct diagram is shown below. In addition, the definition of the new metaclass StringExpression has been omitted as well as the increment to ValueExpression. The following changes are required to correct these problems. ?? Replace the diagram in figure 438 on page 560, with the following diagram: ValueSpecification ParameterableElement (from TemplatesCommon) Expression (from Kernel) NamedElement StringExpression 0..* 0..1 +subExpression {ordered, subsets ownedElement} 0..1 0..1 +nameExpression {subsets ownedElement} ?? Remove constraint [1] of NamedElement on page 560 because the effect is obtained by using the explicit metaclass StringExpression. ?? Remove constraint [2] of NamedElement since it contradicts the text in the Semantics section, which states that an element can have both the name and the nameExpression ?? Add the following two new metaclass descriptions after figure 439 on page 562: 17.5.12 StringExpression An expression that specifies a string value that is derived by concatenating a set of sub-string expressions, some of which might be template parameters. Description StringExpression is a specialization of the general Expression metaclass which adds the ability to contain sub-expressions and whose operands are exclusively LiteralStrings. Attributes No additional attributes. Associations o subExpression : StringExpression[0..*] The StringExpressions that constitute this StringExp ression. Subsets Element::ownedElement. Constraints [1] All the operands of a StringExpression must be LiteralStrings operand->forAll (op | op.oclIsKindOf (LiteralString)) [2] If a StringExpression has sub-expressions, it cannot have operands and vice versa (this avoids the problem of having to define a collating sequence between operands and subexpressions). if subExpression->notEmpty() then operand->isEmpty() else operand->notEmpty() Additional Operations [1] The query stringValue() returns the string that concatenates, in order, all the component string literals of all the subexpressions that are part of the StringExpression. StringExpression::stringValue() : String; if subExpression->notEmpty() then subExpression->iterate(se; stringValue = ‘’| stringValue.concat(se.stringValue())) else operand->iterate()(op; stringValue = ‘’ | stringValue.concat(op.value)) Semantics A StringExpression is a composite expression whose elements are either nested StringExpressions or LiteralStrings. The string value of the expression is obtained by concatenating the respective string values of all the subexpressions in order. If the expression has no subexpressions, the string value is obtained by concatenating the LiteralStrings that are the operands of the StringExpression in order. Notation See the notation section of NamedElement on page EDITOR. Examples See figure 439 on page EDITOR. 17.5.13 ValueSpecification (as specialized) Description StringExpression is a specialization of the general Expression metaclass which adds the ability to contain sub-expressions and whose operands are exclusively LiteralStrings. Attributes No additional attributes. Associations No additional associations. Constraints No additional constraints. Semantics This adds the capability for ValueExpressions to act as template parameters. Disposition: Resolved End of Annotations:===== ubject: UML 2 Super / Package Templates / StringExpression inconsistency X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 31 Oct 2003 20:41:51 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 10/31/2003 20:41:54, Serialize complete at 10/31/2003 20:41:54 The text for NamedElement (as specialized) on page 560 refers to a "string expression" type. Figure 438, however, only shows the type Expression. (Furthermore, the reference Rose metamodel does include a StringExpression type, indicating that the metamodel in figure 438 may be incorrect.) This inconsistency needs to be resolved. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com OMG Issue No: 6404 Title: UML 2 Super / Package Templates / StringExpression inconsistency Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: The text for NamedElement (as specialized) on page 560 refers to a "string expression" type. Figure 438, however, only shows the type Expression. (Furthermore, the reference Rose metamodel does include a StringExpression type, indicating that the metamodel in figure 438 may be incorrect.) This inconsistency needs to be resolved. Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} To: uml2-superstructure-ftf@omg.org Subject: Package Templates: support for string expressions X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 11 Aug 2004 18:34:04 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/11/2004 18:34:06 The following document contains a resolution that fixes the problem with spring parameters in PackageTemplates (it was badly broken -- the text did not match the diagrams). Note that the "official" metamodel is completely broken in the Templates area and will need to be fixed so that it matches what is stated in the document. I will make that fix as part of implementing this resolution. If there are no objections to this resolution, I will post it in ballot 23 (this Friday). Regards, Bran OMG Issue No.6404.040811.doc OMG Issue No: 6404 Title: UML 2 Super / Package Templates / StringExpression inconsistency Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: The text for NamedElement (as specialized) on page 560 refers to a "string expression" type. Figure 438, however, only shows the type Expression. (Furthermore, the reference Rose metamodel does include a StringExpression type, indicating that the metamodel in figure 438 may be incorrect.) This inconsistency needs to be resolved. Discussion: The diagram in figure 438 is incorrect and does not match the text. The correct diagram is shown below. In addition, the definition of the new metaclass StringExpression has been omitted as well as the increment to ValueExpression. The following changes are required to correct these problems. · Replace the diagram in figure 438 on page 560, with the following diagram: · Remove constraint [1] of NamedElement on page 560 because the effect is obtained by using the explicit metaclass StringExpression. · Remove constraint [2] of NamedElement since it contradicts the text in the Semantics section, which states that an element can have both the name and the nameExpression · Add the following two new metaclass descriptions after figure 439 on page 562: 17.5.12 StringExpression An expression that specifies a string value that is derived by concatenating a set of sub-string expressions, some of which might be template parameters. Description StringExpression is a specialization of the general Expression metaclass which adds the ability to contain sub-expressions and whose operands are exclusively LiteralStrings. Attributes No additional attributes. Associations o subExpression : StringExpression[0..*] The StringExpressions that constitute this StringExpression. Subsets Element::ownedElement. Constraints [1] All the operands of a StringExpression must be LiteralStrings operand->forAll (op | op.oclIsKindOf (LiteralString)) [2] If a StringExpression has sub-expressions, it cannot have operands and vice versa (this avoids the problem of having to define a collating sequence between operands and subexpressions). if subExpression->notEmpty() then operand->isEmpty() else operand->notEmpty() Additional Operations [1] The query stringValue() returns the string that concatenates, in order, all the component string literals of all the subexpressions that are part of the StringExpression. StringExpression::stringValue() : String; if subExpression->notEmpty() then subExpression->iterate(se; stringValue = ..| stringValue.concat(se.stringValue())) else operand->iterate()(op; stringValue = .. | stringValue.concat(op.value)) Semantics A StringExpression is a composite expression whose elements are either nested StringExpressions or LiteralStrings. The string value of the expression is obtained by concatenating the respective string values of all the subexpressions in order. If the expression has no subexpressions, the string value is obtained by concatenating the LiteralStrings that are the operands of the StringExpression in order. Notation See the notation section of NamedElement on page EDITOR. Examples See figure 439 on page EDITOR. 17.5.13 ValueSpecification (as specialized) Description StringExpression is a specialization of the general Expression metaclass which adds the ability to contain sub-expressions and whose operands are exclusively LiteralStrings. Attributes No additional attributes. Associations No additional associations. Constraints No additional constraints. Semantics This adds the capability for ValueExpressions to act as template parameters. Disposition: Resolved Subject: RE: Super FTF telecon on Wed. Aug. 18 Date: Tue, 17 Aug 2004 16:43:42 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Super FTF telecon on Wed. Aug. 18 Thread-Index: AcSEqTAaQMluTGe6QmefADO1NI9UZAAB1OVQ From: "Karl Frank" To: "Branislav Selic" Cc: , X-OriginalArrivalTime: 17 Aug 2004 23:43:43.0973 (UTC) FILETIME=[08329950:01C484B4] 1. 6212 It may be yet another defect if having a query named "isCoConsistentWith" is incompatible with queries of another name defined in another place "isConsistentWith()" . The prepended "co" is supposed to suggest "covariance" as opposed to "contra" in contravariance. Questions: -- argumentative in intent but meant in a collaborative way, my intent is to get a good spec out of this, not win arguments -- a) How can the "same" query be defined in more than one place?. You say "the query is defined in numerous places in the spec". The same query or queries of the same name? If the name is "isConsistentWith", how is that query inconsistent with one named "isCoConsistentWith" ? b) Isn't it a problem to have the word "consistent" used in a way contrary to its accepted meaning OUTSIDE the spec? For Operations, the definition as it stands in the spec is most certainly not what the words "is consistent with " mean. These words have a longer history by orders of magnitude than the few decades computers have been around. c) For us who are used to naming conventions, and have stomached using the word redefinition to include renaming, why is a made up word like "coconsistent" such a problem? 2. 6404 Given that a resolution to 6404 is in ballot 23, we should surely pull it from Ballot 24. You just sent me a list in which you listed 6405 as one of my remaining 10 issues and I screwed up by pulling 6404. Sorry.. 3. 6437. I always forget about Infra, since I am not on the Infra FTF. Will research the infra implications. 4. 6616 I specifically called Guus' attention to this already in the email you received, don't understand why you should suggest what I have already told you I did. Guus' views on the matter will get good attention, I am sure. But if he wants "isRoot" back (the issue does NOT say it is needed, nor does it give any argument for why it's loss is regrettable) he should explain why, because it is easier to leave it out. It is not in the FAS as approved, and no-one (including Guus) has so far given any complaint. 5. 7400. Yes, the terminology should be "Closed, no change". I had to create my own format for these, reliving the hell you have been thru often enough, because the styles and wording on the issues website do not match our report styles and wording, and I got this wrong. Will change it for the ballot. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 6:26 PM To: Karl Frank Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Super FTF telecon on Wed. Aug. 18 Karl, some feedback on your propsoed resolutions: 6212: I have two objections to your resolution: (1) I do not feel that renaming "isConsistentWith()" to "isCoConsistentWith()" improves anything as the concept of "co-consistency" is not a common and well-understood term in the computing science community and (2), that query is defined in numerous places in the spec and would have to be redefined everywhere. I would much prefer your second potential solution. 6404: I have already provided a resolution to this issue in ballot 23. (Also, I think that your resolution is incorrect.) 6437: shouldn't this also have an Infrastructure fix in it? 6630: We had this discussion already and I strongly object to your resolution. Specifically, I believe that a client of a dependency should be able to navigate to its dependencies (it is the client). The ramifications of your change are significant since Dependency is the parent class of Realization, Usage, and InterfaceRealization, which are extensively used in many models. Your resolution will impact many implementations adversely. 6616: I seem to recall that Guus felt rather strongly about this one. I suggest that you consult him about it directly. 7400: shouldn't this be a "closed, no change" rather than a "resolved"? Cheers, Bran "Karl Frank" 08/17/2004 03:53 PM To Branislav Selic/Ottawa/IBM@IBMCA, , cc Subject RE: Super FTF telecon on Wed. Aug. 18 Eight proposals are attached. One, 6630, met with counterarguments in an earlier circulation. I am still convinced my proposal is in the best interest of UML modeling, so I am sending it out again with a little more argument to back it up. The obvious easy resolution is self-evident, just x-out the navigability from Supplier, but before I fall back to that easy answer, I want to try out my preferred solution first. Guus, one of your issues is in this batch, so you should look for it. 6616, humorously but accurately named "isRoot disappeared". Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 3:20 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Super FTF telecon on Wed. Aug. 18 DATE: Wed. Aug. 18 TIME: 11 am EDT (usual time) DURATION: 35 minutes NUMBER: 866 842-3549 (toll free North America) 1+613 787-5018 (International) PASSCODE: 8455752# Please plan to attend this one, it is very important. Thanks...Bran[attachment "ForBallot24.doc" deleted by Branislav Selic/Ottawa/IBM] To: "Karl Frank" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Super FTF telecon on Wed. Aug. 18 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 17 Aug 2004 20:32:01 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/17/2004 20:32:02, Serialize complete at 08/17/2004 20:32:02 Karl, A few additional comments embedded below: > 1. 6212 It may be yet another defect if having a query named > "isCoConsistentWith" is incompatible with queries of another name > defined in another place "isConsistentWith()" . > The prepended "co" > is supposed to suggest "covariance" as opposed to "contra" in > contravariance. > Questions: -- argumentative in intent but meant in a collaborative > way, my intent is to get a good spec out of this, not win arguments -- > a) How can the "same" query be defined in more than one place?. You > say "the query is defined in numerous places in the spec". The same > query or queries of the same name? If the name is > "isConsistentWith", how is that query inconsistent with one named > "isCoConsistentWith" ? This was by intent. Since "consistency" has different meanings in different contexts and is also a semantic variation point, there is a default version (the one that you renamed) that was intended to be overridden by other more specific versions. So, a change in one place would require the thing to be changed in all the places. > b) Isn't it a problem to have the word "consistent" used in a way > contrary to its accepted meaning OUTSIDE the spec? For Operations, > the definition as it stands in the spec is most certainly not what > the words "is consistent with " mean. These words have a longer > history by orders of magnitude than the few decades computers have > been around. > c) For us who are used to naming conventions, and have stomached > using the word redefinition to include renaming, why is a made up > word like "coconsistent" such a problem? Perhaps you are used to it, but I am not and I honestly don't believe that most people would get any additional information out of it. In fact, I suspect that it will actually raise more questions. That is, while most people have an intuitive understanding of "consitent", I doubt if they have an intuition about what "co-consistent" could mean. > 2. 6404 Given that a resolution to 6404 is in ballot 23, we should > surely pull it from Ballot 24. You just sent me a list in which you > listed 6405 as one of my remaining 10 issues and I screwed up by > pulling 6404. Sorry.. No problem. > 3. 6437. I always forget about Infra, since I am not on the Infra > FTF. Will research the infra implications. OK > 4. 6616 I specifically called Guus' attention to this already in > the email you received, don't understand why you should suggest what > I have already told you I did. Guus' views on the matter will get > good attention, I am sure. But if he wants "isRoot" back (the issue > does NOT say it is needed, nor does it give any argument for why > it's loss is regrettable) he should explain why, because it is > easier to leave it out. It is not in the FAS as approved, and no- > one (including Guus) has so far given any complaint. Sorry. I now recall that you did draw Guus' attention to it. So, this is good. I agree with your proposed resolution, but wanted to make sure that it went into the ballot without being contested. > 5. 7400. Yes, the terminology should be "Closed, no change". I had > to create my own format for these, reliving the hell you have been > thru often enough, because the styles and wording on the issues > website do not match our report styles and wording, and I got this > wrong. Will change it for the ballot. No problem. You should be able to get the correct styles if you use the posted Draft FTF report. (And, you are right: I had to manually change the formatting of each and every paragraph of the 890 issues that are in that report.) Regards...Bran Disposition: Unresolved