Issue 8449: Should Profiles::Image be an Element? (uml2-rtf) Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: Should Image a subclass of Element? Image and diagram interchange may benefit from reflective capabilities inherited from MOF. Having Image, and all UML metaclasses be a subclass of Element may make it easier for MOF based tools to reflectively navigate the visual notation. Recommendation: Make Profiles::Image a subclass of Element Resolution: see pages 323/324 of ptc/2006-04-01 Revised Text: Actions taken: March 4, 2005: received issue August 23, 2006: closed issue Discussion: End of Annotations:===== Issue 8449: Should Profiles::Image be an Element? Click here for this issue's archive. Source: International Business Machines (Mr. Jim Amsden, mailto:%20jamsden@us.ibm.com) Nature: Uncategorized Issue Severity: Summary: Should Image a subclass of Element? Image and diagram interchange may benefit from reflective capabilities inherited from MOF. Having Image, and all UML metaclasses be a subclass of Element may make it easier for MOF based tools to reflectively navigate the visual notation. Recommendation: Make Profiles::Image a subclass of Element Discussion: Image is delegated to DI for its complete definition. But yes, it seems a good idea to make it an Element. Revised Text: In the profile metamodel (Fig 446), let Image generalize Element. In 18.3.4 (Image) Replace Generalization None By Generalization InfrastructureLibrary:Abstractions:Elements:Element Resolution: Resolved c: Pete.Rivett@adaptive.com, jamsden@us.ibm.com Subject: Critical UML 2 Infra and Super issues X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 4 Mar 2005 08:19:59 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.53HF247 | January 6, 2005) at 03/04/2005 08:19:59, Serialize complete at 03/04/2005 08:19:59 The following issues need to be resolved before the XMI can be generated: (1) UML 2 Infrastructure issues: ========================== Issue Y1: Should Profiles::Image be an Element? Source: Jim Amsden, IBM Software Summary: Should Image a subclass of Element? Image and diagram interchange may benefit from reflective capabilities inherited from MOF. Having Image, and all UML metaclasses be a subclass of Element may make it easier for MOF based tools to reflectively navigate the visual notation. Recommendation: Make Profiles::Image a subclass of Element. Subject: RE: [Profile] - set of issue resolution Date: Tue, 17 May 2005 15:46:38 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Profile] - set of issue resolution Thread-Index: AcVbBYj0t8dIUYKARSixD5NEYkQzcwAB/2SQ From: "Pete Rivett" To: , X-Virus-Scanned: by amavisd-new at sentraliant.com Here are some comments by issue number.... In general where there are changes made to the document they should be applied to the equivalent section in Infrastructure also. Issue 8256: I think the phrase 'at least one instance of the stereotype extension graph' is a bit cryptic: I suggest 'at least one instance of the stereotype or one of its subclasses' Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Issue 8453: Also needs the diagram (Figure 446) to be updated to show the redefined 'lower' property on ExtensionEnd. Issue 8596: It would be helpful to correct the start of the issue text and clarify that it is referring to the 'isRequired' attribute in section 18.3.2. I think the text of the spec needs correcting by replacing "The attribute value is derived from the multiplicity of Extension::ownedEnd" by "The attribute value is derived from the multiplicity of the Property referenced by Extension::ownedEnd". Adding OCL would be even better. Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. The diagram change in the current resolution should be to add "{redefines ownedEnd}" as opposed to "{subsets ownedEnd}". This is already reflected in 18.3.2 so the 2nd change is not necessary at all. Issue 8598: the '/' indicates that the Association is derived so I do not see any reason to remove it. This is official notation for a derived Assoaiction (see 2nd bullet on p39). Isue 8600: "{subsets type}" should be "{redefines type}" as in the Issue and as in the text of 18.3.3. hence the change " In ExtensionEnd, Association, type Add subsets TypedElement::type." is redundant and wrong. Rather than deleting "which was 1" completely, it might be useful to replace it by "which normally, for MultiplicityElements, evaluates to 1 if empty" Issue 8601: I disagree with removing the notation option of allowing '1' instead of {required}. This is not fixing a real problem and introducing such incompatibilities (it invalidates some diagrams, and tools, which are currently valid) is not something an RTF should be doing in the absence of a compelling reason. Issue 8603: rather than addign text "OCL is not available", why not add the OCL? Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Desfray [mailto:Philippe.Desfray@softeam.fr] > Sent: Tuesday, May 17, 2005 6:07 PM > To: uml2-rtf@omg.org > Subject: [Profile] - set of issue resolution > > Dear all, > For the next resolution thread, and to the particular attention of the > Profile WG > > Here is the thread of numerous and easy issues (typos, light > issues) for > profiles. The remaining issues will stem from the teleconf > of the 20th on > Profile. > > To be integrated in the Ballot 4 if everyone is enthousiast with these > resolutions. > Best regards > > ==================================== > Philippe Desfray > VP for R&D - SOFTEAM > Tel: (33) 01 53968400 > Fax: (33) 01 53968401 > 144 Av. des champs Elysées 75008 PARIS > www.softeam.com > www.objecteering.com > Reply-To: From: "Desfray" To: "'Pete Rivett'" , Subject: RE: [Profile] - set of issue resolution Date: Wed, 18 May 2005 09:54:56 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MS-TNEF-Correlator: 0000000000C3B727BFC1BC11A4646E0283BD88A8043CC200 X-Virus-Scanned: by amavisd-new at softeam.com Thanks for these feedbacks Pete, Here is an updated file with proposed resolutions. The "Image" resolution will need more discussion and are withdrawn: >>> Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Well I was hesitating on this point. My first approach was to leave that entirely to DI, and not to take any decision about Images. I though inheriting from Element was harmless, but you have a point here. Lets see if there are other opinions about it. >>> Issue 8596 ... Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. Well, it is not an instance diagram, it is a class diagram (being instances of CMOF metaclasses indeed,but the instance diagram would show instances of associations and would lead to a totally different picture). Mixing instance & class diagram would bring more confusion. This instance explaination can be added to the text, as I suggest in the updated resolution. >>>> Issue 8603: rather than addign text "OCL is not available", why not add the OCL? "Stereotype names should not clash with keywords" : how do you express keywords in OCL? I would not recommend to put here a predefined list of strings ... ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 17 mai 2005 21:47 À : Philippe.Desfray@softeam.fr; uml2-rtf@omg.org Objet : RE: [Profile] - set of issue resolution Here are some comments by issue number.... In general where there are changes made to the document they should be applied to the equivalent section in Infrastructure also. Issue 8256: I think the phrase 'at least one instance of the stereotype extension graph' is a bit cryptic: I suggest 'at least one instance of the stereotype or one of its subclasses' Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Issue 8453: Also needs the diagram (Figure 446) to be updated to show the redefined 'lower' property on ExtensionEnd. Issue 8596: It would be helpful to correct the start of the issue text and clarify that it is referring to the 'isRequired' attribute in section 18.3.2. I think the text of the spec needs correcting by replacing "The attribute value is derived from the multiplicity of Extension::ownedEnd" by "The attribute value is derived from the multiplicity of the Property referenced by Extension::ownedEnd". Adding OCL would be even better. Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. The diagram change in the current resolution should be to add "{redefines ownedEnd}" as opposed to "{subsets ownedEnd}". This is already reflected in 18.3.2 so the 2nd change is not necessary at all. Issue 8598: the '/' indicates that the Association is derived so I do not see any reason to remove it. This is official notation for a derived Assoaiction (see 2nd bullet on p39). Isue 8600: "{subsets type}" should be "{redefines type}" as in the Issue and as in the text of 18.3.3. hence the change " In ExtensionEnd, Association, type Add subsets TypedElement::type." is redundant and wrong. Rather than deleting "which was 1" completely, it might be useful to replace it by "which normally, for MultiplicityElements, evaluates to 1 if empty" Issue 8601: I disagree with removing the notation option of allowing '1' instead of {required}. This is not fixing a real problem and introducing such incompatibilities (it invalidates some diagrams, and tools, which are currently valid) is not something an RTF should be doing in the absence of a compelling reason. Issue 8603: rather than addign text "OCL is not available", why not add the OCL? Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Desfray [ mailto:Philippe.Desfray@softeam.fr ] > Sent: Tuesday, May 17, 2005 6:07 PM > To: uml2-rtf@omg.org > Subject: [Profile] - set of issue resolution > > Dear all, > For the next resolution thread, and to the particular attention of the > Profile WG > > Here is the thread of numerous and easy issues (typos, light > issues) for > profiles. The remaining issues will stem from the teleconf > of the 20th on > Profile. > > To be integrated in the Ballot 4 if everyone is enthousiast with these > resolutions. > Best regards > > ==================================== > Philippe Desfray > VP for R&D - SOFTEAM > Tel: (33) 01 53968400 > Fax: (33) 01 53968401 > 144 Av. des champs Elysées 75008 PARIS > www.softeam.com > www.objecteering.com > To: Cc: uml2-rtf@omg.org Subject: RE: [Profile] - set of issue resolution X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Wed, 18 May 2005 05:41:58 -0600 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 05/18/2005 05:42:01 Philippe, If Image is not an Element, then it cannot be introspected using MOF reflection. Tools based on MOF that want to work reflectively with profiles and DI may find this to be a restriction. If Image is simply a data value, they it would be a property of a Stereotype rather than a separate metaclass. If Image is more than just a URI reference, then it is at least a DataType and could benefit from reflection. "Desfray" 05/18/2005 03:54 AM Please respond to Philippe.Desfray To "'Pete Rivett'" , cc Subject RE: [Profile] - set of issue resolution Thanks for these feedbacks Pete, Here is an updated file with proposed resolutions. The "Image" resolution will need more discussion and are withdrawn: >>> Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Well I was hesitating on this point. My first approach was to leave that entirely to DI, and not to take any decision about Images. I though inheriting from Element was harmless, but you have a point here. Lets see if there are other opinions about it. >>> Issue 8596 ... Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. Well, it is not an instance diagram, it is a class diagram (being instances of CMOF metaclasses indeed,but the instance diagram would show instances of associations and would lead to a totally different picture). Mixing instance & class diagram would bring more confusion. This instance explaination can be added to the text, as I suggest in the updated resolution. >>>> Issue 8603: rather than addign text "OCL is not available", why not add the OCL? "Stereotype names should not clash with keywords" : how do you express keywords in OCL? I would not recommend to put here a predefined list of strings ... ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 17 mai 2005 21:47 À : Philippe.Desfray@softeam.fr; uml2-rtf@omg.org Objet : RE: [Profile] - set of issue resolution Here are some comments by issue number.... In general where there are changes made to the document they should be applied to the equivalent section in Infrastructure also. Issue 8256: I think the phrase 'at least one instance of the stereotype extension graph' is a bit cryptic: I suggest 'at least one instance of the stereotype or one of its subclasses' Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Issue 8453: Also needs the diagram (Figure 446) to be updated to show the redefined 'lower' property on ExtensionEnd. Issue 8596: It would be helpful to correct the start of the issue text and clarify that it is referring to the 'isRequired' attribute in section 18.3.2. I think the text of the spec needs correcting by replacing "The attribute value is derived from the multiplicity of Extension::ownedEnd" by "The attribute value is derived from the multiplicity of the Property referenced by Extension::ownedEnd". Adding OCL would be even better. Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. The diagram change in the current resolution should be to add "{redefines ownedEnd}" as opposed to "{subsets ownedEnd}". This is already reflected in 18.3.2 so the 2nd change is not necessary at all. Issue 8598: the '/' indicates that the Association is derived so I do not see any reason to remove it. This is official notation for a derived Assoaiction (see 2nd bullet on p39). Isue 8600: "{subsets type}" should be "{redefines type}" as in the Issue and as in the text of 18.3.3. hence the change " In ExtensionEnd, Association, type Add subsets TypedElement::type." is redundant and wrong. Rather than deleting "which was 1" completely, it might be useful to replace it by "which normally, for MultiplicityElements, evaluates to 1 if empty" Issue 8601: I disagree with removing the notation option of allowing '1' instead of {required}. This is not fixing a real problem and introducing such incompatibilities (it invalidates some diagrams, and tools, which are currently valid) is not something an RTF should be doing in the absence of a compelling reason. Issue 8603: rather than addign text "OCL is not available", why not add the OCL? Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Desfray [ mailto:Philippe.Desfray@softeam.fr ] > Sent: Tuesday, May 17, 2005 6:07 PM > To: uml2-rtf@omg.org > Subject: [Profile] - set of issue resolution > > Dear all, > For the next resolution thread, and to the particular attention of the > Profile WG > > Here is the thread of numerous and easy issues (typos, light > issues) for > profiles. The remaining issues will stem from the teleconf > of the 20th on > Profile. > > To be integrated in the Ballot 4 if everyone is enthousiast with these > resolutions. > Best regards > > ==================================== > Philippe Desfray > VP for R&D - SOFTEAM > Tel: (33) 01 53968400 > Fax: (33) 01 53968401 > 144 Av. des champs Elysées 75008 PARIS > www.softeam.com > www.objecteering.com > winmail2.dat Subject: RE: [Profile] - set of issue resolution Date: Wed, 18 May 2005 17:01:22 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Profile] - set of issue resolution thread-index: AcVbfuHFR1DfVvATSBGSmctm44DvlgAOi6Ow From: "Tim Weilkiens" To: , "Pete Rivett" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j4IF79hh020410 Is it really necessary to model Image as a metaclass? What about modeling it as a string property of Stereotype? Just a thought. I don't know the arguments for the Image element that lead to the decision to introduce it in the final UML2 version. Tim > -----Original Message----- > From: Desfray [mailto:Philippe.Desfray@softeam.fr] > Sent: Wednesday, May 18, 2005 9:55 AM > To: 'Pete Rivett'; uml2-rtf@omg.org > Subject: RE: [Profile] - set of issue resolution > > Thanks for these feedbacks Pete, > > Here is an updated file with proposed resolutions. > The "Image" resolution will need more discussion and are withdrawn: > > >>> Issue 8449: I am not sure about Image inheriting from > Element: I see Image as more of a Data value. I think this > needs more discussion. If it does inherit from Element then > it should be "InfrastructureLibrary::Constructs::Element" > rather than from Abstractions. > > Well I was hesitating on this point. My first approach was to > leave that entirely to DI, and not to take any decision about > Images. I though inheriting from Element was harmless, but > you have a point here. Lets see if there are other opinions about it. > > >>> Issue 8596 ... Also the issue has a point about Figure > 448: it could be made clearer by indicating that's it's an > instance diagram (at the MOF level which is what it's about). > Just change the names in the boxes to: Interface:CMOF::Class > and Home:CMOF::Stereotype. > > Well, it is not an instance diagram, it is a class diagram > (being instances of CMOF metaclasses indeed,but the instance > diagram would show instances of associations and would lead > to a totally different picture). Mixing instance & class > diagram would bring more confusion. This instance > explaination can be added to the text, as I suggest in the > updated resolution. > > >>>> Issue 8603: rather than addign text "OCL is not > available", why not add the OCL? > "Stereotype names should not clash with keywords" : how do > you express keywords in OCL? I would not recommend to put > here a predefined list of strings ... > > ==================================== > Philippe Desfray > VP for R&D - SOFTEAM > Tel: (33) 01 53968400 > Fax: (33) 01 53968401 > 144 Av. des champs Elysées 75008 PARIS > www.softeam.com > www.objecteering.com > > -----Message d'origine----- > De : Pete Rivett [mailto:pete.rivett@adaptive.com] > Envoyé : mardi 17 mai 2005 21:47 > À : Philippe.Desfray@softeam.fr; uml2-rtf@omg.org > Objet : RE: [Profile] - set of issue resolution > > > > Here are some comments by issue number.... > > In general where there are changes made to the document > they should be applied to the equivalent section in > Infrastructure also. > > Issue 8256: I think the phrase 'at least one instance > of the stereotype extension graph' is a bit cryptic: I > suggest 'at least one instance of the stereotype or one of > its subclasses' > > Issue 8449: I am not sure about Image inheriting from > Element: I see Image as more of a Data value. I think this > needs more discussion. If it does inherit from Element then > it should be "InfrastructureLibrary::Constructs::Element" > rather than from Abstractions. > > > Issue 8453: Also needs the diagram (Figure 446) to be > updated to show the redefined 'lower' property on ExtensionEnd. > > Issue 8596: It would be helpful to correct the start > of the issue text and clarify that it is referring to the > 'isRequired' attribute in section 18.3.2. > I think the text of the spec needs correcting by > replacing "The attribute value is derived from the > multiplicity of Extension::ownedEnd" by "The attribute value > is derived from the multiplicity of the Property referenced > by Extension::ownedEnd". Adding OCL would be even better. > Also the issue has a point about Figure 448: it could > be made clearer by indicating that's it's an instance diagram > (at the MOF level which is what it's about). Just change the > names in the boxes to: Interface:CMOF::Class and > Home:CMOF::Stereotype. > The diagram change in the current resolution should be > to add "{redefines ownedEnd}" as opposed to "{subsets > ownedEnd}". This is already reflected in 18.3.2 so the 2nd > change is not necessary at all. > > > Issue 8598: the '/' indicates that the Association is > derived so I do not see any reason to remove it. This is > official notation for a derived Assoaiction (see 2nd bullet on p39). > > Isue 8600: "{subsets type}" should be "{redefines > type}" as in the Issue and as in the text of 18.3.3. hence > the change " > > In ExtensionEnd, Association, type > > Add > > subsets TypedElement::type." is redundant and wrong. > Rather than deleting "which was 1" completely, it might > be useful to replace it by "which normally, for > MultiplicityElements, evaluates to 1 if empty" > > > > Issue 8601: I disagree with removing the notation > option of allowing '1' instead of {required}. This is not > fixing a real problem and introducing such incompatibilities > (it invalidates some diagrams, and tools, which are currently > valid) is not something an RTF should be doing in the absence > of a compelling reason. > > Issue 8603: rather than addign text "OCL is not > available", why not add the OCL? > > Pete > > > > > > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > CTO, Adaptive Inc. > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, > BH1 1HL, UK > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > http://www.adaptive.com > > > > > > -----Original Message----- > > From: Desfray [mailto:Philippe.Desfray@softeam.fr] > > Sent: Tuesday, May 17, 2005 6:07 PM > > To: uml2-rtf@omg.org > > Subject: [Profile] - set of issue resolution > > > > Dear all, > > For the next resolution thread, and to the particular > attention of the > > Profile WG > > > > Here is the thread of numerous and easy issues (typos, light > > issues) for > > profiles. The remaining issues will stem from the teleconf > > of the 20th on > > Profile. > > > > To be integrated in the Ballot 4 if everyone is > enthousiast with these > > resolutions. > > Best regards > > > > ==================================== > > Philippe Desfray > > VP for R&D - SOFTEAM > > Tel: (33) 01 53968400 > > Fax: (33) 01 53968401 > > 144 Av. des champs Elysées 75008 PARIS > > www.softeam.com > > www.objecteering.com > > > > Subject: RE: [Profile] - set of issue resolution Date: Wed, 18 May 2005 11:22:59 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Profile] - set of issue resolution Thread-Index: AcVbu0R+EkaAEjo+QpOHlMXROyF24w== From: "Pete Rivett" To: "Jim Amsden" , Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com Jim, I agree the current situation is not ideal as you suggest: the question is how do we resolve it? One approach which avoids UML itself getting too deep into image formats/processing is to keep it opaque and make Image an instance of PrimitiveType. What introspection did you envisage on Image? Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, May 18, 2005 12:42 PM To: Philippe.Desfray@softeam.fr Cc: uml2-rtf@omg.org Subject: RE: [Profile] - set of issue resolution Philippe, If Image is not an Element, then it cannot be introspected using MOF reflection. Tools based on MOF that want to work reflectively with profiles and DI may find this to be a restriction. If Image is simply a data value, they it would be a property of a Stereotype rather than a separate metaclass. If Image is more than just a URI reference, then it is at least a DataType and could benefit from reflection. "Desfray" 05/18/2005 03:54 AM Please respond to Philippe.Desfray To "'Pete Rivett'" , cc Subject RE: [Profile] - set of issue resolution Thanks for these feedbacks Pete, Here is an updated file with proposed resolutions. The "Image" resolution will need more discussion and are withdrawn: >>> Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Well I was hesitating on this point. My first approach was to leave that entirely to DI, and not to take any decision about Images. I though inheriting from Element was harmless, but you have a point here. Lets see if there are other opinions about it. >>> Issue 8596 ... Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. Well, it is not an instance diagram, it is a class diagram (being instances of CMOF metaclasses indeed,but the instance diagram would show instances of associations and would lead to a totally different picture). Mixing instance & class diagram would bring more confusion. This instance explaination can be added to the text, as I suggest in the updated resolution. >>>> Issue 8603: rather than addign text "OCL is not available", why not add the OCL? "Stereotype names should not clash with keywords" : how do you express keywords in OCL? I would not recommend to put here a predefined list of strings ... ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 17 mai 2005 21:47 À : Philippe.Desfray@softeam.fr; uml2-rtf@omg.org Objet : RE: [Profile] - set of issue resolution Here are some comments by issue number.... In general where there are changes made to the document they should be applied to the equivalent section in Infrastructure also. Issue 8256: I think the phrase 'at least one instance of the stereotype extension graph' is a bit cryptic: I suggest 'at least one instance of the stereotype or one of its subclasses' Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Issue 8453: Also needs the diagram (Figure 446) to be updated to show the redefined 'lower' property on ExtensionEnd. Issue 8596: It would be helpful to correct the start of the issue text and clarify that it is referring to the 'isRequired' attribute in section 18.3.2. I think the text of the spec needs correcting by replacing "The attribute value is derived from the multiplicity of Extension::ownedEnd" by "The attribute value is derived from the multiplicity of the Property referenced by Extension::ownedEnd". Adding OCL would be even better. Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. The diagram change in the current resolution should be to add "{redefines ownedEnd}" as opposed to "{subsets ownedEnd}". This is already reflected in 18.3.2 so the 2nd change is not necessary at all. Issue 8598: the '/' indicates that the Association is derived so I do not see any reason to remove it. This is official notation for a derived Assoaiction (see 2nd bullet on p39). Isue 8600: "{subsets type}" should be "{redefines type}" as in the Issue and as in the text of 18.3.3. hence the change " In ExtensionEnd, Association, type Add subsets TypedElement::type." is redundant and wrong. Rather than deleting "which was 1" completely, it might be useful to replace it by "which normally, for MultiplicityElements, evaluates to 1 if empty" Issue 8601: I disagree with removing the notation option of allowing '1' instead of {required}. This is not fixing a real problem and introducing such incompatibilities (it invalidates some diagrams, and tools, which are currently valid) is not something an RTF should be doing in the absence of a compelling reason. Issue 8603: rather than addign text "OCL is not available", why not add the OCL? Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Desfray [ mailto:Philippe.Desfray@softeam.fr ] > Sent: Tuesday, May 17, 2005 6:07 PM > To: uml2-rtf@omg.org > Subject: [Profile] - set of issue resolution > > Dear all, > For the next resolution thread, and to the particular attention of the > Profile WG > > Here is the thread of numerous and easy issues (typos, light > issues) for > profiles. The remaining issues will stem from the teleconf > of the 20th on > Profile. > > To be integrated in the Ballot 4 if everyone is enthousiast with these > resolutions. > Best regards > > ==================================== > Philippe Desfray > VP for R&D - SOFTEAM > Tel: (33) 01 53968400 > Fax: (33) 01 53968401 > 144 Av. des champs Elysées 75008 PARIS > www.softeam.com > www.objecteering.com > Reply-To: From: "Desfray" To: "'Pete Rivett'" , "'Jim Amsden'" Cc: Subject: RE: [Profile] - set of issue resolution Date: Wed, 18 May 2005 18:01:54 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MS-TNEF-Correlator: 0000000000C3B727BFC1BC11A4646E0283BD88A82445C200 X-Virus-Scanned: by amavisd-new at softeam.com Thinking twice about it, I would like to recall the objective of this abstract Image metaclass: It is there to be further defined within the DI specification, where aditional information is added. In DI, an Image inherits from LeafElement which inherits from DiagramElements, all this having a couple of attributes. As far as can see (but I am puzzled with the DI spec, which seems uncomplete, without a detailed description of each class), DiagramElement does not inherit from Element. Image is not a primitive type, and the responsibility of its definition belongs to DI. Starting there, I see only two options: 1 Letting the decision of inheriting from Element to DI 2 Adding the Image/Element generalization in the Profile spec. I beleive that: 1 DiagramElement should generalize Element, and that is a DI issue. 2 Getting to the solution 2 would introduce an exception in the DI spec, and this is not desirable. It would be a trick, expecting that DI will fix it in some future. Unless we have a compelling Use Case to let Image generalize Element, we should go for option 1. And we are back to Pete's question: >>> What introspection did you envisage on Image? ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mercredi 18 mai 2005 17:23 À : Jim Amsden; Philippe.Desfray@softeam.fr Cc : uml2-rtf@omg.org Objet : RE: [Profile] - set of issue resolution Jim, I agree the current situation is not ideal as you suggest: the question is how do we resolve it? One approach which avoids UML itself getting too deep into image formats/processing is to keep it opaque and make Image an instance of PrimitiveType. What introspection did you envisage on Image? Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com _____ From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, May 18, 2005 12:42 PM To: Philippe.Desfray@softeam.fr Cc: uml2-rtf@omg.org Subject: RE: [Profile] - set of issue resolution Philippe, If Image is not an Element, then it cannot be introspected using MOF reflection. Tools based on MOF that want to work reflectively with profiles and DI may find this to be a restriction. If Image is simply a data value, they it would be a property of a Stereotype rather than a separate metaclass. If Image is more than just a URI reference, then it is at least a DataType and could benefit from reflection. "Desfray" 05/18/2005 03:54 AM Please respond to Philippe.Desfray To "'Pete Rivett'" , cc Subject RE: [Profile] - set of issue resolution Thanks for these feedbacks Pete, Here is an updated file with proposed resolutions. The "Image" resolution will need more discussion and are withdrawn: >>> Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Well I was hesitating on this point. My first approach was to leave that entirely to DI, and not to take any decision about Images. I though inheriting from Element was harmless, but you have a point here. Lets see if there are other opinions about it. >>> Issue 8596 ... Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. Well, it is not an instance diagram, it is a class diagram (being instances of CMOF metaclasses indeed,but the instance diagram would show instances of associations and would lead to a totally different picture). Mixing instance & class diagram would bring more confusion. This instance explaination can be added to the text, as I suggest in the updated resolution. >>>> Issue 8603: rather than addign text "OCL is not available", why not add the OCL? "Stereotype names should not clash with keywords" : how do you express keywords in OCL? I would not recommend to put here a predefined list of strings ... ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 17 mai 2005 21:47 À : Philippe.Desfray@softeam.fr; uml2-rtf@omg.org Objet : RE: [Profile] - set of issue resolution Here are some comments by issue number.... In general where there are changes made to the document they should be applied to the equivalent section in Infrastructure also. Issue 8256: I think the phrase 'at least one instance of the stereotype extension graph' is a bit cryptic: I suggest 'at least one instance of the stereotype or one of its subclasses' Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Issue 8453: Also needs the diagram (Figure 446) to be updated to show the redefined 'lower' property on ExtensionEnd. Issue 8596: It would be helpful to correct the start of the issue text and clarify that it is referring to the 'isRequired' attribute in section 18.3.2. I think the text of the spec needs correcting by replacing "The attribute value is derived from the multiplicity of Extension::ownedEnd" by "The attribute value is derived from the multiplicity of the Property referenced by Extension::ownedEnd". Adding OCL would be even better. Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. The diagram change in the current resolution should be to add "{redefines ownedEnd}" as opposed to "{subsets ownedEnd}". This is already reflected in 18.3.2 so the 2nd change is not necessary at all. Issue 8598: the '/' indicates that the Association is derived so I do not see any reason to remove it. This is official notation for a derived Assoaiction (see 2nd bullet on p39). Isue 8600: "{subsets type}" should be "{redefines type}" as in the Issue and as in the text of 18.3.3. hence the change " In ExtensionEnd, Association, type Add subsets TypedElement::type." is redundant and wrong. Rather than deleting "which was 1" completely, it might be useful to replace it by "which normally, for MultiplicityElements, evaluates to 1 if empty" Issue 8601: I disagree with removing the notation option of allowing '1' instead of {required}. This is not fixing a real problem and introducing such incompatibilities (it invalidates some diagrams, and tools, which are currently valid) is not something an RTF should be doing in the absence of a compelling reason. Issue 8603: rather than addign text "OCL is not available", why not add the OCL? Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Desfray [ mailto:Philippe.Desfray@softeam.fr ] > Sent: Tuesday, May 17, 2005 6:07 PM > To: uml2-rtf@omg.org > Subject: [Profile] - set of issue resolution > > Dear all, > For the next resolution thread, and to the particular attention of the > Profile WG > > Here is the thread of numerous and easy issues (typos, light > issues) for > profiles. The remaining issues will stem from the teleconf > of the 20th on > Profile. > > To be integrated in the Ballot 4 if everyone is enthousiast with these > resolutions. > Best regards > > ==================================== > Philippe Desfray > VP for R&D - SOFTEAM > Tel: (33) 01 53968400 > Fax: (33) 01 53968401 > 144 Av. des champs Elysées 75008 PARIS > www.softeam.com > www.objecteering.com > winmail3.dat To: "Pete Rivett" Cc: Philippe.Desfray@softeam.fr, uml2-rtf@omg.org Subject: RE: [Profile] - set of issue resolution X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Wed, 18 May 2005 14:26:57 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 05/18/2005 12:27:09, Serialize complete at 05/18/2005 12:27:09 Pete, I didn't have anything specific in mind, only that a reflective tool manipulating a profile should be able to see instances of Image, and introspect its properties. If it is opaque, then its really even more important to support introspection as there is no other standard way to access the properties. If Image is an instance of a primitive type, then it should be a property of Stereotype, not a separate metaclass. "Pete Rivett" 05/18/2005 11:22 AM To Jim Amsden/Raleigh/IBM@IBMUS, cc Subject RE: [Profile] - set of issue resolution Jim, I agree the current situation is not ideal as you suggest: the question is how do we resolve it? One approach which avoids UML itself getting too deep into image formats/processing is to keep it opaque and make Image an instance of PrimitiveType. What introspection did you envisage on Image? Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, May 18, 2005 12:42 PM To: Philippe.Desfray@softeam.fr Cc: uml2-rtf@omg.org Subject: RE: [Profile] - set of issue resolution Philippe, If Image is not an Element, then it cannot be introspected using MOF reflection. Tools based on MOF that want to work reflectively with profiles and DI may find this to be a restriction. If Image is simply a data value, they it would be a property of a Stereotype rather than a separate metaclass. If Image is more than just a URI reference, then it is at least a DataType and could benefit from reflection. "Desfray" 05/18/2005 03:54 AM Please respond to Philippe.Desfray To "'Pete Rivett'" , cc Subject RE: [Profile] - set of issue resolution Thanks for these feedbacks Pete, Here is an updated file with proposed resolutions. The "Image" resolution will need more discussion and are withdrawn: >>> Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Well I was hesitating on this point. My first approach was to leave that entirely to DI, and not to take any decision about Images. I though inheriting from Element was harmless, but you have a point here. Lets see if there are other opinions about it. >>> Issue 8596 ... Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. Well, it is not an instance diagram, it is a class diagram (being instances of CMOF metaclasses indeed,but the instance diagram would show instances of associations and would lead to a totally different picture). Mixing instance & class diagram would bring more confusion. This instance explaination can be added to the text, as I suggest in the updated resolution. >>>> Issue 8603: rather than addign text "OCL is not available", why not add the OCL? "Stereotype names should not clash with keywords" : how do you express keywords in OCL? I would not recommend to put here a predefined list of strings ... ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 17 mai 2005 21:47 À : Philippe.Desfray@softeam.fr; uml2-rtf@omg.org Objet : RE: [Profile] - set of issue resolution Here are some comments by issue number.... In general where there are changes made to the document they should be applied to the equivalent section in Infrastructure also. Issue 8256: I think the phrase 'at least one instance of the stereotype extension graph' is a bit cryptic: I suggest 'at least one instance of the stereotype or one of its subclasses' Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Issue 8453: Also needs the diagram (Figure 446) to be updated to show the redefined 'lower' property on ExtensionEnd. Issue 8596: It would be helpful to correct the start of the issue text and clarify that it is referring to the 'isRequired' attribute in section 18.3.2. I think the text of the spec needs correcting by replacing "The attribute value is derived from the multiplicity of Extension::ownedEnd" by "The attribute value is derived from the multiplicity of the Property referenced by Extension::ownedEnd". Adding OCL would be even better. Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. The diagram change in the current resolution should be to add "{redefines ownedEnd}" as opposed to "{subsets ownedEnd}". This is already reflected in 18.3.2 so the 2nd change is not necessary at all. Issue 8598: the '/' indicates that the Association is derived so I do not see any reason to remove it. This is official notation for a derived Assoaiction (see 2nd bullet on p39). Isue 8600: "{subsets type}" should be "{redefines type}" as in the Issue and as in the text of 18.3.3. hence the change " In ExtensionEnd, Association, type Add subsets TypedElement::type." is redundant and wrong. Rather than deleting "which was 1" completely, it might be useful to replace it by "which normally, for MultiplicityElements, evaluates to 1 if empty" Issue 8601: I disagree with removing the notation option of allowing '1' instead of {required}. This is not fixing a real problem and introducing such incompatibilities (it invalidates some diagrams, and tools, which are currently valid) is not something an RTF should be doing in the absence of a compelling reason. Issue 8603: rather than addign text "OCL is not available", why not add the OCL? Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Desfray [ mailto:Philippe.Desfray@softeam.fr ] > Sent: Tuesday, May 17, 2005 6:07 PM > To: uml2-rtf@omg.org > Subject: [Profile] - set of issue resolution > > Dear all, > For the next resolution thread, and to the particular attention of the > Profile WG > > Here is the thread of numerous and easy issues (typos, light > issues) for > profiles. The remaining issues will stem from the teleconf > of the 20th on > Profile. > > To be integrated in the Ballot 4 if everyone is enthousiast with these > resolutions. > Best regards > > ==================================== > Philippe Desfray > VP for R&D - SOFTEAM > Tel: (33) 01 53968400 > Fax: (33) 01 53968401 > 144 Av. des champs Elysées 75008 PARIS > www.softeam.com > www.objecteering.com > To: Cc: "'Pete Rivett'" , uml2-rtf@omg.org Subject: RE: [Profile] - set of issue resolution X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Wed, 18 May 2005 12:35:26 -0600 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 05/18/2005 12:35:28 Philippe, I like your solution 1, and think it is an indication we might have been trying to solve the wrong problem. The issue arises because Stereotype has a navigable association to Image. The DI specification should provide a way of associating images with stereotypes and there really should be no need to mention images in profiles at all. "Desfray" 05/18/2005 12:01 PM Please respond to Philippe.Desfray To "'Pete Rivett'" , Jim Amsden/Raleigh/IBM@IBMUS cc Subject RE: [Profile] - set of issue resolution Thinking twice about it, I would like to recall the objective of this abstract Image metaclass: It is there to be further defined within the DI specification, where aditional information is added. In DI, an Image inherits from LeafElement which inherits from DiagramElements, all this having a couple of attributes. As far as can see (but I am puzzled with the DI spec, which seems uncomplete, without a detailed description of each class), DiagramElement does not inherit from Element. Image is not a primitive type, and the responsibility of its definition belongs to DI. Starting there, I see only two options: 1 Letting the decision of inheriting from Element to DI 2 Adding the Image/Element generalization in the Profile spec. I beleive that: 1 DiagramElement should generalize Element, and that is a DI issue. 2 Getting to the solution 2 would introduce an exception in the DI spec, and this is not desirable. It would be a trick, expecting that DI will fix it in some future. Unless we have a compelling Use Case to let Image generalize Element, we should go for option 1. And we are back to Pete's question: >>> What introspection did you envisage on Image? ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mercredi 18 mai 2005 17:23 À : Jim Amsden; Philippe.Desfray@softeam.fr Cc : uml2-rtf@omg.org Objet : RE: [Profile] - set of issue resolution Jim, I agree the current situation is not ideal as you suggest: the question is how do we resolve it? One approach which avoids UML itself getting too deep into image formats/processing is to keep it opaque and make Image an instance of PrimitiveType. What introspection did you envisage on Image? Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com _____ From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, May 18, 2005 12:42 PM To: Philippe.Desfray@softeam.fr Cc: uml2-rtf@omg.org Subject: RE: [Profile] - set of issue resolution Philippe, If Image is not an Element, then it cannot be introspected using MOF reflection. Tools based on MOF that want to work reflectively with profiles and DI may find this to be a restriction. If Image is simply a data value, they it would be a property of a Stereotype rather than a separate metaclass. If Image is more than just a URI reference, then it is at least a DataType and could benefit from reflection. "Desfray" 05/18/2005 03:54 AM Please respond to Philippe.Desfray To "'Pete Rivett'" , cc Subject RE: [Profile] - set of issue resolution Thanks for these feedbacks Pete, Here is an updated file with proposed resolutions. The "Image" resolution will need more discussion and are withdrawn: >>> Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Well I was hesitating on this point. My first approach was to leave that entirely to DI, and not to take any decision about Images. I though inheriting from Element was harmless, but you have a point here. Lets see if there are other opinions about it. >>> Issue 8596 ... Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. Well, it is not an instance diagram, it is a class diagram (being instances of CMOF metaclasses indeed,but the instance diagram would show instances of associations and would lead to a totally different picture). Mixing instance & class diagram would bring more confusion. This instance explaination can be added to the text, as I suggest in the updated resolution. >>>> Issue 8603: rather than addign text "OCL is not available", why not add the OCL? "Stereotype names should not clash with keywords" : how do you express keywords in OCL? I would not recommend to put here a predefined list of strings ... ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 17 mai 2005 21:47 À : Philippe.Desfray@softeam.fr; uml2-rtf@omg.org Objet : RE: [Profile] - set of issue resolution Here are some comments by issue number.... In general where there are changes made to the document they should be applied to the equivalent section in Infrastructure also. Issue 8256: I think the phrase 'at least one instance of the stereotype extension graph' is a bit cryptic: I suggest 'at least one instance of the stereotype or one of its subclasses' Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Issue 8453: Also needs the diagram (Figure 446) to be updated to show the redefined 'lower' property on ExtensionEnd. Issue 8596: It would be helpful to correct the start of the issue text and clarify that it is referring to the 'isRequired' attribute in section 18.3.2. I think the text of the spec needs correcting by replacing "The attribute value is derived from the multiplicity of Extension::ownedEnd" by "The attribute value is derived from the multiplicity of the Property referenced by Extension::ownedEnd". Adding OCL would be even better. Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. The diagram change in the current resolution should be to add "{redefines ownedEnd}" as opposed to "{subsets ownedEnd}". This is already reflected in 18.3.2 so the 2nd change is not necessary at all. Issue 8598: the '/' indicates that the Association is derived so I do not see any reason to remove it. This is official notation for a derived Assoaiction (see 2nd bullet on p39). Isue 8600: "{subsets type}" should be "{redefines type}" as in the Issue and as in the text of 18.3.3. hence the change " In ExtensionEnd, Association, type Add subsets TypedElement::type." is redundant and wrong. Rather than deleting "which was 1" completely, it might be useful to replace it by "which normally, for MultiplicityElements, evaluates to 1 if empty" Issue 8601: I disagree with removing the notation option of allowing '1' instead of {required}. This is not fixing a real problem and introducing such incompatibilities (it invalidates some diagrams, and tools, which are currently valid) is not something an RTF should be doing in the absence of a compelling reason. Issue 8603: rather than addign text "OCL is not available", why not add the OCL? Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Desfray [ mailto:Philippe.Desfray@softeam.fr ] > Sent: Tuesday, May 17, 2005 6:07 PM > To: uml2-rtf@omg.org > Subject: [Profile] - set of issue resolution > > Dear all, > For the next resolution thread, and to the particular attention of the > Profile WG > > Here is the thread of numerous and easy issues (typos, light > issues) for > profiles. The remaining issues will stem from the teleconf > of the 20th on > Profile. > > To be integrated in the Ballot 4 if everyone is enthousiast with these > resolutions. > Best regards > > ==================================== > Philippe Desfray > VP for R&D - SOFTEAM > Tel: (33) 01 53968400 > Fax: (33) 01 53968401 > 144 Av. des champs Elysées 75008 PARIS > www.softeam.com > www.objecteering.com > winmail4.dat To: Jim Amsden Cc: "'Pete Rivett'" , Philippe.Desfray@softeam.fr, uml2-rtf@omg.org Subject: RE: [Profile] - set of issue resolution X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 18 May 2005 19:49:04 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.53HF247 | January 6, 2005) at 05/18/2005 19:51:01, Serialize complete at 05/18/2005 19:51:01 From what I recall, it was Philippe who suggested the addition of Image to the UML metamodel. I also recall that at the time, we were not very happy with this because it corrupted the architecturla principle of keeping UML agnostic and independent of DI. However, since we wanted to make profile definitions fully self-contained, we thought at the time that this necessarily implied that stereotype icons had to be in the UML side. If there is some other way of doing this, that would be great. However, unless we have a concrete proposal for this, we should opt for solution 2. I believe that the reason that LeafElement is not an Element was another architectural decision to keep the DI spec at arms length from the UML metamodel. This may have been because the intent was to allow the DI spec to be used for other metamodels. But, I cannot say that with certainty. The folks who know about DI are all gone. Bran Jim Amsden 05/18/2005 02:35 PM To cc "'Pete Rivett'" , uml2-rtf@omg.org Subject RE: [Profile] - set of issue resolution Philippe, I like your solution 1, and think it is an indication we might have been trying to solve the wrong problem. The issue arises because Stereotype has a navigable association to Image. The DI specification should provide a way of associating images with stereotypes and there really should be no need to mention images in profiles at all. "Desfray" 05/18/2005 12:01 PM Please respond to Philippe.Desfray To "'Pete Rivett'" , Jim Amsden/Raleigh/IBM@IBMUS cc Subject RE: [Profile] - set of issue resolution Thinking twice about it, I would like to recall the objective of this abstract Image metaclass: It is there to be further defined within the DI specification, where aditional information is added. In DI, an Image inherits from LeafElement which inherits from DiagramElements, all this having a couple of attributes. As far as can see (but I am puzzled with the DI spec, which seems uncomplete, without a detailed description of each class), DiagramElement does not inherit from Element. Image is not a primitive type, and the responsibility of its definition belongs to DI. Starting there, I see only two options: 1 Letting the decision of inheriting from Element to DI 2 Adding the Image/Element generalization in the Profile spec. I beleive that: 1 DiagramElement should generalize Element, and that is a DI issue. 2 Getting to the solution 2 would introduce an exception in the DI spec, and this is not desirable. It would be a trick, expecting that DI will fix it in some future. Unless we have a compelling Use Case to let Image generalize Element, we should go for option 1. And we are back to Pete's question: >>> What introspection did you envisage on Image? ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mercredi 18 mai 2005 17:23 À : Jim Amsden; Philippe.Desfray@softeam.fr Cc : uml2-rtf@omg.org Objet : RE: [Profile] - set of issue resolution Jim, I agree the current situation is not ideal as you suggest: the question is how do we resolve it? One approach which avoids UML itself getting too deep into image formats/processing is to keep it opaque and make Image an instance of PrimitiveType. What introspection did you envisage on Image? Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com _____ From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, May 18, 2005 12:42 PM To: Philippe.Desfray@softeam.fr Cc: uml2-rtf@omg.org Subject: RE: [Profile] - set of issue resolution Philippe, If Image is not an Element, then it cannot be introspected using MOF reflection. Tools based on MOF that want to work reflectively with profiles and DI may find this to be a restriction. If Image is simply a data value, they it would be a property of a Stereotype rather than a separate metaclass. If Image is more than just a URI reference, then it is at least a DataType and could benefit from reflection. "Desfray" 05/18/2005 03:54 AM Please respond to Philippe.Desfray To "'Pete Rivett'" , cc Subject RE: [Profile] - set of issue resolution Thanks for these feedbacks Pete, Here is an updated file with proposed resolutions. The "Image" resolution will need more discussion and are withdrawn: >>> Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Well I was hesitating on this point. My first approach was to leave that entirely to DI, and not to take any decision about Images. I though inheriting from Element was harmless, but you have a point here. Lets see if there are other opinions about it. >>> Issue 8596 ... Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. Well, it is not an instance diagram, it is a class diagram (being instances of CMOF metaclasses indeed,but the instance diagram would show instances of associations and would lead to a totally different picture). Mixing instance & class diagram would bring more confusion. This instance explaination can be added to the text, as I suggest in the updated resolution. >>>> Issue 8603: rather than addign text "OCL is not available", why not add the OCL? "Stereotype names should not clash with keywords" : how do you express keywords in OCL? I would not recommend to put here a predefined list of strings ... ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 17 mai 2005 21:47 À : Philippe.Desfray@softeam.fr; uml2-rtf@omg.org Objet : RE: [Profile] - set of issue resolution Here are some comments by issue number.... In general where there are changes made to the document they should be applied to the equivalent section in Infrastructure also. Issue 8256: I think the phrase 'at least one instance of the stereotype extension graph' is a bit cryptic: I suggest 'at least one instance of the stereotype or one of its subclasses' Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Issue 8453: Also needs the diagram (Figure 446) to be updated to show the redefined 'lower' property on ExtensionEnd. Issue 8596: It would be helpful to correct the start of the issue text and clarify that it is referring to the 'isRequired' attribute in section 18.3.2. I think the text of the spec needs correcting by replacing "The attribute value is derived from the multiplicity of Extension::ownedEnd" by "The attribute value is derived from the multiplicity of the Property referenced by Extension::ownedEnd". Adding OCL would be even better. Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. The diagram change in the current resolution should be to add "{redefines ownedEnd}" as opposed to "{subsets ownedEnd}". This is already reflected in 18.3.2 so the 2nd change is not necessary at all. Issue 8598: the '/' indicates that the Association is derived so I do not see any reason to remove it. This is official notation for a derived Assoaiction (see 2nd bullet on p39). Isue 8600: "{subsets type}" should be "{redefines type}" as in the Issue and as in the text of 18.3.3. hence the change " In ExtensionEnd, Association, type Add subsets TypedElement::type." is redundant and wrong. Rather than deleting "which was 1" completely, it might be useful to replace it by "which normally, for MultiplicityElements, evaluates to 1 if empty" Issue 8601: I disagree with removing the notation option of allowing '1' instead of {required}. This is not fixing a real problem and introducing such incompatibilities (it invalidates some diagrams, and tools, which are currently valid) is not something an RTF should be doing in the absence of a compelling reason. Issue 8603: rather than addign text "OCL is not available", why not add the OCL? Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Desfray [ mailto:Philippe.Desfray@softeam.fr ] > Sent: Tuesday, May 17, 2005 6:07 PM > To: uml2-rtf@omg.org > Subject: [Profile] - set of issue resolution > > Dear all, > For the next resolution thread, and to the particular attention of the > Profile WG > > Here is the thread of numerous and easy issues (typos, light > issues) for > profiles. The remaining issues will stem from the teleconf > of the 20th on > Profile. > > To be integrated in the Ballot 4 if everyone is enthousiast with these > resolutions. > Best regards > > ==================================== > Philippe Desfray > VP for R&D - SOFTEAM > Tel: (33) 01 53968400 > Fax: (33) 01 53968401 > 144 Av. des champs Elysées 75008 PARIS > www.softeam.com > www.objecteering.com > [attachment "winmail.dat" deleted by Branislav Selic/Ottawa/IBM] Reply-To: From: "Desfray" To: "'Pete Rivett'" , "'Branislav Selic'" , "'Jim Amsden'" Cc: Subject: RE: [Profile] - set of issue resolution Date: Thu, 19 May 2005 09:45:38 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MS-TNEF-Correlator: 0000000000C3B727BFC1BC11A4646E0283BD88A80449C200 X-Virus-Scanned: by amavisd-new at softeam.com (Jim)The DI specification should provide a way of associating images with stereotypes and there really should be no need to mention images in profiles at all. (pete) I say 'no': the DI spec is about exchanging diagram instances and not definitions of profiles. One should be able to associate an Image with a Stereotype in a Profile independently of, and prior to, drawing a diagram for a model having an Application of that profile (which is all that DI addresses). In fact DI has no notion of Profile or Stereotype and it's important to keep that independence. Fully agree with Pete here. We have to do something with image within profiles, and cannot just ditch it. (Bran) I believe that the reason that LeafElement is not an Element was another architectural decision to keep the DI spec at arms length from the UML metamodel. Well, UML is not in question here, it is a good practice to reuse Infrastructure in other OMG spec as much as possible. So now, we have three options. 1 Letting the decision of inheriting from Element to DI (i.e. leaving the spec as it is) 2 Adding the Image/Element generalization in the Profile spec. 3 Introducing "Image" as a primitive type Lets remind that all three solutions work. (good news ;-) The advantage of (1) is that it delegates entirely the responsibility of defining Image to DI. If we go fro (3), then: - It becomes a requirement for DI to reuse this Image definition - we have to add to the Infrastructure Primitive Types the Image type. (Who's responsibility is this?) - We do not rely on the DI uncertain process and solve everything immediately. If we solve the process of (3), then my order of preference would be (3), (1), (2) ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : jeudi 19 mai 2005 07:11 À : Branislav Selic; Jim Amsden Cc : Philippe.Desfray@softeam.fr; uml2-rtf@omg.org Objet : RE: [Profile] - set of issue resolution Jim wrote: > The DI specification should provide a way of associating images with stereotypes and there really should be no need to mention images in profiles at all. I say 'no': the DI spec is about exchanging diagram instances and not definitions of profiles. One should be able to associate an Image with a Stereotype in a Profile independently of, and prior to, drawing a diagram for a model having an Application of that profile (which is all that DI addresses). In fact DI has no notion of Profile or Stereotype and it's important to keep that independence. Bran wrote: > However, unless we have a concrete proposal for this, we should opt for solution 2. Firstly we need an answer to my question of why it might be useful to 'introspect' Image at all with some concrete scenarios. Failing such a justification there is no Issue to address IMHO and we can 'close no change'. I also made a concrete proposal of Image as a Primitive type. Philippe says it's not a Primitive type which is true now but need not remain so (and we have a small window to treat this as a shared Issue with DI FTF). We should look at the merits e.g. is an Image a value or an element? One advantage is that if Image is in the PrimitiveTypes library then it provides a means of having it available/shared in both DI and UML specs with minimal cross-dependencies between the specs. FWIW we have defined a Primitive type 'BLOB' in our MOF implementation (with some operations) and that has worked out very well. So 'Primitive' does not need to equate with 'simple': just that there is no internal structure of interest. > This may have been because the intent was to allow the DI spec to be used for other metamodels. But, I cannot say that with certainty. It was indeed the intent to allow DI to be used for any MOF metamodel. This is explicit in the spec. > The folks who know about DI are all gone. I was a co-submitter, and an implementer, of the DI spec as I have said several times recently. And I am not gone. Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com _____ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, May 19, 2005 12:49 AM To: Jim Amsden Cc: Pete Rivett; Philippe.Desfray@softeam.fr; uml2-rtf@omg.org Subject: RE: [Profile] - set of issue resolution >From what I recall, it was Philippe who suggested the addition of Image to the UML metamodel. I also recall that at the time, we were not very happy with this because it corrupted the architecturla principle of keeping UML agnostic and independent of DI. However, since we wanted to make profile definitions fully self-contained, we thought at the time that this necessarily implied that stereotype icons had to be in the UML side. If there is some other way of doing this, that would be great. However, unless we have a concrete proposal for this, we should opt for solution 2. I believe that the reason that LeafElement is not an Element was another architectural decision to keep the DI spec at arms length from the UML metamodel. This may have been because the intent was to allow the DI spec to be used for other metamodels. But, I cannot say that with certainty. The folks who know about DI are all gone. Bran Jim Amsden 05/18/2005 02:35 PM To cc "'Pete Rivett'" , uml2-rtf@omg.org Subject RE: [Profile] - set of issue resolution Philippe, I like your solution 1, and think it is an indication we might have been trying to solve the wrong problem. The issue arises because Stereotype has a navigable association to Image. The DI specification should provide a way of associating images with stereotypes and there really should be no need to mention images in profiles at all. "Desfray" 05/18/2005 12:01 PM Please respond to Philippe.Desfray To "'Pete Rivett'" , Jim Amsden/Raleigh/IBM@IBMUS cc Subject RE: [Profile] - set of issue resolution Thinking twice about it, I would like to recall the objective of this abstract Image metaclass: It is there to be further defined within the DI specification, where aditional information is added. In DI, an Image inherits from LeafElement which inherits from DiagramElements, all this having a couple of attributes. As far as can see (but I am puzzled with the DI spec, which seems uncomplete, without a detailed description of each class), DiagramElement does not inherit from Element. Image is not a primitive type, and the responsibility of its definition belongs to DI. Starting there, I see only two options: 1 Letting the decision of inheriting from Element to DI 2 Adding the Image/Element generalization in the Profile spec. I beleive that: 1 DiagramElement should generalize Element, and that is a DI issue. 2 Getting to the solution 2 would introduce an exception in the DI spec, and this is not desirable. It would be a trick, expecting that DI will fix it in some future. Unless we have a compelling Use Case to let Image generalize Element, we should go for option 1. And we are back to Pete's question: >>> What introspection did you envisage on Image? ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mercredi 18 mai 2005 17:23 À : Jim Amsden; Philippe.Desfray@softeam.fr Cc : uml2-rtf@omg.org Objet : RE: [Profile] - set of issue resolution Jim, I agree the current situation is not ideal as you suggest: the question is how do we resolve it? One approach which avoids UML itself getting too deep into image formats/processing is to keep it opaque and make Image an instance of PrimitiveType. What introspection did you envisage on Image? Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com _____ From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, May 18, 2005 12:42 PM To: Philippe.Desfray@softeam.fr Cc: uml2-rtf@omg.org Subject: RE: [Profile] - set of issue resolution Philippe, If Image is not an Element, then it cannot be introspected using MOF reflection. Tools based on MOF that want to work reflectively with profiles and DI may find this to be a restriction. If Image is simply a data value, they it would be a property of a Stereotype rather than a separate metaclass. If Image is more than just a URI reference, then it is at least a DataType and could benefit from reflection. "Desfray" 05/18/2005 03:54 AM Please respond to Philippe.Desfray To "'Pete Rivett'" , cc Subject RE: [Profile] - set of issue resolution Thanks for these feedbacks Pete, Here is an updated file with proposed resolutions. The "Image" resolution will need more discussion and are withdrawn: >>> Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Well I was hesitating on this point. My first approach was to leave that entirely to DI, and not to take any decision about Images. I though inheriting from Element was harmless, but you have a point here. Lets see if there are other opinions about it. >>> Issue 8596 ... Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. Well, it is not an instance diagram, it is a class diagram (being instances of CMOF metaclasses indeed,but the instance diagram would show instances of associations and would lead to a totally different picture). Mixing instance & class diagram would bring more confusion. This instance explaination can be added to the text, as I suggest in the updated resolution. >>>> Issue 8603: rather than addign text "OCL is not available", why not add the OCL? "Stereotype names should not clash with keywords" : how do you express keywords in OCL? I would not recommend to put here a predefined list of strings ... ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 17 mai 2005 21:47 À : Philippe.Desfray@softeam.fr; uml2-rtf@omg.org Objet : RE: [Profile] - set of issue resolution Here are some comments by issue number.... In general where there are changes made to the document they should be applied to the equivalent section in Infrastructure also. Issue 8256: I think the phrase 'at least one instance of the stereotype extension graph' is a bit cryptic: I suggest 'at least one instance of the stereotype or one of its subclasses' Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Issue 8453: Also needs the diagram (Figure 446) to be updated to show the redefined 'lower' property on ExtensionEnd. Issue 8596: It would be helpful to correct the start of the issue text and clarify that it is referring to the 'isRequired' attribute in section 18.3.2. I think the text of the spec needs correcting by replacing "The attribute value is derived from the multiplicity of Extension::ownedEnd" by "The attribute value is derived from the multiplicity of the Property referenced by Extension::ownedEnd". Adding OCL would be even better. Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. The diagram change in the current resolution should be to add "{redefines ownedEnd}" as opposed to "{subsets ownedEnd}". This is already reflected in 18.3.2 so the 2nd change is not necessary at all. Issue 8598: the '/' indicates that the Association is derived so I do not see any reason to remove it. This is official notation for a derived Assoaiction (see 2nd bullet on p39). Isue 8600: "{subsets type}" should be "{redefines type}" as in the Issue and as in the text of 18.3.3. hence the change " In ExtensionEnd, Association, type Add subsets TypedElement::type." is redundant and wrong. Rather than deleting "which was 1" completely, it might be useful to replace it by "which normally, for MultiplicityElements, evaluates to 1 if empty" Issue 8601: I disagree with removing the notation option of allowing '1' instead of {required}. This is not fixing a real problem and introducing such incompatibilities (it invalidates some diagrams, and tools, which are currently valid) is not something an RTF should be doing in the absence of a compelling reason. Issue 8603: rather than addign text "OCL is not available", why not add the OCL? Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Desfray [ mailto:Philippe.Desfray@softeam.fr ] > Sent: Tuesday, May 17, 2005 6:07 PM > To: uml2-rtf@omg.org > Subject: [Profile] - set of issue resolution > > Dear all, > For the next resolution thread, and to the particular attention of the > Profile WG > > Here is the thread of numerous and easy issues (typos, light > issues) for > profiles. The remaining issues will stem from the teleconf > of the 20th on > Profile. > > To be integrated in the Ballot 4 if everyone is enthousiast with these > resolutions. > Best regards > > ==================================== > Philippe Desfray > VP for R&D - SOFTEAM > Tel: (33) 01 53968400 > Fax: (33) 01 53968401 > 144 Av. des champs Elysées 75008 PARIS > www.softeam.com > www.objecteering.com > [attachment "winmail.dat" deleted by Branislav Selic/Ottawa/IBM] winmail8.dat To: "Pete Rivett" Cc: "Branislav Selic" , Philippe.Desfray@softeam.fr, uml2-rtf@omg.org Subject: RE: [Profile] - set of issue resolution X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Thu, 19 May 2005 11:13:37 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 05/19/2005 09:13:50, Serialize complete at 05/19/2005 09:13:50 Pete, Yes, I think you are correct. Stereotype images can't just be a DI concern. Its hard to say what introspection tools might want to do with Image since it has little definition. If it were a primitive type, or a string, used as a stereotype property, then this would be fine. If it remains a metaclass, then it should probably be an Element. Then whatever it becomes can be introspected. I like your idea of making it a PrimitiveType since that's essentially the way Profiles uses it. The only reason for it not being a primitive type is if we decide either now or in some future revision to add properties and operations to it. One could imagine some pretty rich Image properties and behaviors given common uses of images. "Pete Rivett" 05/19/2005 01:11 AM To "Branislav Selic" , Jim Amsden/Raleigh/IBM@IBMUS cc , Subject RE: [Profile] - set of issue resolution Jim wrote: > The DI specification should provide a way of associating images with stereotypes and there really should be no need to mention images in profiles at all. I say 'no': the DI spec is about exchanging diagram instances and not definitions of profiles. One should be able to associate an Image with a Stereotype in a Profile independently of, and prior to, drawing a diagram for a model having an Application of that profile (which is all that DI addresses). In fact DI has no notion of Profile or Stereotype and it's important to keep that independence. Bran wrote: > However, unless we have a concrete proposal for this, we should opt for solution 2. Firstly we need an answer to my question of why it might be useful to 'introspect' Image at all with some concrete scenarios. Failing such a justification there is no Issue to address IMHO and we can 'close no change'. I also made a concrete proposal of Image as a Primitive type. Philippe says it's not a Primitive type which is true now but need not remain so (and we have a small window to treat this as a shared Issue with DI FTF). We should look at the merits e.g. is an Image a value or an element? One advantage is that if Image is in the PrimitiveTypes library then it provides a means of having it available/shared in both DI and UML specs with minimal cross-dependencies between the specs. FWIW we have defined a Primitive type 'BLOB' in our MOF implementation (with some operations) and that has worked out very well. So 'Primitive' does not need to equate with 'simple': just that there is no internal structure of interest. > This may have been because the intent was to allow the DI spec to be used for other metamodels. But, I cannot say that with certainty. It was indeed the intent to allow DI to be used for any MOF metamodel. This is explicit in the spec. > The folks who know about DI are all gone. I was a co-submitter, and an implementer, of the DI spec as I have said several times recently. And I am not gone. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, May 19, 2005 12:49 AM To: Jim Amsden Cc: Pete Rivett; Philippe.Desfray@softeam.fr; uml2-rtf@omg.org Subject: RE: [Profile] - set of issue resolution >From what I recall, it was Philippe who suggested the addition of Image to the UML metamodel. I also recall that at the time, we were not very happy with this because it corrupted the architecturla principle of keeping UML agnostic and independent of DI. However, since we wanted to make profile definitions fully self-contained, we thought at the time that this necessarily implied that stereotype icons had to be in the UML side. If there is some other way of doing this, that would be great. However, unless we have a concrete proposal for this, we should opt for solution 2. I believe that the reason that LeafElement is not an Element was another architectural decision to keep the DI spec at arms length from the UML metamodel. This may have been because the intent was to allow the DI spec to be used for other metamodels. But, I cannot say that with certainty. The folks who know about DI are all gone. Bran Jim Amsden 05/18/2005 02:35 PM To cc "'Pete Rivett'" , uml2-rtf@omg.org Subject RE: [Profile] - set of issue resolution Philippe, I like your solution 1, and think it is an indication we might have been trying to solve the wrong problem. The issue arises because Stereotype has a navigable association to Image. The DI specification should provide a way of associating images with stereotypes and there really should be no need to mention images in profiles at all. "Desfray" 05/18/2005 12:01 PM Please respond to Philippe.Desfray To "'Pete Rivett'" , Jim Amsden/Raleigh/IBM@IBMUS cc Subject RE: [Profile] - set of issue resolution Thinking twice about it, I would like to recall the objective of this abstract Image metaclass: It is there to be further defined within the DI specification, where aditional information is added. In DI, an Image inherits from LeafElement which inherits from DiagramElements, all this having a couple of attributes. As far as can see (but I am puzzled with the DI spec, which seems uncomplete, without a detailed description of each class), DiagramElement does not inherit from Element. Image is not a primitive type, and the responsibility of its definition belongs to DI. Starting there, I see only two options: 1 Letting the decision of inheriting from Element to DI 2 Adding the Image/Element generalization in the Profile spec. I beleive that: 1 DiagramElement should generalize Element, and that is a DI issue. 2 Getting to the solution 2 would introduce an exception in the DI spec, and this is not desirable. It would be a trick, expecting that DI will fix it in some future. Unless we have a compelling Use Case to let Image generalize Element, we should go for option 1. And we are back to Pete's question: >>> What introspection did you envisage on Image? ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mercredi 18 mai 2005 17:23 À : Jim Amsden; Philippe.Desfray@softeam.fr Cc : uml2-rtf@omg.org Objet : RE: [Profile] - set of issue resolution Jim, I agree the current situation is not ideal as you suggest: the question is how do we resolve it? One approach which avoids UML itself getting too deep into image formats/processing is to keep it opaque and make Image an instance of PrimitiveType. What introspection did you envisage on Image? Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com _____ From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, May 18, 2005 12:42 PM To: Philippe.Desfray@softeam.fr Cc: uml2-rtf@omg.org Subject: RE: [Profile] - set of issue resolution Philippe, If Image is not an Element, then it cannot be introspected using MOF reflection. Tools based on MOF that want to work reflectively with profiles and DI may find this to be a restriction. If Image is simply a data value, they it would be a property of a Stereotype rather than a separate metaclass. If Image is more than just a URI reference, then it is at least a DataType and could benefit from reflection. "Desfray" 05/18/2005 03:54 AM Please respond to Philippe.Desfray To "'Pete Rivett'" , cc Subject RE: [Profile] - set of issue resolution Thanks for these feedbacks Pete, Here is an updated file with proposed resolutions. The "Image" resolution will need more discussion and are withdrawn: >>> Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Well I was hesitating on this point. My first approach was to leave that entirely to DI, and not to take any decision about Images. I though inheriting from Element was harmless, but you have a point here. Lets see if there are other opinions about it. >>> Issue 8596 ... Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. Well, it is not an instance diagram, it is a class diagram (being instances of CMOF metaclasses indeed,but the instance diagram would show instances of associations and would lead to a totally different picture). Mixing instance & class diagram would bring more confusion. This instance explaination can be added to the text, as I suggest in the updated resolution. >>>> Issue 8603: rather than addign text "OCL is not available", why not add the OCL? "Stereotype names should not clash with keywords" : how do you express keywords in OCL? I would not recommend to put here a predefined list of strings ... ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 17 mai 2005 21:47 À : Philippe.Desfray@softeam.fr; uml2-rtf@omg.org Objet : RE: [Profile] - set of issue resolution Here are some comments by issue number.... In general where there are changes made to the document they should be applied to the equivalent section in Infrastructure also. Issue 8256: I think the phrase 'at least one instance of the stereotype extension graph' is a bit cryptic: I suggest 'at least one instance of the stereotype or one of its subclasses' Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Issue 8453: Also needs the diagram (Figure 446) to be updated to show the redefined 'lower' property on ExtensionEnd. Issue 8596: It would be helpful to correct the start of the issue text and clarify that it is referring to the 'isRequired' attribute in section 18.3.2. I think the text of the spec needs correcting by replacing "The attribute value is derived from the multiplicity of Extension::ownedEnd" by "The attribute value is derived from the multiplicity of the Property referenced by Extension::ownedEnd". Adding OCL would be even better. Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. The diagram change in the current resolution should be to add "{redefines ownedEnd}" as opposed to "{subsets ownedEnd}". This is already reflected in 18.3.2 so the 2nd change is not necessary at all. Issue 8598: the '/' indicates that the Association is derived so I do not see any reason to remove it. This is official notation for a derived Assoaiction (see 2nd bullet on p39). Isue 8600: "{subsets type}" should be "{redefines type}" as in the Issue and as in the text of 18.3.3. hence the change " In ExtensionEnd, Association, type Add subsets TypedElement::type." is redundant and wrong. Rather than deleting "which was 1" completely, it might be useful to replace it by "which normally, for MultiplicityElements, evaluates to 1 if empty" Issue 8601: I disagree with removing the notation option of allowing '1' instead of {required}. This is not fixing a real problem and introducing such incompatibilities (it invalidates some diagrams, and tools, which are currently valid) is not something an RTF should be doing in the absence of a compelling reason. Issue 8603: rather than addign text "OCL is not available", why not add the OCL? Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Desfray [ mailto:Philippe.Desfray@softeam.fr ] > Sent: Tuesday, May 17, 2005 6:07 PM > To: uml2-rtf@omg.org > Subject: [Profile] - set of issue resolution > > Dear all, > For the next resolution thread, and to the particular attention of the > Profile WG > > Here is the thread of numerous and easy issues (typos, light > issues) for > profiles. The remaining issues will stem from the teleconf > of the 20th on > Profile. > > To be integrated in the Ballot 4 if everyone is enthousiast with these > resolutions. > Best regards > > ==================================== > Philippe Desfray > VP for R&D - SOFTEAM > Tel: (33) 01 53968400 > Fax: (33) 01 53968401 > 144 Av. des champs Elysées 75008 PARIS > www.softeam.com > www.objecteering.com > [attachment "winmail.dat" deleted by Branislav Selic/Ottawa/IBM] To: Jim Amsden Cc: "Pete Rivett" , Philippe.Desfray@softeam.fr, uml2-rtf@omg.org Subject: RE: [Profile] - set of issue resolution X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 19 May 2005 11:35:22 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.53HF247 | January 6, 2005) at 05/19/2005 11:35:26, Serialize complete at 05/19/2005 11:35:26 Another possibility seems to be to model Image simply as a generic DataType (which is a concrete metaclass in the spec). Its interpretation comes from Stereotype::icon. That avoids introducing yet another primitive data type. Bran Jim Amsden 05/19/2005 11:13 AM To "Pete Rivett" cc Branislav Selic/Ottawa/IBM@IBMCA, Philippe.Desfray@softeam.fr, uml2-rtf@omg.org Subject RE: [Profile] - set of issue resolution Pete, Yes, I think you are correct. Stereotype images can't just be a DI concern. Its hard to say what introspection tools might want to do with Image since it has little definition. If it were a primitive type, or a string, used as a stereotype property, then this would be fine. If it remains a metaclass, then it should probably be an Element. Then whatever it becomes can be introspected. I like your idea of making it a PrimitiveType since that's essentially the way Profiles uses it. The only reason for it not being a primitive type is if we decide either now or in some future revision to add properties and operations to it. One could imagine some pretty rich Image properties and behaviors given common uses of images. "Pete Rivett" 05/19/2005 01:11 AM To "Branislav Selic" , Jim Amsden/Raleigh/IBM@IBMUS cc , Subject RE: [Profile] - set of issue resolution Jim wrote: > The DI specification should provide a way of associating images with stereotypes and there really should be no need to mention images in profiles at all. I say 'no': the DI spec is about exchanging diagram instances and not definitions of profiles. One should be able to associate an Image with a Stereotype in a Profile independently of, and prior to, drawing a diagram for a model having an Application of that profile (which is all that DI addresses). In fact DI has no notion of Profile or Stereotype and it's important to keep that independence. Bran wrote: > However, unless we have a concrete proposal for this, we should opt for solution 2. Firstly we need an answer to my question of why it might be useful to 'introspect' Image at all with some concrete scenarios. Failing such a justification there is no Issue to address IMHO and we can 'close no change'. I also made a concrete proposal of Image as a Primitive type. Philippe says it's not a Primitive type which is true now but need not remain so (and we have a small window to treat this as a shared Issue with DI FTF). We should look at the merits e.g. is an Image a value or an element? One advantage is that if Image is in the PrimitiveTypes library then it provides a means of having it available/shared in both DI and UML specs with minimal cross-dependencies between the specs. FWIW we have defined a Primitive type 'BLOB' in our MOF implementation (with some operations) and that has worked out very well. So 'Primitive' does not need to equate with 'simple': just that there is no internal structure of interest. > This may have been because the intent was to allow the DI spec to be used for other metamodels. But, I cannot say that with certainty. It was indeed the intent to allow DI to be used for any MOF metamodel. This is explicit in the spec. > The folks who know about DI are all gone. I was a co-submitter, and an implementer, of the DI spec as I have said several times recently. And I am not gone. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, May 19, 2005 12:49 AM To: Jim Amsden Cc: Pete Rivett; Philippe.Desfray@softeam.fr; uml2-rtf@omg.org Subject: RE: [Profile] - set of issue resolution >From what I recall, it was Philippe who suggested the addition of Image to the UML metamodel. I also recall that at the time, we were not very happy with this because it corrupted the architecturla principle of keeping UML agnostic and independent of DI. However, since we wanted to make profile definitions fully self-contained, we thought at the time that this necessarily implied that stereotype icons had to be in the UML side. If there is some other way of doing this, that would be great. However, unless we have a concrete proposal for this, we should opt for solution 2. I believe that the reason that LeafElement is not an Element was another architectural decision to keep the DI spec at arms length from the UML metamodel. This may have been because the intent was to allow the DI spec to be used for other metamodels. But, I cannot say that with certainty. The folks who know about DI are all gone. Bran Jim Amsden 05/18/2005 02:35 PM To cc "'Pete Rivett'" , uml2-rtf@omg.org Subject RE: [Profile] - set of issue resolution Philippe, I like your solution 1, and think it is an indication we might have been trying to solve the wrong problem. The issue arises because Stereotype has a navigable association to Image. The DI specification should provide a way of associating images with stereotypes and there really should be no need to mention images in profiles at all. "Desfray" 05/18/2005 12:01 PM Please respond to Philippe.Desfray To "'Pete Rivett'" , Jim Amsden/Raleigh/IBM@IBMUS cc Subject RE: [Profile] - set of issue resolution Thinking twice about it, I would like to recall the objective of this abstract Image metaclass: It is there to be further defined within the DI specification, where aditional information is added. In DI, an Image inherits from LeafElement which inherits from DiagramElements, all this having a couple of attributes. As far as can see (but I am puzzled with the DI spec, which seems uncomplete, without a detailed description of each class), DiagramElement does not inherit from Element. Image is not a primitive type, and the responsibility of its definition belongs to DI. Starting there, I see only two options: 1 Letting the decision of inheriting from Element to DI 2 Adding the Image/Element generalization in the Profile spec. I beleive that: 1 DiagramElement should generalize Element, and that is a DI issue. 2 Getting to the solution 2 would introduce an exception in the DI spec, and this is not desirable. It would be a trick, expecting that DI will fix it in some future. Unless we have a compelling Use Case to let Image generalize Element, we should go for option 1. And we are back to Pete's question: >>> What introspection did you envisage on Image? ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mercredi 18 mai 2005 17:23 À : Jim Amsden; Philippe.Desfray@softeam.fr Cc : uml2-rtf@omg.org Objet : RE: [Profile] - set of issue resolution Jim, I agree the current situation is not ideal as you suggest: the question is how do we resolve it? One approach which avoids UML itself getting too deep into image formats/processing is to keep it opaque and make Image an instance of PrimitiveType. What introspection did you envisage on Image? Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com _____ From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, May 18, 2005 12:42 PM To: Philippe.Desfray@softeam.fr Cc: uml2-rtf@omg.org Subject: RE: [Profile] - set of issue resolution Philippe, If Image is not an Element, then it cannot be introspected using MOF reflection. Tools based on MOF that want to work reflectively with profiles and DI may find this to be a restriction. If Image is simply a data value, they it would be a property of a Stereotype rather than a separate metaclass. If Image is more than just a URI reference, then it is at least a DataType and could benefit from reflection. "Desfray" 05/18/2005 03:54 AM Please respond to Philippe.Desfray To "'Pete Rivett'" , cc Subject RE: [Profile] - set of issue resolution Thanks for these feedbacks Pete, Here is an updated file with proposed resolutions. The "Image" resolution will need more discussion and are withdrawn: >>> Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Well I was hesitating on this point. My first approach was to leave that entirely to DI, and not to take any decision about Images. I though inheriting from Element was harmless, but you have a point here. Lets see if there are other opinions about it. >>> Issue 8596 ... Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. Well, it is not an instance diagram, it is a class diagram (being instances of CMOF metaclasses indeed,but the instance diagram would show instances of associations and would lead to a totally different picture). Mixing instance & class diagram would bring more confusion. This instance explaination can be added to the text, as I suggest in the updated resolution. >>>> Issue 8603: rather than addign text "OCL is not available", why not add the OCL? "Stereotype names should not clash with keywords" : how do you express keywords in OCL? I would not recommend to put here a predefined list of strings ... ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 17 mai 2005 21:47 À : Philippe.Desfray@softeam.fr; uml2-rtf@omg.org Objet : RE: [Profile] - set of issue resolution Here are some comments by issue number.... In general where there are changes made to the document they should be applied to the equivalent section in Infrastructure also. Issue 8256: I think the phrase 'at least one instance of the stereotype extension graph' is a bit cryptic: I suggest 'at least one instance of the stereotype or one of its subclasses' Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Issue 8453: Also needs the diagram (Figure 446) to be updated to show the redefined 'lower' property on ExtensionEnd. Issue 8596: It would be helpful to correct the start of the issue text and clarify that it is referring to the 'isRequired' attribute in section 18.3.2. I think the text of the spec needs correcting by replacing "The attribute value is derived from the multiplicity of Extension::ownedEnd" by "The attribute value is derived from the multiplicity of the Property referenced by Extension::ownedEnd". Adding OCL would be even better. Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. The diagram change in the current resolution should be to add "{redefines ownedEnd}" as opposed to "{subsets ownedEnd}". This is already reflected in 18.3.2 so the 2nd change is not necessary at all. Issue 8598: the '/' indicates that the Association is derived so I do not see any reason to remove it. This is official notation for a derived Assoaiction (see 2nd bullet on p39). Isue 8600: "{subsets type}" should be "{redefines type}" as in the Issue and as in the text of 18.3.3. hence the change " In ExtensionEnd, Association, type Add subsets TypedElement::type." is redundant and wrong. Rather than deleting "which was 1" completely, it might be useful to replace it by "which normally, for MultiplicityElements, evaluates to 1 if empty" Issue 8601: I disagree with removing the notation option of allowing '1' instead of {required}. This is not fixing a real problem and introducing such incompatibilities (it invalidates some diagrams, and tools, which are currently valid) is not something an RTF should be doing in the absence of a compelling reason. Issue 8603: rather than addign text "OCL is not available", why not add the OCL? Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Desfray [ mailto:Philippe.Desfray@softeam.fr ] > Sent: Tuesday, May 17, 2005 6:07 PM > To: uml2-rtf@omg.org > Subject: [Profile] - set of issue resolution > > Dear all, > For the next resolution thread, and to the particular attention of the > Profile WG > > Here is the thread of numerous and easy issues (typos, light > issues) for > profiles. The remaining issues will stem from the teleconf > of the 20th on > Profile. > > To be integrated in the Ballot 4 if everyone is enthousiast with these > resolutions. > Best regards > > ==================================== > Philippe Desfray > VP for R&D - SOFTEAM > Tel: (33) 01 53968400 > Fax: (33) 01 53968401 > 144 Av. des champs Elysées 75008 PARIS > www.softeam.com > www.objecteering.com > [attachment "winmail.dat" deleted by Branislav Selic/Ottawa/IBM] Subject: RE: Second version of draft 5 ballot Date: Fri, 10 Jun 2005 12:49:21 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Second version of draft 5 ballot Thread-Index: AcVqDi4LnbIGtvCzTnu2ZkZCe2GoggDuTiyQ Priority: Urgent From: "Pete Rivett" To: "Branislav Selic" , X-Virus-Scanned: by amavisd-new at sentraliant.com See below. Quite a few comments but all minor except for issue 8449 which I think should be pulled. 7756 The heading 'Discussion' should be replaced by 'Revised Text'. The issue replaces several paragraphs so instead of "change the paragraph " should say "replace the following text". The corresponding text in Infra also needs updating. 7756: the English for the new text could be improved, and I think 'a usual class' is not clear. Also 'navigable' is used in the old sense not the new sense: I presume the intention is the old sense (that there is a property on the Stereotype) Here is suggested new text (my changes in red) Stereotypes can participate in associations. The opposite class can be another stereotype, a non-Stereotype class that is owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than the other class/metaclass. Issue 8031: I don't think the interaction between Conrad and Bran belongs in the discussion. See my proposed guidance in my vote on Ballot 4 (earlier today). Issue 8117: ditto. Issue 8187, 8239, 8262: Would be better to use the proper syntax to express the 'subsets' Issue 8225, 8262, others: Was it intentional to replace [0..*] by [*]? I thought the preferred style was the former. More generally, we seem to be spending a lot of cycles faffing around with issues related to * and 0..* - do people not realize that they are identical? Issue 8234: ditto Issue 8256: Use of 'at least' implies than more than one instance of stereotype may be attached to a single element. Suggested rewording: "If the extending stereotype has subclasses, then at one instance of the stereotype or one of its subclasses is required." Issue 8301: Should say 'increased clarity' not 'increased clarify'. Issue 8449: As I said in the discussion within the Profiles group I think Image should be a PrimitiveType. Even if Image is an instance of DataType rather than PrimitiveType the proposed resolution does not reflect this and in fact makes no sense as it stands since it is at the wrong metalevel: it would allow a Stereotype to refer, as an image to an actual datatype in the UML metamodel (or a user model) - for example 'Integer' or 'AddressType'! I will follow up with more detailed email but I think this issue must be pulled from ballot for now. Issue 8608: The Revised text says ", replace .intended. by the word .intended." - the first 'intended' should be 'intedded' The disposition should be 'Resolved' not 'closed no change' Issue 8619: I think a portion of the 'Discussion' could be added to clarify the diagram in Appendix F. I propose the following: Revised Text: Add the following to the end of the first (and only) paragraph in Appendix F The .classes. in this diagram that do not have superclasses are actually merge increments. Their superclasses can be inferred from any increment that actually has a superclass. Putting those in the diagram would not add any information but would simply clutter the diagram. Issue 8824: Did we not already address this in Ballot 4 with issue 8349 ( I have not checked the detail though)? Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Sunday, June 05, 2005 9:17 PM To: uml2-rtf@omg.org Subject: Second version of draft 5 ballot I am having problems with my mailer that is having trouble sending larger files. It looks like my previous post of the ballot 5 draft did not get through. So, I'm sending this new ZIPPED version (however, to get around the OMG aversion to Zipped files, I have given it a "zap" suffix -- which you should change bck to "zip" when you receive the file.) For those who may have received the original version, this one is different in that it has added Tim Weilkins' fix to issue 8467. Bran