Issue 15804: Big UML 2.4 problem: missing defaults in XMI (uml2-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Uncategorized Issue Severity: Summary: This came up in the MIWG testing (though that was for UML 2.2) There seem to be several cases where the specification has defaults that are not represented in the XMI. Examples of this are as follows: ActivityEdge::guard : ValueSpecification [1..1] = true ActivityEdge::weight : ValueSpecification [1..1] = 1 ObjectNode::upperBound : ValueSpecification [1..1] = * They all seem to be ValueSpecifications so I’m sure there are others. BTW these are all listed under Attributes of the metaclass whereas they are in fact modeled as Associations with ValueSpecification. So should they not be placed into the Associations section? Something to look at for 2.5 I guess. Resolution: Revised Text: Actions taken: November 1, 2010: received issue Discussion: End of Annotations:===== m: Steve Cook To: "issues@omg.org" CC: "ed-s@modeldriven.com" , Pete Rivett , "melaasar@ca.ibm.com" , "nicolas.f.rouquette@jpl.nasa.gov" Subject: RE: Big UML 2.4 problem: missing defaults in XMI Thread-Topic: Big UML 2.4 problem: missing defaults in XMI Thread-Index: Act52XfjxVZVzSdfSOGdF27vX/5YIwCMeybQ Date: Thu, 4 Nov 2010 10:31:46 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.70] Juergen Please log this as an issue against UML. From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 01 November 2010 15:29 To: Steve Cook; melaasar@ca.ibm.com; nicolas.f.rouquette@jpl.nasa.gov Cc: ed-s@modeldriven.com Subject: Big UML 2.4 problem: missing defaults in XMI Importance: High This came up in the MIWG testing (though that was for UML 2.2) There seem to be several cases where the specification has defaults that are not represented in the XMI. Examples of this are as follows: ActivityEdge::guard : ValueSpecification [1..1] = true ActivityEdge::weight : ValueSpecification [1..1] = 1 ObjectNode::upperBound : ValueSpecification [1..1] = * They all seem to be ValueSpecifications so I.m sure there are others. BTW these are all listed under Attributes of the metaclass whereas they are in fact modeled as Associations with ValueSpecification. So should they not be placed into the Associations section? Something to look at for 2.5 I guess. Pete -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp From: "Rouquette, Nicolas F (316A)" To: Pete Rivett CC: Steve Cook , Maged Elaasar , Ed Seidewitz , Juergen Boldt Date: Thu, 4 Nov 2010 13:49:05 -0700 Subject: Re: Big UML 2.4 problem: missing defaults in XMI Thread-Topic: Big UML 2.4 problem: missing defaults in XMI Thread-Index: Act8YbjzPTocndDYR3ymHxcQNs9F/g== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Hi, I strongly disagree with (2) Issue 15804 is a duplicate of issue 8450 from Pete: http://www.omg.org/issues/uml2-rtf.open.html#Issue8450 The real issue is that the current specification document is written in terms of conventions outside the scope of what is supported in clause 6.2. Another way of saying this is that the notation subclause in 7.3.45 Property does not explain how to convert the textual notation for a default value when the type of the property is not a datatype. In fact, the problem is much more fundamental than this because in current UML there is fundamentally no way to *designate* an element as a value for any purpose; instance specification, default value, instance value, ... http://www.omg.org/issues/uml2-rtf.open.html#Issue10821 For that matter, we don't even have a way to link element values: http://www.omg.org/issues/uml2-rtf.open.html#Issue9445 ... let alone construct collections of elements or navigate across links among elements: http://www.omg.org/issues/uml2-rtf.open.html#Issue9961 So, saying that the spec is correct and the metamodel is wrong is itself a lie. The metamodel can only represent what we know how to represent by construction or by convention. The real problem is that the document sometimes exceeds the limitations established in the conventions described in clause 6.2 - Nicolas. On Nov 4, 2010, at 11:44 AM, Pete Rivett wrote: I think so: Ed can confirm. Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, November 04, 2010 9:55 AM To: Pete Rivett; Maged Elaasar Cc: Ed Seidewitz; Rouquette, Nicolas F (316A) Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete Are you suggesting that we include a resolution to this issue in Ballot 11 with these words or similar, and that would be sufficient for the MIWG? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 04 November 2010 16:03 To: Maged Elaasar; Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A) Subject: RE: Big UML 2.4 problem: missing defaults in XMI Not so simple, folks . the reason this was raised in the first place was due to a real interchange problem. Even if we do nothing formally at UML 2.4 .we. need to give a clear statement - to MIWG amongst others - regarding serialization of these properties. And it seems to me desirable that the .we. needs to have more weight than an email from us 5. Options: 1) Tell people that the spec is wrong and the metamodel is correct in providing no defaults and that values should always be serialized 2) Tell people the spec is correct and the metamodel wrong and that the documented defaults should not be serialized. This I believe is the interim position taken by MIWG. 3) Tell people that the spec is correct but that we don.t have a way of including defaults for ValueSpecifications in the metamodel. In the same way as there is no default for multiplicities. Nonetheless the default weights etc must not be serialized. So my preference would be to include the wording from 3) as the response to the issue Steve just raised. For the future we need to consider how to serialize such default ValueSpecifications. I still disagree with Ed on this: while his approach is technically more .pure. what I advocate works and is more pragmatic. And is what tools are more likely to do anyway. It might not accord with fUML but since when is the fUML spec binding on the UML spec? Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, November 04, 2010 7:52 AM To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); Pete Rivett Subject: RE: Big UML 2.4 problem: missing defaults in XMI I agree to do nothing now, although I think we should not get bogged down initially in 2.5 by this or other MM changes in order to do a timely submission. In the FTF, we can entertain these changes assming they do not adversely impact compatibility. Maged Steve Cook Steve Cook 11/04/2010 06:32 AM To Ed Seidewitz , Pete Rivett - Adaptive cc Maged Elaasar/Ottawa/IBM@IBMCA, "Rouquette, Nicolas F (316A)" Subject RE: Big UML 2.4 problem: missing defaults in XMI From the silence I.m assuming we agreed to fix it in 2.5. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 November 2010 22:26 To: Pete Rivett - Adaptive Cc: Steve Cook; melaasar@ca.ibm.com; Rouquette, Nicolas F (316A) Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete . Well, ObjectNode::upperBound is a ValueSpecification for the same reason that Multiplicity::upperBound is a ValueSpecification . to allow for computed upper bounds, rather than having them fixed to values in the model. I suppose that is why weight is also a ValueSpecification, though I am hard pressed to come up with an example in which that is useful (perhaps in the context of a template??). But I wouldn.t change it without a thorough conversation with Conrad first! Indeed, I go with Steve.s most recent option: Do nothing now (except maybe submit an issue), leave the spec inconsistent with the metamodel (as it is in a number of other places) and figure out the right thing to do as part of UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Monday, November 01, 2010 5:48 PM To: Rouquette, Nicolas F (316A); Ed Seidewitz Cc: Steve Cook; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Your option 2 also requires MOF to be changed to permit default values for Properties typed by Classes. The complexity of what to do with the instances explains the original reason for this J. I.m not sure Ed.s proposed use of InstanceSpecification is right either: see email just sent. A 3rd option is as per Steve.s suggestion: For weight, why is it not simply defined as an Integer? For upperBound, why is it not simply defined as UnlimitedNatural? That at least would minimize the impact on existing models. And make joinSpec and guard optional. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, November 01, 2010 2:04 PM To: Ed Seidewitz Cc: Steve Cook; melaasar@ca.ibm.com; Pete Rivett Subject: Re: Big UML 2.4 problem: missing defaults in XMI Why agonize over this? Objectively, we have 2 choices: option1: - leave the 2.4 metamodel as-is without the defaults - remove the defaults from the spec document which still requires an issue/resolution for ballot 11 - this will break compatibility with 2.3 models that don't have the default values serialized option2: - add default values in the 2.4 metamodel as Ed suggested (i.e., via an instance value that refers to an instance spec for a literal integer/string as appropriate) - this requires yet one more issue/resolution for ballot 11 to fix the metamodel - this should provide compatibility with 2.3 models that don't have the default values serialized Objectively speaking, I prefer option 2. - Nicolas. On Nov 1, 2010, at 1:21 PM, Ed Seidewitz wrote: Steve . No, all I was saying is that the usual rule of XMI serialization for UML is that when a property has its default value, it is not serialized. This is regardless of the multiplicity . when there is a default or a mandatory property, not serializing the value means that the property has the default value, not that it is empty. Your point about properties with class types not being allowed to have defaults in MOF is a different . and more salient . point. This seems to mean that the defaults as given in the spec are not allowed in any case (unless this is changing in MOF 2.4.). I am trying mightily to convince myself we do not have to resolve this in UML 2.4. However, having to serialize explicit weights and guards for every activity edge in an activity diagram, even though they are pointless in almost all cases, does not seem like a good solution to me. Presuming that the defaults are really not allowed by MOF, I think the only reasonable solution is to make these properties optional, with the semantics of the cases when they are empty being equivalent to what is currently given as the defaults. On the one hand, a change like this would seem to have to be made in UML 2.4. However, if we did it in UML 2.5, it would not actually invalidate any UML 2.4 models (since it would just weaken the multiplicity constraint), and would, in fact, be compatible with XMI generated by tools that assumed one should not serialized the previously specified default values for these properties. So maybe we can just handle it in UML 2.5.(please?) -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 2:33 PM To: Ed Seidewitz; Pete Rivett - Adaptive; Rouquette, Nicolas F (316A) Cc: melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Ed Really? But the multiplicity is [1..1]. You are saying that there are special rules for a [1..1] association when the metamodel has a default value. I don.t think so. Here.s a quote from the MOF spec: [8] Properties of type Class cannot have defaults. It doesn.t seem at all supportive of this approach. In the latest MIWG report Peter Denno says he.s .updated the metamodel the validator uses.. To what, I wonder? Are you arguing that we should fix this problem in 2.4? It seems to me that any tool, according to the current spec, is required to serialize an instance of ValueSpecification for all of these properties, because of the lower multiplicity. They.d be sensible to serialize instances that conform to the defaults specified in the text. What is wrong with that? -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 November 2010 18:19 To: Steve Cook; Pete Rivett - Adaptive; Rouquette, Nicolas F (316A) Cc: melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Steve . Even though I think the default value specification that Pete gave is wrong, the intent is correct. By giving a default value in the metamodel, it is then not necessary to serialize the weight if it is equal to the default. It is when the default is missing that the weight would need to always be serialized. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 2:13 PM To: Pete Rivett - Adaptive; Rouquette, Nicolas F (316A) Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Sorry, I had a meta-moment. Yes. And the effect of this would be to require every model, for every instance of ActivityEdge, to explicitly serialize a copy of that LiteralInteger for its weight. Do you really think that is the best solution? From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 01 November 2010 18:08 To: Steve Cook; Rouquette, Nicolas F (316A) Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI We have hundreds of instances of LiteralInteger . for all the non-default multiplicities. And even used for default values . for example Extension::lower. What I.d expect to see in the metamodel is, for example (with change in green): The minimum number of tokens that must traverse the edge at the same time. And I already stated how these defaults should be depicted on diagrams . by having the default assignment on the association end label (as Ed pointed out somehow I missed them on the existing Figures 12.11 and 12.14 . I was looking in attribute compartment). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 10:50 AM To: Pete Rivett; Rouquette, Nicolas F (316A) Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete What should the metamodel be? I don.t understand how to model this. We don.t have any instances of LiteralInteger, Expression, LiteralBoolean and so on in the metamodel. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 01 November 2010 17:46 To: Rouquette, Nicolas F (316A); Steve Cook Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI I.m puzzled: how would you fix the spec document . to remove these as defaults to match the metamodel? Seems the wrong way round to me. That will then have the danger of breaking model interchange if people have relied on the spec not the metamodel. In fact MIWG is likely to be fixing their Validator to match what the metamodel should be (i.e.to insert the defaults). Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, November 01, 2010 10:35 AM To: Steve Cook Cc: Ed Seidewitz; Pete Rivett; melaasar@ca.ibm.com Subject: Re: Big UML 2.4 problem: missing defaults in XMI The following defaults are not in the 2.4 metamodel (nor in 2.3 either) ActivityEdge::guard : ValueSpecification [1..1] = true ActivityEdge::weight : ValueSpecification [1..1] = 1 ObjectNode::upperBound : ValueSpecification [1..1] = * The only thing that needs fixing is the specification document, which is sensible to do in 2.5. - Nicolas. On Nov 1, 2010, at 9:31 AM, Steve Cook wrote: >Even though it would be a metamodel change, can we just fix this as part of UML 2.5, as part of resolving inconsistencies with the spec document? I would like to think so, because I have had quite enough of last-minute resolutions on 2.4. But as you know, metamodel changes are supposedly out of scope for 2.5. Pete, it seems that the correct way to represent a model in which these values have the default is actually unambiguous, given what the spec says, and Ed.s explanation of it, which I agree with. So what actually is the MIWG problem? From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 November 2010 16:25 To: Steve Cook Cc: Pete Rivett - Adaptive; melaasar@ca.ibm.com; nicolas.f.rouquette@jpl.nasa.gov Subject: RE: Big UML 2.4 problem: missing defaults in XMI Steve . These are all really supposed to be value specifications. The idea is that they can all be specified as expressions in the model, to be evaluated at .run time., rather than just being model-time constants. Also, a guard is not a constraint . it does not have to be true for a model to be valid; indeed, the whole point of a guard is to gate the flow of tokens based on whether it is true or false. So, when the default is given as, e.g., .true. for a guard, I believe what is really meant is that the default should be a LiteralBoolean (which is a kind of ValueSpecification) with the value .true.. Similarly, the default for weight should be a LiteralInteger, and the default for upperBound should be a LiteralUnlimitedNatural. The case of joinSpec is a bit more difficult. This is really supposed to be an operator of some sort, though exactly how this is supposed to be formalized in a ValueSpecification is not very clear. I think the best way to represent the default is as an Expression (also a kind of ValueSpecification) symbol=.and. and no operands. Even though it would be a metamodel change, can we just fix this as part of UML 2.5, as part of resolving inconsistencies with the spec document? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 11:52 AM To: Pete Rivett - Adaptive; melaasar@ca.ibm.com; nicolas.f.rouquette@jpl.nasa.gov Cc: Ed Seidewitz Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete True, 1 and * are not instances of ValueSpecification. The way that this kind of thing is handled in Multiplicity is to derive the .default values. through operations: MultiplicityElement::lowerBound() : [Integer]; lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif But in that case the ValueSpecification can be empty, the emptiness implies the default value, and there are strongly-typed derived attributes that specify what the value should actually be. For guard, I suppose the ValueSpecification is actually supposed to be a Constraint. For weight, why is it not simply defined as an Integer? For upperBound, why is it not simply defined as UnlimitedNatural? I also found joinSpec : ValueSpecification [1..1] with default .and.. Here I would go for String. Is this a show-stopper for 2.4? Do we have to create another resolution for these? If we did go for another resolution, I would say make them all [0..1], create derived attributes /guardValue: Boolean, /weightValue: Integer, /upper : UnlimitedNatural and /joinSpecValue : String, and use the same pattern to give them .defaults. via operations. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 01 November 2010 15:29 To: Steve Cook; melaasar@ca.ibm.com; nicolas.f.rouquette@jpl.nasa.gov Cc: ed-s@modeldriven.com Subject: Big UML 2.4 problem: missing defaults in XMI Importance: High This came up in the MIWG testing (though that was for UML 2.2) There seem to be several cases where the specification has defaults that are not represented in the XMI. Examples of this are as follows: ActivityEdge::guard : ValueSpecification [1..1] = true ActivityEdge::weight : ValueSpecification [1..1] = 1 ObjectNode::upperBound : ValueSpecification [1..1] = * They all seem to be ValueSpecifications so I.m sure there are others. BTW these are all listed under Attributes of the metaclass whereas they are in fact modeled as Associations with ValueSpecification. So should they not be placed into the Associations section? Something to look at for 2.5 I guess. Pete -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp Subject: RE: Big UML 2.4 problem: missing defaults in XMI Date: Thu, 4 Nov 2010 17:00:27 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Big UML 2.4 problem: missing defaults in XMI Thread-Index: Act8YbjzPTocndDYR3ymHxcQNs9F/gAASlWg From: "Ed Seidewitz" To: "Rouquette, Nicolas F (316A)" , "Pete Rivett - Adaptive" Cc: "Steve Cook" , "Maged Elaasar" , "Juergen Boldt" Actually, I agree that we shouldn.t tell people that .the spec is correct and the metamodel is wrong. on this, as such. In reality, the spec is wrong (since it calls for defaults in a metamodel that are not allowed in MOF) and the metamodel does not express what was intended (since it calls for the properties to be serialized in a large number of cases that was not intended). My position is just that the MIWG adopt the convention that the defaults called for in the spec are not to be serialized (effectively acting as if the spec was correct, because that is what was intended) and then make both the spec and the metamodel both correct and as intended in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, November 04, 2010 4:49 PM To: Pete Rivett - Adaptive Cc: Steve Cook; Maged Elaasar; Ed Seidewitz; Juergen Boldt Subject: Re: Big UML 2.4 problem: missing defaults in XMI Hi, I strongly disagree with (2) Issue 15804 is a duplicate of issue 8450 from Pete: http://www.omg.org/issues/uml2-rtf.open.html#Issue8450 The real issue is that the current specification document is written in terms of conventions outside the scope of what is supported in clause 6.2. Another way of saying this is that the notation subclause in 7.3.45 Property does not explain how to convert the textual notation for a default value when the type of the property is not a datatype. In fact, the problem is much more fundamental than this because in current UML there is fundamentally no way to *designate* an element as a value for any purpose; instance specification, default value, instance value, ... http://www.omg.org/issues/uml2-rtf.open.html#Issue10821 For that matter, we don't even have a way to link element values: http://www.omg.org/issues/uml2-rtf.open.html#Issue9445 ... let alone construct collections of elements or navigate across links among elements: http://www.omg.org/issues/uml2-rtf.open.html#Issue9961 So, saying that the spec is correct and the metamodel is wrong is itself a lie. The metamodel can only represent what we know how to represent by construction or by convention. The real problem is that the document sometimes exceeds the limitations established in the conventions described in clause 6.2 - Nicolas. On Nov 4, 2010, at 11:44 AM, Pete Rivett wrote: I think so: Ed can confirm. Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, November 04, 2010 9:55 AM To: Pete Rivett; Maged Elaasar Cc: Ed Seidewitz; Rouquette, Nicolas F (316A) Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete Are you suggesting that we include a resolution to this issue in Ballot 11 with these words or similar, and that would be sufficient for the MIWG? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 04 November 2010 16:03 To: Maged Elaasar; Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A) Subject: RE: Big UML 2.4 problem: missing defaults in XMI Not so simple, folks . the reason this was raised in the first place was due to a real interchange problem. Even if we do nothing formally at UML 2.4 .we. need to give a clear statement - to MIWG amongst others - regarding serialization of these properties. And it seems to me desirable that the .we. needs to have more weight than an email from us 5. Options: 1) Tell people that the spec is wrong and the metamodel is correct in providing no defaults and that values should always be serialized 2) Tell people the spec is correct and the metamodel wrong and that the documented defaults should not be serialized. This I believe is the interim position taken by MIWG. 3) Tell people that the spec is correct but that we don.t have a way of including defaults for ValueSpecifications in the metamodel. In the same way as there is no default for multiplicities. Nonetheless the default weights etc must not be serialized. So my preference would be to include the wording from 3) as the response to the issue Steve just raised. For the future we need to consider how to serialize such default ValueSpecifications. I still disagree with Ed on this: while his approach is technically more .pure. what I advocate works and is more pragmatic. And is what tools are more likely to do anyway. It might not accord with fUML but since when is the fUML spec binding on the UML spec? Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, November 04, 2010 7:52 AM To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); Pete Rivett Subject: RE: Big UML 2.4 problem: missing defaults in XMI I agree to do nothing now, although I think we should not get bogged down initially in 2.5 by this or other MM changes in order to do a timely submission. In the FTF, we can entertain these changes assming they do not adversely impact compatibility. Maged Steve Cook Steve Cook 11/04/2010 06:32 AM To Ed Seidewitz , Pete Rivett - Adaptive cc Maged Elaasar/Ottawa/IBM@IBMCA, "Rouquette, Nicolas F (316A)" Subject RE: Big UML 2.4 problem: missing defaults in XMI From the silence I.m assuming we agreed to fix it in 2.5. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 November 2010 22:26 To: Pete Rivett - Adaptive Cc: Steve Cook; melaasar@ca.ibm.com; Rouquette, Nicolas F (316A) Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete . Well, ObjectNode::upperBound is a ValueSpecification for the same reason that Multiplicity::upperBound is a ValueSpecification . to allow for computed upper bounds, rather than having them fixed to values in the model. I suppose that is why weight is also a ValueSpecification, though I am hard pressed to come up with an example in which that is useful (perhaps in the context of a template??). But I wouldn.t change it without a thorough conversation with Conrad first! Indeed, I go with Steve.s most recent option: Do nothing now (except maybe submit an issue), leave the spec inconsistent with the metamodel (as it is in a number of other places) and figure out the right thing to do as part of UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Monday, November 01, 2010 5:48 PM To: Rouquette, Nicolas F (316A); Ed Seidewitz Cc: Steve Cook; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Your option 2 also requires MOF to be changed to permit default values for Properties typed by Classes. The complexity of what to do with the instances explains the original reason for this J. I.m not sure Ed.s proposed use of InstanceSpecification is right either: see email just sent. A 3rd option is as per Steve.s suggestion: For weight, why is it not simply defined as an Integer? For upperBound, why is it not simply defined as UnlimitedNatural? That at least would minimize the impact on existing models. And make joinSpec and guard optional. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, November 01, 2010 2:04 PM To: Ed Seidewitz Cc: Steve Cook; melaasar@ca.ibm.com; Pete Rivett Subject: Re: Big UML 2.4 problem: missing defaults in XMI Why agonize over this? Objectively, we have 2 choices: option1: - leave the 2.4 metamodel as-is without the defaults - remove the defaults from the spec document which still requires an issue/resolution for ballot 11 - this will break compatibility with 2.3 models that don't have the default values serialized option2: - add default values in the 2.4 metamodel as Ed suggested (i.e., via an instance value that refers to an instance spec for a literal integer/string as appropriate) - this requires yet one more issue/resolution for ballot 11 to fix the metamodel - this should provide compatibility with 2.3 models that don't have the default values serialized Objectively speaking, I prefer option 2. - Nicolas. On Nov 1, 2010, at 1:21 PM, Ed Seidewitz wrote: Steve . No, all I was saying is that the usual rule of XMI serialization for UML is that when a property has its default value, it is not serialized. This is regardless of the multiplicity . when there is a default or a mandatory property, not serializing the value means that the property has the default value, not that it is empty. Your point about properties with class types not being allowed to have defaults in MOF is a different . and more salient . point. This seems to mean that the defaults as given in the spec are not allowed in any case (unless this is changing in MOF 2.4.). I am trying mightily to convince myself we do not have to resolve this in UML 2.4. However, having to serialize explicit weights and guards for every activity edge in an activity diagram, even though they are pointless in almost all cases, does not seem like a good solution to me. Presuming that the defaults are really not allowed by MOF, I think the only reasonable solution is to make these properties optional, with the semantics of the cases when they are empty being equivalent to what is currently given as the defaults. On the one hand, a change like this would seem to have to be made in UML 2.4. However, if we did it in UML 2.5, it would not actually invalidate any UML 2.4 models (since it would just weaken the multiplicity constraint), and would, in fact, be compatible with XMI generated by tools that assumed one should not serialized the previously specified default values for these properties. So maybe we can just handle it in UML 2.5.(please?) -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 2:33 PM To: Ed Seidewitz; Pete Rivett - Adaptive; Rouquette, Nicolas F (316A) Cc: melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Ed Really? But the multiplicity is [1..1]. You are saying that there are special rules for a [1..1] association when the metamodel has a default value. I don.t think so. Here.s a quote from the MOF spec: [8] Properties of type Class cannot have defaults. It doesn.t seem at all supportive of this approach. In the latest MIWG report Peter Denno says he.s .updated the metamodel the validator uses.. To what, I wonder? Are you arguing that we should fix this problem in 2.4? It seems to me that any tool, according to the current spec, is required to serialize an instance of ValueSpecification for all of these properties, because of the lower multiplicity. They.d be sensible to serialize instances that conform to the defaults specified in the text. What is wrong with that? -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 November 2010 18:19 To: Steve Cook; Pete Rivett - Adaptive; Rouquette, Nicolas F (316A) Cc: melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Steve . Even though I think the default value specification that Pete gave is wrong, the intent is correct. By giving a default value in the metamodel, it is then not necessary to serialize the weight if it is equal to the default. It is when the default is missing that the weight would need to always be serialized. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 2:13 PM To: Pete Rivett - Adaptive; Rouquette, Nicolas F (316A) Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Sorry, I had a meta-moment. Yes. And the effect of this would be to require every model, for every instance of ActivityEdge, to explicitly serialize a copy of that LiteralInteger for its weight. Do you really think that is the best solution? From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 01 November 2010 18:08 To: Steve Cook; Rouquette, Nicolas F (316A) Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI We have hundreds of instances of LiteralInteger . for all the non-default multiplicities. And even used for default values . for example Extension::lower. What I.d expect to see in the metamodel is, for example (with change in green): The minimum number of tokens that must traverse the edge at the same time. And I already stated how these defaults should be depicted on diagrams . by having the default assignment on the association end label (as Ed pointed out somehow I missed them on the existing Figures 12.11 and 12.14 . I was looking in attribute compartment). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 10:50 AM To: Pete Rivett; Rouquette, Nicolas F (316A) Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete What should the metamodel be? I don.t understand how to model this. We don.t have any instances of LiteralInteger, Expression, LiteralBoolean and so on in the metamodel. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 01 November 2010 17:46 To: Rouquette, Nicolas F (316A); Steve Cook Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI I.m puzzled: how would you fix the spec document . to remove these as defaults to match the metamodel? Seems the wrong way round to me. That will then have the danger of breaking model interchange if people have relied on the spec not the metamodel. In fact MIWG is likely to be fixing their Validator to match what the metamodel should be (i.e.to insert the defaults). Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, November 01, 2010 10:35 AM To: Steve Cook Cc: Ed Seidewitz; Pete Rivett; melaasar@ca.ibm.com Subject: Re: Big UML 2.4 problem: missing defaults in XMI The following defaults are not in the 2.4 metamodel (nor in 2.3 either) ActivityEdge::guard : ValueSpecification [1..1] = true ActivityEdge::weight : ValueSpecification [1..1] = 1 ObjectNode::upperBound : ValueSpecification [1..1] = * The only thing that needs fixing is the specification document, which is sensible to do in 2.5. - Nicolas. On Nov 1, 2010, at 9:31 AM, Steve Cook wrote: >Even though it would be a metamodel change, can we just fix this as part of UML 2.5, as part of resolving inconsistencies with the spec document? I would like to think so, because I have had quite enough of last-minute resolutions on 2.4. But as you know, metamodel changes are supposedly out of scope for 2.5. Pete, it seems that the correct way to represent a model in which these values have the default is actually unambiguous, given what the spec says, and Ed.s explanation of it, which I agree with. So what actually is the MIWG problem? From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 November 2010 16:25 To: Steve Cook Cc: Pete Rivett - Adaptive; melaasar@ca.ibm.com; nicolas.f.rouquette@jpl.nasa.gov Subject: RE: Big UML 2.4 problem: missing defaults in XMI Steve . These are all really supposed to be value specifications. The idea is that they can all be specified as expressions in the model, to be evaluated at .run time., rather than just being model-time constants. Also, a guard is not a constraint . it does not have to be true for a model to be valid; indeed, the whole point of a guard is to gate the flow of tokens based on whether it is true or false. So, when the default is given as, e.g., .true. for a guard, I believe what is really meant is that the default should be a LiteralBoolean (which is a kind of ValueSpecification) with the value .true.. Similarly, the default for weight should be a LiteralInteger, and the default for upperBound should be a LiteralUnlimitedNatural. The case of joinSpec is a bit more difficult. This is really supposed to be an operator of some sort, though exactly how this is supposed to be formalized in a ValueSpecification is not very clear. I think the best way to represent the default is as an Expression (also a kind of ValueSpecification) symbol=.and. and no operands. Even though it would be a metamodel change, can we just fix this as part of UML 2.5, as part of resolving inconsistencies with the spec document? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 11:52 AM To: Pete Rivett - Adaptive; melaasar@ca.ibm.com; nicolas.f.rouquette@jpl.nasa.gov Cc: Ed Seidewitz Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete True, 1 and * are not instances of ValueSpecification. The way that this kind of thing is handled in Multiplicity is to derive the .default values. through operations: MultiplicityElement::lowerBound() : [Integer]; lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif But in that case the ValueSpecification can be empty, the emptiness implies the default value, and there are strongly-typed derived attributes that specify what the value should actually be. For guard, I suppose the ValueSpecification is actually supposed to be a Constraint. For weight, why is it not simply defined as an Integer? For upperBound, why is it not simply defined as UnlimitedNatural? I also found joinSpec : ValueSpecification [1..1] with default .and.. Here I would go for String. Is this a show-stopper for 2.4? Do we have to create another resolution for these? If we did go for another resolution, I would say make them all [0..1], create derived attributes /guardValue: Boolean, /weightValue: Integer, /upper : UnlimitedNatural and /joinSpecValue : String, and use the same pattern to give them .defaults. via operations. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 01 November 2010 15:29 To: Steve Cook; melaasar@ca.ibm.com; nicolas.f.rouquette@jpl.nasa.gov Cc: ed-s@modeldriven.com Subject: Big UML 2.4 problem: missing defaults in XMI Importance: High This came up in the MIWG testing (though that was for UML 2.2) There seem to be several cases where the specification has defaults that are not represented in the XMI. Examples of this are as follows: ActivityEdge::guard : ValueSpecification [1..1] = true ActivityEdge::weight : ValueSpecification [1..1] = 1 ObjectNode::upperBound : ValueSpecification [1..1] = * They all seem to be ValueSpecifications so I.m sure there are others. BTW these are all listed under Attributes of the metaclass whereas they are in fact modeled as Associations with ValueSpecification. So should they not be placed into the Associations section? Something to look at for 2.5 I guess. Pete -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp Subject: RE: Big UML 2.4 problem: missing defaults in XMI Date: Thu, 4 Nov 2010 14:34:41 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Big UML 2.4 problem: missing defaults in XMI Thread-Index: Act8YbjzPTocndDYR3ymHxcQNs9F/gAASlWgAAEsD4A= From: "Pete Rivett" To: "Ed Seidewitz" , "Rouquette, Nicolas F (316A)" Cc: "Steve Cook" , "Maged Elaasar" , "Juergen Boldt" I was proposing option 3) not option 2), to quote . So my preference would be to include the wording from 3) as the response to the issue Steve just raised.. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, November 04, 2010 2:00 PM To: Rouquette, Nicolas F (316A); Pete Rivett Cc: Steve Cook; Maged Elaasar; Juergen Boldt Subject: RE: Big UML 2.4 problem: missing defaults in XMI Actually, I agree that we shouldn.t tell people that .the spec is correct and the metamodel is wrong. on this, as such. In reality, the spec is wrong (since it calls for defaults in a metamodel that are not allowed in MOF) and the metamodel does not express what was intended (since it calls for the properties to be serialized in a large number of cases that was not intended). My position is just that the MIWG adopt the convention that the defaults called for in the spec are not to be serialized (effectively acting as if the spec was correct, because that is what was intended) and then make both the spec and the metamodel both correct and as intended in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, November 04, 2010 4:49 PM To: Pete Rivett - Adaptive Cc: Steve Cook; Maged Elaasar; Ed Seidewitz; Juergen Boldt Subject: Re: Big UML 2.4 problem: missing defaults in XMI Hi, I strongly disagree with (2) Issue 15804 is a duplicate of issue 8450 from Pete: http://www.omg.org/issues/uml2-rtf.open.html#Issue8450 The real issue is that the current specification document is written in terms of conventions outside the scope of what is supported in clause 6.2. Another way of saying this is that the notation subclause in 7.3.45 Property does not explain how to convert the textual notation for a default value when the type of the property is not a datatype. In fact, the problem is much more fundamental than this because in current UML there is fundamentally no way to *designate* an element as a value for any purpose; instance specification, default value, instance value, ... http://www.omg.org/issues/uml2-rtf.open.html#Issue10821 For that matter, we don't even have a way to link element values: http://www.omg.org/issues/uml2-rtf.open.html#Issue9445 ... let alone construct collections of elements or navigate across links among elements: http://www.omg.org/issues/uml2-rtf.open.html#Issue9961 So, saying that the spec is correct and the metamodel is wrong is itself a lie. The metamodel can only represent what we know how to represent by construction or by convention. The real problem is that the document sometimes exceeds the limitations established in the conventions described in clause 6.2 - Nicolas. On Nov 4, 2010, at 11:44 AM, Pete Rivett wrote: I think so: Ed can confirm. Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, November 04, 2010 9:55 AM To: Pete Rivett; Maged Elaasar Cc: Ed Seidewitz; Rouquette, Nicolas F (316A) Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete Are you suggesting that we include a resolution to this issue in Ballot 11 with these words or similar, and that would be sufficient for the MIWG? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 04 November 2010 16:03 To: Maged Elaasar; Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A) Subject: RE: Big UML 2.4 problem: missing defaults in XMI Not so simple, folks . the reason this was raised in the first place was due to a real interchange problem. Even if we do nothing formally at UML 2.4 .we. need to give a clear statement - to MIWG amongst others - regarding serialization of these properties. And it seems to me desirable that the .we. needs to have more weight than an email from us 5. Options: 1) Tell people that the spec is wrong and the metamodel is correct in providing no defaults and that values should always be serialized 2) Tell people the spec is correct and the metamodel wrong and that the documented defaults should not be serialized. This I believe is the interim position taken by MIWG. 3) Tell people that the spec is correct but that we don.t have a way of including defaults for ValueSpecifications in the metamodel. In the same way as there is no default for multiplicities. Nonetheless the default weights etc must not be serialized. So my preference would be to include the wording from 3) as the response to the issue Steve just raised. For the future we need to consider how to serialize such default ValueSpecifications. I still disagree with Ed on this: while his approach is technically more .pure. what I advocate works and is more pragmatic. And is what tools are more likely to do anyway. It might not accord with fUML but since when is the fUML spec binding on the UML spec? Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, November 04, 2010 7:52 AM To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); Pete Rivett Subject: RE: Big UML 2.4 problem: missing defaults in XMI I agree to do nothing now, although I think we should not get bogged down initially in 2.5 by this or other MM changes in order to do a timely submission. In the FTF, we can entertain these changes assming they do not adversely impact compatibility. Maged Steve Cook Steve Cook 11/04/2010 06:32 AM To Ed Seidewitz , Pete Rivett - Adaptive cc Maged Elaasar/Ottawa/IBM@IBMCA, "Rouquette, Nicolas F (316A)" Subject RE: Big UML 2.4 problem: missing defaults in XMI From the silence I.m assuming we agreed to fix it in 2.5. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 November 2010 22:26 To: Pete Rivett - Adaptive Cc: Steve Cook; melaasar@ca.ibm.com; Rouquette, Nicolas F (316A) Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete . Well, ObjectNode::upperBound is a ValueSpecification for the same reason that Multiplicity::upperBound is a ValueSpecification . to allow for computed upper bounds, rather than having them fixed to values in the model. I suppose that is why weight is also a ValueSpecification, though I am hard pressed to come up with an example in which that is useful (perhaps in the context of a template??). But I wouldn.t change it without a thorough conversation with Conrad first! Indeed, I go with Steve.s most recent option: Do nothing now (except maybe submit an issue), leave the spec inconsistent with the metamodel (as it is in a number of other places) and figure out the right thing to do as part of UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Monday, November 01, 2010 5:48 PM To: Rouquette, Nicolas F (316A); Ed Seidewitz Cc: Steve Cook; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Your option 2 also requires MOF to be changed to permit default values for Properties typed by Classes. The complexity of what to do with the instances explains the original reason for this J. I.m not sure Ed.s proposed use of InstanceSpecification is right either: see email just sent. A 3rd option is as per Steve.s suggestion: For weight, why is it not simply defined as an Integer? For upperBound, why is it not simply defined as UnlimitedNatural? That at least would minimize the impact on existing models. And make joinSpec and guard optional. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, November 01, 2010 2:04 PM To: Ed Seidewitz Cc: Steve Cook; melaasar@ca.ibm.com; Pete Rivett Subject: Re: Big UML 2.4 problem: missing defaults in XMI Why agonize over this? Objectively, we have 2 choices: option1: - leave the 2.4 metamodel as-is without the defaults - remove the defaults from the spec document which still requires an issue/resolution for ballot 11 - this will break compatibility with 2.3 models that don't have the default values serialized option2: - add default values in the 2.4 metamodel as Ed suggested (i.e., via an instance value that refers to an instance spec for a literal integer/string as appropriate) - this requires yet one more issue/resolution for ballot 11 to fix the metamodel - this should provide compatibility with 2.3 models that don't have the default values serialized Objectively speaking, I prefer option 2. - Nicolas. On Nov 1, 2010, at 1:21 PM, Ed Seidewitz wrote: Steve . No, all I was saying is that the usual rule of XMI serialization for UML is that when a property has its default value, it is not serialized. This is regardless of the multiplicity . when there is a default or a mandatory property, not serializing the value means that the property has the default value, not that it is empty. Your point about properties with class types not being allowed to have defaults in MOF is a different . and more salient . point. This seems to mean that the defaults as given in the spec are not allowed in any case (unless this is changing in MOF 2.4.). I am trying mightily to convince myself we do not have to resolve this in UML 2.4. However, having to serialize explicit weights and guards for every activity edge in an activity diagram, even though they are pointless in almost all cases, does not seem like a good solution to me. Presuming that the defaults are really not allowed by MOF, I think the only reasonable solution is to make these properties optional, with the semantics of the cases when they are empty being equivalent to what is currently given as the defaults. On the one hand, a change like this would seem to have to be made in UML 2.4. However, if we did it in UML 2.5, it would not actually invalidate any UML 2.4 models (since it would just weaken the multiplicity constraint), and would, in fact, be compatible with XMI generated by tools that assumed one should not serialized the previously specified default values for these properties. So maybe we can just handle it in UML 2.5.(please?) -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 2:33 PM To: Ed Seidewitz; Pete Rivett - Adaptive; Rouquette, Nicolas F (316A) Cc: melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Ed Really? But the multiplicity is [1..1]. You are saying that there are special rules for a [1..1] association when the metamodel has a default value. I don.t think so. Here.s a quote from the MOF spec: [8] Properties of type Class cannot have defaults. It doesn.t seem at all supportive of this approach. In the latest MIWG report Peter Denno says he.s .updated the metamodel the validator uses.. To what, I wonder? Are you arguing that we should fix this problem in 2.4? It seems to me that any tool, according to the current spec, is required to serialize an instance of ValueSpecification for all of these properties, because of the lower multiplicity. They.d be sensible to serialize instances that conform to the defaults specified in the text. What is wrong with that? -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 November 2010 18:19 To: Steve Cook; Pete Rivett - Adaptive; Rouquette, Nicolas F (316A) Cc: melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Steve . Even though I think the default value specification that Pete gave is wrong, the intent is correct. By giving a default value in the metamodel, it is then not necessary to serialize the weight if it is equal to the default. It is when the default is missing that the weight would need to always be serialized. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 2:13 PM To: Pete Rivett - Adaptive; Rouquette, Nicolas F (316A) Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Sorry, I had a meta-moment. Yes. And the effect of this would be to require every model, for every instance of ActivityEdge, to explicitly serialize a copy of that LiteralInteger for its weight. Do you really think that is the best solution? From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 01 November 2010 18:08 To: Steve Cook; Rouquette, Nicolas F (316A) Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI We have hundreds of instances of LiteralInteger . for all the non-default multiplicities. And even used for default values . for example Extension::lower. What I.d expect to see in the metamodel is, for example (with change in green): The minimum number of tokens that must traverse the edge at the same time. And I already stated how these defaults should be depicted on diagrams . by having the default assignment on the association end label (as Ed pointed out somehow I missed them on the existing Figures 12.11 and 12.14 . I was looking in attribute compartment). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 10:50 AM To: Pete Rivett; Rouquette, Nicolas F (316A) Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete What should the metamodel be? I don.t understand how to model this. We don.t have any instances of LiteralInteger, Expression, LiteralBoolean and so on in the metamodel. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 01 November 2010 17:46 To: Rouquette, Nicolas F (316A); Steve Cook Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI I.m puzzled: how would you fix the spec document . to remove these as defaults to match the metamodel? Seems the wrong way round to me. That will then have the danger of breaking model interchange if people have relied on the spec not the metamodel. In fact MIWG is likely to be fixing their Validator to match what the metamodel should be (i.e.to insert the defaults). Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, November 01, 2010 10:35 AM To: Steve Cook Cc: Ed Seidewitz; Pete Rivett; melaasar@ca.ibm.com Subject: Re: Big UML 2.4 problem: missing defaults in XMI The following defaults are not in the 2.4 metamodel (nor in 2.3 either) ActivityEdge::guard : ValueSpecification [1..1] = true ActivityEdge::weight : ValueSpecification [1..1] = 1 ObjectNode::upperBound : ValueSpecification [1..1] = * The only thing that needs fixing is the specification document, which is sensible to do in 2.5. - Nicolas. On Nov 1, 2010, at 9:31 AM, Steve Cook wrote: >Even though it would be a metamodel change, can we just fix this as part of UML 2.5, as part of resolving inconsistencies with the spec document? I would like to think so, because I have had quite enough of last-minute resolutions on 2.4. But as you know, metamodel changes are supposedly out of scope for 2.5. Pete, it seems that the correct way to represent a model in which these values have the default is actually unambiguous, given what the spec says, and Ed.s explanation of it, which I agree with. So what actually is the MIWG problem? From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 November 2010 16:25 To: Steve Cook Cc: Pete Rivett - Adaptive; melaasar@ca.ibm.com; nicolas.f.rouquette@jpl.nasa.gov Subject: RE: Big UML 2.4 problem: missing defaults in XMI Steve . These are all really supposed to be value specifications. The idea is that they can all be specified as expressions in the model, to be evaluated at .run time., rather than just being model-time constants. Also, a guard is not a constraint . it does not have to be true for a model to be valid; indeed, the whole point of a guard is to gate the flow of tokens based on whether it is true or false. So, when the default is given as, e.g., .true. for a guard, I believe what is really meant is that the default should be a LiteralBoolean (which is a kind of ValueSpecification) with the value .true.. Similarly, the default for weight should be a LiteralInteger, and the default for upperBound should be a LiteralUnlimitedNatural. The case of joinSpec is a bit more difficult. This is really supposed to be an operator of some sort, though exactly how this is supposed to be formalized in a ValueSpecification is not very clear. I think the best way to represent the default is as an Expression (also a kind of ValueSpecification) symbol=.and. and no operands. Even though it would be a metamodel change, can we just fix this as part of UML 2.5, as part of resolving inconsistencies with the spec document? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 11:52 AM To: Pete Rivett - Adaptive; melaasar@ca.ibm.com; nicolas.f.rouquette@jpl.nasa.gov Cc: Ed Seidewitz Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete True, 1 and * are not instances of ValueSpecification. The way that this kind of thing is handled in Multiplicity is to derive the .default values. through operations: MultiplicityElement::lowerBound() : [Integer]; lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif But in that case the ValueSpecification can be empty, the emptiness implies the default value, and there are strongly-typed derived attributes that specify what the value should actually be. For guard, I suppose the ValueSpecification is actually supposed to be a Constraint. For weight, why is it not simply defined as an Integer? For upperBound, why is it not simply defined as UnlimitedNatural? I also found joinSpec : ValueSpecification [1..1] with default .and.. Here I would go for String. Is this a show-stopper for 2.4? Do we have to create another resolution for these? If we did go for another resolution, I would say make them all [0..1], create derived attributes /guardValue: Boolean, /weightValue: Integer, /upper : UnlimitedNatural and /joinSpecValue : String, and use the same pattern to give them .defaults. via operations. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 01 November 2010 15:29 To: Steve Cook; melaasar@ca.ibm.com; nicolas.f.rouquette@jpl.nasa.gov Cc: ed-s@modeldriven.com Subject: Big UML 2.4 problem: missing defaults in XMI Importance: High This came up in the MIWG testing (though that was for UML 2.2) There seem to be several cases where the specification has defaults that are not represented in the XMI. Examples of this are as follows: ActivityEdge::guard : ValueSpecification [1..1] = true ActivityEdge::weight : ValueSpecification [1..1] = 1 ObjectNode::upperBound : ValueSpecification [1..1] = * They all seem to be ValueSpecifications so I.m sure there are others. BTW these are all listed under Attributes of the metaclass whereas they are in fact modeled as Associations with ValueSpecification. So should they not be placed into the Associations section? Something to look at for 2.5 I guess. Pete -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp Subject: RE: Big UML 2.4 problem: missing defaults in XMI Date: Thu, 4 Nov 2010 17:41:37 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Big UML 2.4 problem: missing defaults in XMI Thread-Index: Act8YbjzPTocndDYR3ymHxcQNs9F/gAASlWgAAEsD4AAAFhokA== From: "Ed Seidewitz" To: "Pete Rivett - Adaptive" Cc: "Steve Cook" , "Maged Elaasar" , "Juergen Boldt" , "Rouquette, Nicolas F (316A)" Pete -- Actually, you are right, option 3 was pretty much what I was agreeing with, wasn.t I? J -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, November 04, 2010 5:35 PM To: Ed Seidewitz; Rouquette, Nicolas F (316A) Cc: Steve Cook; Maged Elaasar; Juergen Boldt Subject: RE: Big UML 2.4 problem: missing defaults in XMI I was proposing option 3) not option 2), to quote . So my preference would be to include the wording from 3) as the response to the issue Steve just raised.. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, November 04, 2010 2:00 PM To: Rouquette, Nicolas F (316A); Pete Rivett Cc: Steve Cook; Maged Elaasar; Juergen Boldt Subject: RE: Big UML 2.4 problem: missing defaults in XMI Actually, I agree that we shouldn.t tell people that .the spec is correct and the metamodel is wrong. on this, as such. In reality, the spec is wrong (since it calls for defaults in a metamodel that are not allowed in MOF) and the metamodel does not express what was intended (since it calls for the properties to be serialized in a large number of cases that was not intended). My position is just that the MIWG adopt the convention that the defaults called for in the spec are not to be serialized (effectively acting as if the spec was correct, because that is what was intended) and then make both the spec and the metamodel both correct and as intended in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, November 04, 2010 4:49 PM To: Pete Rivett - Adaptive Cc: Steve Cook; Maged Elaasar; Ed Seidewitz; Juergen Boldt Subject: Re: Big UML 2.4 problem: missing defaults in XMI Hi, I strongly disagree with (2) Issue 15804 is a duplicate of issue 8450 from Pete: http://www.omg.org/issues/uml2-rtf.open.html#Issue8450 The real issue is that the current specification document is written in terms of conventions outside the scope of what is supported in clause 6.2. Another way of saying this is that the notation subclause in 7.3.45 Property does not explain how to convert the textual notation for a default value when the type of the property is not a datatype. In fact, the problem is much more fundamental than this because in current UML there is fundamentally no way to *designate* an element as a value for any purpose; instance specification, default value, instance value, ... http://www.omg.org/issues/uml2-rtf.open.html#Issue10821 For that matter, we don't even have a way to link element values: http://www.omg.org/issues/uml2-rtf.open.html#Issue9445 ... let alone construct collections of elements or navigate across links among elements: http://www.omg.org/issues/uml2-rtf.open.html#Issue9961 So, saying that the spec is correct and the metamodel is wrong is itself a lie. The metamodel can only represent what we know how to represent by construction or by convention. The real problem is that the document sometimes exceeds the limitations established in the conventions described in clause 6.2 - Nicolas. On Nov 4, 2010, at 11:44 AM, Pete Rivett wrote: I think so: Ed can confirm. Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, November 04, 2010 9:55 AM To: Pete Rivett; Maged Elaasar Cc: Ed Seidewitz; Rouquette, Nicolas F (316A) Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete Are you suggesting that we include a resolution to this issue in Ballot 11 with these words or similar, and that would be sufficient for the MIWG? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 04 November 2010 16:03 To: Maged Elaasar; Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A) Subject: RE: Big UML 2.4 problem: missing defaults in XMI Not so simple, folks . the reason this was raised in the first place was due to a real interchange problem. Even if we do nothing formally at UML 2.4 .we. need to give a clear statement - to MIWG amongst others - regarding serialization of these properties. And it seems to me desirable that the .we. needs to have more weight than an email from us 5. Options: 1) Tell people that the spec is wrong and the metamodel is correct in providing no defaults and that values should always be serialized 2) Tell people the spec is correct and the metamodel wrong and that the documented defaults should not be serialized. This I believe is the interim position taken by MIWG. 3) Tell people that the spec is correct but that we don.t have a way of including defaults for ValueSpecifications in the metamodel. In the same way as there is no default for multiplicities. Nonetheless the default weights etc must not be serialized. So my preference would be to include the wording from 3) as the response to the issue Steve just raised. For the future we need to consider how to serialize such default ValueSpecifications. I still disagree with Ed on this: while his approach is technically more .pure. what I advocate works and is more pragmatic. And is what tools are more likely to do anyway. It might not accord with fUML but since when is the fUML spec binding on the UML spec? Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, November 04, 2010 7:52 AM To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); Pete Rivett Subject: RE: Big UML 2.4 problem: missing defaults in XMI I agree to do nothing now, although I think we should not get bogged down initially in 2.5 by this or other MM changes in order to do a timely submission. In the FTF, we can entertain these changes assming they do not adversely impact compatibility. Maged Steve Cook Steve Cook 11/04/2010 06:32 AM To Ed Seidewitz , Pete Rivett - Adaptive cc Maged Elaasar/Ottawa/IBM@IBMCA, "Rouquette, Nicolas F (316A)" Subject RE: Big UML 2.4 problem: missing defaults in XMI From the silence I.m assuming we agreed to fix it in 2.5. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 November 2010 22:26 To: Pete Rivett - Adaptive Cc: Steve Cook; melaasar@ca.ibm.com; Rouquette, Nicolas F (316A) Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete . Well, ObjectNode::upperBound is a ValueSpecification for the same reason that Multiplicity::upperBound is a ValueSpecification . to allow for computed upper bounds, rather than having them fixed to values in the model. I suppose that is why weight is also a ValueSpecification, though I am hard pressed to come up with an example in which that is useful (perhaps in the context of a template??). But I wouldn.t change it without a thorough conversation with Conrad first! Indeed, I go with Steve.s most recent option: Do nothing now (except maybe submit an issue), leave the spec inconsistent with the metamodel (as it is in a number of other places) and figure out the right thing to do as part of UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Monday, November 01, 2010 5:48 PM To: Rouquette, Nicolas F (316A); Ed Seidewitz Cc: Steve Cook; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Your option 2 also requires MOF to be changed to permit default values for Properties typed by Classes. The complexity of what to do with the instances explains the original reason for this J. I.m not sure Ed.s proposed use of InstanceSpecification is right either: see email just sent. A 3rd option is as per Steve.s suggestion: For weight, why is it not simply defined as an Integer? For upperBound, why is it not simply defined as UnlimitedNatural? That at least would minimize the impact on existing models. And make joinSpec and guard optional. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, November 01, 2010 2:04 PM To: Ed Seidewitz Cc: Steve Cook; melaasar@ca.ibm.com; Pete Rivett Subject: Re: Big UML 2.4 problem: missing defaults in XMI Why agonize over this? Objectively, we have 2 choices: option1: - leave the 2.4 metamodel as-is without the defaults - remove the defaults from the spec document which still requires an issue/resolution for ballot 11 - this will break compatibility with 2.3 models that don't have the default values serialized option2: - add default values in the 2.4 metamodel as Ed suggested (i.e., via an instance value that refers to an instance spec for a literal integer/string as appropriate) - this requires yet one more issue/resolution for ballot 11 to fix the metamodel - this should provide compatibility with 2.3 models that don't have the default values serialized Objectively speaking, I prefer option 2. - Nicolas. On Nov 1, 2010, at 1:21 PM, Ed Seidewitz wrote: Steve . No, all I was saying is that the usual rule of XMI serialization for UML is that when a property has its default value, it is not serialized. This is regardless of the multiplicity . when there is a default or a mandatory property, not serializing the value means that the property has the default value, not that it is empty. Your point about properties with class types not being allowed to have defaults in MOF is a different . and more salient . point. This seems to mean that the defaults as given in the spec are not allowed in any case (unless this is changing in MOF 2.4.). I am trying mightily to convince myself we do not have to resolve this in UML 2.4. However, having to serialize explicit weights and guards for every activity edge in an activity diagram, even though they are pointless in almost all cases, does not seem like a good solution to me. Presuming that the defaults are really not allowed by MOF, I think the only reasonable solution is to make these properties optional, with the semantics of the cases when they are empty being equivalent to what is currently given as the defaults. On the one hand, a change like this would seem to have to be made in UML 2.4. However, if we did it in UML 2.5, it would not actually invalidate any UML 2.4 models (since it would just weaken the multiplicity constraint), and would, in fact, be compatible with XMI generated by tools that assumed one should not serialized the previously specified default values for these properties. So maybe we can just handle it in UML 2.5.(please?) -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 2:33 PM To: Ed Seidewitz; Pete Rivett - Adaptive; Rouquette, Nicolas F (316A) Cc: melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Ed Really? But the multiplicity is [1..1]. You are saying that there are special rules for a [1..1] association when the metamodel has a default value. I don.t think so. Here.s a quote from the MOF spec: [8] Properties of type Class cannot have defaults. It doesn.t seem at all supportive of this approach. In the latest MIWG report Peter Denno says he.s .updated the metamodel the validator uses.. To what, I wonder? Are you arguing that we should fix this problem in 2.4? It seems to me that any tool, according to the current spec, is required to serialize an instance of ValueSpecification for all of these properties, because of the lower multiplicity. They.d be sensible to serialize instances that conform to the defaults specified in the text. What is wrong with that? -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 November 2010 18:19 To: Steve Cook; Pete Rivett - Adaptive; Rouquette, Nicolas F (316A) Cc: melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Steve . Even though I think the default value specification that Pete gave is wrong, the intent is correct. By giving a default value in the metamodel, it is then not necessary to serialize the weight if it is equal to the default. It is when the default is missing that the weight would need to always be serialized. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 2:13 PM To: Pete Rivett - Adaptive; Rouquette, Nicolas F (316A) Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Sorry, I had a meta-moment. Yes. And the effect of this would be to require every model, for every instance of ActivityEdge, to explicitly serialize a copy of that LiteralInteger for its weight. Do you really think that is the best solution? From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 01 November 2010 18:08 To: Steve Cook; Rouquette, Nicolas F (316A) Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI We have hundreds of instances of LiteralInteger . for all the non-default multiplicities. And even used for default values . for example Extension::lower. What I.d expect to see in the metamodel is, for example (with change in green): The minimum number of tokens that must traverse the edge at the same time. And I already stated how these defaults should be depicted on diagrams . by having the default assignment on the association end label (as Ed pointed out somehow I missed them on the existing Figures 12.11 and 12.14 . I was looking in attribute compartment). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 10:50 AM To: Pete Rivett; Rouquette, Nicolas F (316A) Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete What should the metamodel be? I don.t understand how to model this. We don.t have any instances of LiteralInteger, Expression, LiteralBoolean and so on in the metamodel. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 01 November 2010 17:46 To: Rouquette, Nicolas F (316A); Steve Cook Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI I.m puzzled: how would you fix the spec document . to remove these as defaults to match the metamodel? Seems the wrong way round to me. That will then have the danger of breaking model interchange if people have relied on the spec not the metamodel. In fact MIWG is likely to be fixing their Validator to match what the metamodel should be (i.e.to insert the defaults). Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, November 01, 2010 10:35 AM To: Steve Cook Cc: Ed Seidewitz; Pete Rivett; melaasar@ca.ibm.com Subject: Re: Big UML 2.4 problem: missing defaults in XMI The following defaults are not in the 2.4 metamodel (nor in 2.3 either) ActivityEdge::guard : ValueSpecification [1..1] = true ActivityEdge::weight : ValueSpecification [1..1] = 1 ObjectNode::upperBound : ValueSpecification [1..1] = * The only thing that needs fixing is the specification document, which is sensible to do in 2.5. - Nicolas. On Nov 1, 2010, at 9:31 AM, Steve Cook wrote: >Even though it would be a metamodel change, can we just fix this as part of UML 2.5, as part of resolving inconsistencies with the spec document? I would like to think so, because I have had quite enough of last-minute resolutions on 2.4. But as you know, metamodel changes are supposedly out of scope for 2.5. Pete, it seems that the correct way to represent a model in which these values have the default is actually unambiguous, given what the spec says, and Ed.s explanation of it, which I agree with. So what actually is the MIWG problem? From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 November 2010 16:25 To: Steve Cook Cc: Pete Rivett - Adaptive; melaasar@ca.ibm.com; nicolas.f.rouquette@jpl.nasa.gov Subject: RE: Big UML 2.4 problem: missing defaults in XMI Steve . These are all really supposed to be value specifications. The idea is that they can all be specified as expressions in the model, to be evaluated at .run time., rather than just being model-time constants. Also, a guard is not a constraint . it does not have to be true for a model to be valid; indeed, the whole point of a guard is to gate the flow of tokens based on whether it is true or false. So, when the default is given as, e.g., .true. for a guard, I believe what is really meant is that the default should be a LiteralBoolean (which is a kind of ValueSpecification) with the value .true.. Similarly, the default for weight should be a LiteralInteger, and the default for upperBound should be a LiteralUnlimitedNatural. The case of joinSpec is a bit more difficult. This is really supposed to be an operator of some sort, though exactly how this is supposed to be formalized in a ValueSpecification is not very clear. I think the best way to represent the default is as an Expression (also a kind of ValueSpecification) symbol=.and. and no operands. Even though it would be a metamodel change, can we just fix this as part of UML 2.5, as part of resolving inconsistencies with the spec document? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 11:52 AM To: Pete Rivett - Adaptive; melaasar@ca.ibm.com; nicolas.f.rouquette@jpl.nasa.gov Cc: Ed Seidewitz Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete True, 1 and * are not instances of ValueSpecification. The way that this kind of thing is handled in Multiplicity is to derive the .default values. through operations: MultiplicityElement::lowerBound() : [Integer]; lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif But in that case the ValueSpecification can be empty, the emptiness implies the default value, and there are strongly-typed derived attributes that specify what the value should actually be. For guard, I suppose the ValueSpecification is actually supposed to be a Constraint. For weight, why is it not simply defined as an Integer? For upperBound, why is it not simply defined as UnlimitedNatural? I also found joinSpec : ValueSpecification [1..1] with default .and.. Here I would go for String. Is this a show-stopper for 2.4? Do we have to create another resolution for these? If we did go for another resolution, I would say make them all [0..1], create derived attributes /guardValue: Boolean, /weightValue: Integer, /upper : UnlimitedNatural and /joinSpecValue : String, and use the same pattern to give them .defaults. via operations. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 01 November 2010 15:29 To: Steve Cook; melaasar@ca.ibm.com; nicolas.f.rouquette@jpl.nasa.gov Cc: ed-s@modeldriven.com Subject: Big UML 2.4 problem: missing defaults in XMI Importance: High This came up in the MIWG testing (though that was for UML 2.2) There seem to be several cases where the specification has defaults that are not represented in the XMI. Examples of this are as follows: ActivityEdge::guard : ValueSpecification [1..1] = true ActivityEdge::weight : ValueSpecification [1..1] = 1 ObjectNode::upperBound : ValueSpecification [1..1] = * They all seem to be ValueSpecifications so I.m sure there are others. BTW these are all listed under Attributes of the metaclass whereas they are in fact modeled as Associations with ValueSpecification. So should they not be placed into the Associations section? Something to look at for 2.5 I guess. Pete -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp From: Steve Cook To: Ed Seidewitz , Pete Rivett - Adaptive CC: Maged Elaasar , Juergen Boldt , "Rouquette, Nicolas F (316A)" Subject: RE: Big UML 2.4 problem: missing defaults in XMI Thread-Topic: Big UML 2.4 problem: missing defaults in XMI Thread-Index: Act52XfjxVZVzSdfSOGdF27vX/5YIwAAI94AAAFtMNAAAHdr8AACYRYAAABd4QAAAAa5sAAAY4DwAABrlVAAAEOcsAAAHG0wAAPYNDAAAd/KAAABiYuAAAFW4AAAfeybEAAJEWyAAAJ+9oAAAaRq0AAD/dgAAARbFIAAAGWhgAABMhKAAAA9/YAAGhzWwA== Date: Fri, 5 Nov 2010 10:17:59 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.97] Without being too pedantic about whether/how the spec and/or metamodel are actually correct or not, can we agree that the MIWG will adopt the convention that the defaults called for in the spec are not to be serialized, leave the issues unresolved, and get on with tying up 2.4? -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 04 November 2010 21:42 To: Pete Rivett - Adaptive Cc: Steve Cook; Maged Elaasar; Juergen Boldt; Rouquette, Nicolas F (316A) Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete -- Actually, you are right, option 3 was pretty much what I was agreeing with, wasn.t I? J -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, November 04, 2010 5:35 PM To: Ed Seidewitz; Rouquette, Nicolas F (316A) Cc: Steve Cook; Maged Elaasar; Juergen Boldt Subject: RE: Big UML 2.4 problem: missing defaults in XMI I was proposing option 3) not option 2), to quote . So my preference would be to include the wording from 3) as the response to the issue Steve just raised.. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, November 04, 2010 2:00 PM To: Rouquette, Nicolas F (316A); Pete Rivett Cc: Steve Cook; Maged Elaasar; Juergen Boldt Subject: RE: Big UML 2.4 problem: missing defaults in XMI Actually, I agree that we shouldn.t tell people that .the spec is correct and the metamodel is wrong. on this, as such. In reality, the spec is wrong (since it calls for defaults in a metamodel that are not allowed in MOF) and the metamodel does not express what was intended (since it calls for the properties to be serialized in a large number of cases that was not intended). My position is just that the MIWG adopt the convention that the defaults called for in the spec are not to be serialized (effectively acting as if the spec was correct, because that is what was intended) and then make both the spec and the metamodel both correct and as intended in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, November 04, 2010 4:49 PM To: Pete Rivett - Adaptive Cc: Steve Cook; Maged Elaasar; Ed Seidewitz; Juergen Boldt Subject: Re: Big UML 2.4 problem: missing defaults in XMI Hi, I strongly disagree with (2) Issue 15804 is a duplicate of issue 8450 from Pete: http://www.omg.org/issues/uml2-rtf.open.html#Issue8450 The real issue is that the current specification document is written in terms of conventions outside the scope of what is supported in clause 6.2. Another way of saying this is that the notation subclause in 7.3.45 Property does not explain how to convert the textual notation for a default value when the type of the property is not a datatype. In fact, the problem is much more fundamental than this because in current UML there is fundamentally no way to *designate* an element as a value for any purpose; instance specification, default value, instance value, ... http://www.omg.org/issues/uml2-rtf.open.html#Issue10821 For that matter, we don't even have a way to link element values: http://www.omg.org/issues/uml2-rtf.open.html#Issue9445 ... let alone construct collections of elements or navigate across links among elements: http://www.omg.org/issues/uml2-rtf.open.html#Issue9961 So, saying that the spec is correct and the metamodel is wrong is itself a lie. The metamodel can only represent what we know how to represent by construction or by convention. The real problem is that the document sometimes exceeds the limitations established in the conventions described in clause 6.2 - Nicolas. On Nov 4, 2010, at 11:44 AM, Pete Rivett wrote: I think so: Ed can confirm. Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, November 04, 2010 9:55 AM To: Pete Rivett; Maged Elaasar Cc: Ed Seidewitz; Rouquette, Nicolas F (316A) Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete Are you suggesting that we include a resolution to this issue in Ballot 11 with these words or similar, and that would be sufficient for the MIWG? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 04 November 2010 16:03 To: Maged Elaasar; Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A) Subject: RE: Big UML 2.4 problem: missing defaults in XMI Not so simple, folks . the reason this was raised in the first place was due to a real interchange problem. Even if we do nothing formally at UML 2.4 .we. need to give a clear statement - to MIWG amongst others - regarding serialization of these properties. And it seems to me desirable that the .we. needs to have more weight than an email from us 5. Options: 1) Tell people that the spec is wrong and the metamodel is correct in providing no defaults and that values should always be serialized 2) Tell people the spec is correct and the metamodel wrong and that the documented defaults should not be serialized. This I believe is the interim position taken by MIWG. 3) Tell people that the spec is correct but that we don.t have a way of including defaults for ValueSpecifications in the metamodel. In the same way as there is no default for multiplicities. Nonetheless the default weights etc must not be serialized. So my preference would be to include the wording from 3) as the response to the issue Steve just raised. For the future we need to consider how to serialize such default ValueSpecifications. I still disagree with Ed on this: while his approach is technically more .pure. what I advocate works and is more pragmatic. And is what tools are more likely to do anyway. It might not accord with fUML but since when is the fUML spec binding on the UML spec? Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, November 04, 2010 7:52 AM To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); Pete Rivett Subject: RE: Big UML 2.4 problem: missing defaults in XMI I agree to do nothing now, although I think we should not get bogged down initially in 2.5 by this or other MM changes in order to do a timely submission. In the FTF, we can entertain these changes assming they do not adversely impact compatibility. Maged Steve Cook Steve Cook 11/04/2010 06:32 AM To Ed Seidewitz , Pete Rivett - Adaptive cc Maged Elaasar/Ottawa/IBM@IBMCA, "Rouquette, Nicolas F (316A)" Subject RE: Big UML 2.4 problem: missing defaults in XMI From the silence I.m assuming we agreed to fix it in 2.5. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 November 2010 22:26 To: Pete Rivett - Adaptive Cc: Steve Cook; melaasar@ca.ibm.com; Rouquette, Nicolas F (316A) Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete . Well, ObjectNode::upperBound is a ValueSpecification for the same reason that Multiplicity::upperBound is a ValueSpecification . to allow for computed upper bounds, rather than having them fixed to values in the model. I suppose that is why weight is also a ValueSpecification, though I am hard pressed to come up with an example in which that is useful (perhaps in the context of a template??). But I wouldn.t change it without a thorough conversation with Conrad first! Indeed, I go with Steve.s most recent option: Do nothing now (except maybe submit an issue), leave the spec inconsistent with the metamodel (as it is in a number of other places) and figure out the right thing to do as part of UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Monday, November 01, 2010 5:48 PM To: Rouquette, Nicolas F (316A); Ed Seidewitz Cc: Steve Cook; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Your option 2 also requires MOF to be changed to permit default values for Properties typed by Classes. The complexity of what to do with the instances explains the original reason for this J. I.m not sure Ed.s proposed use of InstanceSpecification is right either: see email just sent. A 3rd option is as per Steve.s suggestion: For weight, why is it not simply defined as an Integer? For upperBound, why is it not simply defined as UnlimitedNatural? That at least would minimize the impact on existing models. And make joinSpec and guard optional. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, November 01, 2010 2:04 PM To: Ed Seidewitz Cc: Steve Cook; melaasar@ca.ibm.com; Pete Rivett Subject: Re: Big UML 2.4 problem: missing defaults in XMI Why agonize over this? Objectively, we have 2 choices: option1: - leave the 2.4 metamodel as-is without the defaults - remove the defaults from the spec document which still requires an issue/resolution for ballot 11 - this will break compatibility with 2.3 models that don't have the default values serialized option2: - add default values in the 2.4 metamodel as Ed suggested (i.e., via an instance value that refers to an instance spec for a literal integer/string as appropriate) - this requires yet one more issue/resolution for ballot 11 to fix the metamodel - this should provide compatibility with 2.3 models that don't have the default values serialized Objectively speaking, I prefer option 2. - Nicolas. On Nov 1, 2010, at 1:21 PM, Ed Seidewitz wrote: Steve . No, all I was saying is that the usual rule of XMI serialization for UML is that when a property has its default value, it is not serialized. This is regardless of the multiplicity . when there is a default or a mandatory property, not serializing the value means that the property has the default value, not that it is empty. Your point about properties with class types not being allowed to have defaults in MOF is a different . and more salient . point. This seems to mean that the defaults as given in the spec are not allowed in any case (unless this is changing in MOF 2.4.). I am trying mightily to convince myself we do not have to resolve this in UML 2.4. However, having to serialize explicit weights and guards for every activity edge in an activity diagram, even though they are pointless in almost all cases, does not seem like a good solution to me. Presuming that the defaults are really not allowed by MOF, I think the only reasonable solution is to make these properties optional, with the semantics of the cases when they are empty being equivalent to what is currently given as the defaults. On the one hand, a change like this would seem to have to be made in UML 2.4. However, if we did it in UML 2.5, it would not actually invalidate any UML 2.4 models (since it would just weaken the multiplicity constraint), and would, in fact, be compatible with XMI generated by tools that assumed one should not serialized the previously specified default values for these properties. So maybe we can just handle it in UML 2.5.(please?) -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 2:33 PM To: Ed Seidewitz; Pete Rivett - Adaptive; Rouquette, Nicolas F (316A) Cc: melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Ed Really? But the multiplicity is [1..1]. You are saying that there are special rules for a [1..1] association when the metamodel has a default value. I don.t think so. Here.s a quote from the MOF spec: [8] Properties of type Class cannot have defaults. It doesn.t seem at all supportive of this approach. In the latest MIWG report Peter Denno says he.s .updated the metamodel the validator uses.. To what, I wonder? Are you arguing that we should fix this problem in 2.4? It seems to me that any tool, according to the current spec, is required to serialize an instance of ValueSpecification for all of these properties, because of the lower multiplicity. They.d be sensible to serialize instances that conform to the defaults specified in the text. What is wrong with that? -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 November 2010 18:19 To: Steve Cook; Pete Rivett - Adaptive; Rouquette, Nicolas F (316A) Cc: melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Steve . Even though I think the default value specification that Pete gave is wrong, the intent is correct. By giving a default value in the metamodel, it is then not necessary to serialize the weight if it is equal to the default. It is when the default is missing that the weight would need to always be serialized. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 2:13 PM To: Pete Rivett - Adaptive; Rouquette, Nicolas F (316A) Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Sorry, I had a meta-moment. Yes. And the effect of this would be to require every model, for every instance of ActivityEdge, to explicitly serialize a copy of that LiteralInteger for its weight. Do you really think that is the best solution? From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 01 November 2010 18:08 To: Steve Cook; Rouquette, Nicolas F (316A) Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI We have hundreds of instances of LiteralInteger . for all the non-default multiplicities. And even used for default values . for example Extension::lower. What I.d expect to see in the metamodel is, for example (with change in green): The minimum number of tokens that must traverse the edge at the same time. And I already stated how these defaults should be depicted on diagrams . by having the default assignment on the association end label (as Ed pointed out somehow I missed them on the existing Figures 12.11 and 12.14 . I was looking in attribute compartment). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 10:50 AM To: Pete Rivett; Rouquette, Nicolas F (316A) Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete What should the metamodel be? I don.t understand how to model this. We don.t have any instances of LiteralInteger, Expression, LiteralBoolean and so on in the metamodel. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 01 November 2010 17:46 To: Rouquette, Nicolas F (316A); Steve Cook Cc: Ed Seidewitz; melaasar@ca.ibm.com Subject: RE: Big UML 2.4 problem: missing defaults in XMI I.m puzzled: how would you fix the spec document . to remove these as defaults to match the metamodel? Seems the wrong way round to me. That will then have the danger of breaking model interchange if people have relied on the spec not the metamodel. In fact MIWG is likely to be fixing their Validator to match what the metamodel should be (i.e.to insert the defaults). Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, November 01, 2010 10:35 AM To: Steve Cook Cc: Ed Seidewitz; Pete Rivett; melaasar@ca.ibm.com Subject: Re: Big UML 2.4 problem: missing defaults in XMI The following defaults are not in the 2.4 metamodel (nor in 2.3 either) ActivityEdge::guard : ValueSpecification [1..1] = true ActivityEdge::weight : ValueSpecification [1..1] = 1 ObjectNode::upperBound : ValueSpecification [1..1] = * The only thing that needs fixing is the specification document, which is sensible to do in 2.5. - Nicolas. On Nov 1, 2010, at 9:31 AM, Steve Cook wrote: >Even though it would be a metamodel change, can we just fix this as part of UML 2.5, as part of resolving inconsistencies with the spec document? I would like to think so, because I have had quite enough of last-minute resolutions on 2.4. But as you know, metamodel changes are supposedly out of scope for 2.5. Pete, it seems that the correct way to represent a model in which these values have the default is actually unambiguous, given what the spec says, and Ed.s explanation of it, which I agree with. So what actually is the MIWG problem? From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 November 2010 16:25 To: Steve Cook Cc: Pete Rivett - Adaptive; melaasar@ca.ibm.com; nicolas.f.rouquette@jpl.nasa.gov Subject: RE: Big UML 2.4 problem: missing defaults in XMI Steve . These are all really supposed to be value specifications. The idea is that they can all be specified as expressions in the model, to be evaluated at .run time., rather than just being model-time constants. Also, a guard is not a constraint . it does not have to be true for a model to be valid; indeed, the whole point of a guard is to gate the flow of tokens based on whether it is true or false. So, when the default is given as, e.g., .true. for a guard, I believe what is really meant is that the default should be a LiteralBoolean (which is a kind of ValueSpecification) with the value .true.. Similarly, the default for weight should be a LiteralInteger, and the default for upperBound should be a LiteralUnlimitedNatural. The case of joinSpec is a bit more difficult. This is really supposed to be an operator of some sort, though exactly how this is supposed to be formalized in a ValueSpecification is not very clear. I think the best way to represent the default is as an Expression (also a kind of ValueSpecification) symbol=.and. and no operands. Even though it would be a metamodel change, can we just fix this as part of UML 2.5, as part of resolving inconsistencies with the spec document? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, November 01, 2010 11:52 AM To: Pete Rivett - Adaptive; melaasar@ca.ibm.com; nicolas.f.rouquette@jpl.nasa.gov Cc: Ed Seidewitz Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete True, 1 and * are not instances of ValueSpecification. The way that this kind of thing is handled in Multiplicity is to derive the .default values. through operations: MultiplicityElement::lowerBound() : [Integer]; lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif But in that case the ValueSpecification can be empty, the emptiness implies the default value, and there are strongly-typed derived attributes that specify what the value should actually be. For guard, I suppose the ValueSpecification is actually supposed to be a Constraint. For weight, why is it not simply defined as an Integer? For upperBound, why is it not simply defined as UnlimitedNatural? I also found joinSpec : ValueSpecification [1..1] with default .and.. Here I would go for String. Is this a show-stopper for 2.4? Do we have to create another resolution for these? If we did go for another resolution, I would say make them all [0..1], create derived attributes /guardValue: Boolean, /weightValue: Integer, /upper : UnlimitedNatural and /joinSpecValue : String, and use the same pattern to give them .defaults. via operations. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 01 November 2010 15:29 To: Steve Cook; melaasar@ca.ibm.com; nicolas.f.rouquette@jpl.nasa.gov Cc: ed-s@modeldriven.com Subject: Big UML 2.4 problem: missing defaults in XMI Importance: High This came up in the MIWG testing (though that was for UML 2.2) There seem to be several cases where the specification has defaults that are not represented in the XMI. Examples of this are as follows: ActivityEdge::guard : ValueSpecification [1..1] = true ActivityEdge::weight : ValueSpecification [1..1] = 1 ObjectNode::upperBound : ValueSpecification [1..1] = * They all seem to be ValueSpecifications so I.m sure there are others. BTW these are all listed under Attributes of the metaclass whereas they are in fact modeled as Associations with ValueSpecification. So should they not be placed into the Associations section? Something to look at for 2.5 I guess. Pete -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp From: "Rouquette, Nicolas F (316A)" To: "steve.cook@microsoft.com" , "ed-s@modeldriven.com" , "pete.rivett@adaptive.com" CC: Maged Elaasar , "juergen@omg.org" Date: Fri, 5 Nov 2010 07:55:48 -0700 Subject: RE: Big UML 2.4 problem: missing defaults in XMI Thread-Topic: Big UML 2.4 problem: missing defaults in XMI Thread-Index: Act8+X/+eoNDbuvGRY++stoDgQVerg== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Ok Sent via DROID on Verizon Wireless -----Original message----- From: Steve Cook To: Ed Seidewitz , Pete Rivett - Adaptive Cc: Maged Elaasar , Juergen Boldt , "Rouquette, Nicolas F (316A)" Sent: Fri, Nov 5, 2010 10:18:29 GMT+00:00 Subject: RE: Big UML 2.4 problem: missing defaults in XMI Without being too pedantic about whether/how the spec and/or metamodel are actually correct or not, can we agree that the MIWG will adopt the convention that the defaults called for in the spec are not to be serialized, leave the issues unresolved, and get on with tying up 2.4? -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 04 November 2010 21:42 To: Pete Rivett - Adaptive Cc: Steve Cook; Maged Elaasar; Juergen Boldt; Rouquette, Nicolas F (316A) Subject: RE: Big UML 2.4 problem: missing defaults in XMI Pete -- Actually, you are right, option 3 was pretty much what I was agreeing with, wasnât I? J -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, November 04, 2010 5:35 PM To: Ed Seidewitz; Rouquette, Nicolas F (316A) Cc: Steve Cook; Maged Elaasar; Juergen Boldt Subject: RE: Big UML 2.4 problem: missing defaults in XMI I was proposing option 3) not option 2), to quote â So my preference would be to include the wording from 3) as the response to the issue Steve just raised.â From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, November 04, 2010 2:00 PM To: Rouquette, Nicolas F (316A); Pete Rivett Cc: Steve Cook; Maged Elaasar; Juergen Boldt Subject: RE: Big UML 2.4 problem: missing defaults in XMI Actually, I agree that we shouldnât tell people that âthe spec is correct and the metamodel is wrongâ on this, as such. In reality, the spec is wrong (since it calls for defaults in a metamodel that are not allowed in MOF) and the metamodel does not express what was intended (since it calls for the properties to be serialized in a large number of cases that was not intended). My position is just that the MIWG adopt the convention that the defaults called for in the spec are not to be serialized (effectively acting as if the spec was correct, because that is what was intended) and then make both the spec and the metamodel both correct and as intended in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, November 04, 2010 4:49 PM To: Pete Rivett - Adaptive Cc: Steve Cook; Maged Elaasar; Ed Seidewitz; Juergen Boldt Subject: Re: Big UML 2.4 problem: missing defaults in XMI Hi, I strongly disagree with (2) Issue 15804 is a duplicate of issue 8450 from Pete: http://www.omg.org/is