Issue 4946: UML 1.4.1 should use MOF 1.4 (uml2-superstructure-ftf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Uncategorized Issue Severity: Summary: In the case of MOF 1.4 there are far more important reasons for moving to it. The main change in MOF 1.4 is a 'proper' modeled datatype system as opposed to CORBA datatypes hidden away in typeCodes. Because of this: a) MOF 1.4 is the basis of the Java Metadata Interface (JMI) which provides Java APIs to metamodels and is being adopted by a number of repository and UML tool vendors. Without an official version of UML expressed in MOF 1.4 people will have to do their own conversion with subsequent interoperability problems b) MOF 1.4 is also the basis of XMI 1.2 and XMI 2.0 (XMI for XML Schemas). Without being expressed in MOF 1.4, the UML interchange definition cannot be expressed as an XML Schema. c) the proper datatype model provides the opportunity to 'clean up' a number of datatype-related issues in UML (e.g. issue 4452). And represent UML's datatypes such as Multiplicity and MultiplicityRange as MOF (structure) datatypes rather than MOF classes. I would expect this to only affect the UML 1.4.1 Concrete metamodel. I would be willing to draft a proposal for this. Is there a version of this with already-agreed 1.4.1 changes incorporated? Resolution: Revised Text: Actions taken: March 7, 2002: received issue March 9, 2005: closed issue Discussion: UML 2.0 is now aligned with MOF 2 so this issue does not apply. Disposition: Closed, no change End of Annotations:===== From: "Pete Rivett" To: Cc: Subject: UML 1.4.1 should use MOF 1.4 Date: Thu, 7 Mar 2002 00:55:18 -0000 Message-ID: <007e01c1c572$c11d6fc0$114c04c8@CHIMAY> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 446!!;E$!!DaOd9m-Ce9 I'm raising this just in case: I'd have hoped it would be normal practice to use the latest approved version of an 'underlying' standard. In the case of MOF 1.4 there are far more important reasons for moving to it. The main change in MOF 1.4 is a 'proper' modeled datatype system as opposed to CORBA datatypes hidden away in typeCodes. Because of this: a) MOF 1.4 is the basis of the Java Metadata Interface (JMI) which provides Java APIs to metamodels and is being adopted by a number of repository and UML tool vendors. Without an official version of UML expressed in MOF 1.4 people will have to do their own conversion with subsequent interoperability problems b) MOF 1.4 is also the basis of XMI 1.2 and XMI 2.0 (XMI for XML Schemas). Without being expressed in MOF 1.4, the UML interchange definition cannot be expressed as an XML Schema. c) the proper datatype model provides the opportunity to 'clean up' a number of datatype-related issues in UML (e.g. issue 4452). And represent UML's datatypes such as Multiplicity and MultiplicityRange as MOF (structure) datatypes rather than MOF classes. I would expect this to only affect the UML 1.4.1 Concrete metamodel. I would be willing to draft a proposal for this. Is there a version of this with already-agreed 1.4.1 changes incorporated? Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd 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 The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. From: "Martin Matula" To: "Pete Rivett" , Cc: References: <007e01c1c572$c11d6fc0$114c04c8@CHIMAY> Subject: Re: UML 1.4.1 should use MOF 1.4 Date: Thu, 7 Mar 2002 09:04:37 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: f@Od958&e95cK!!UH#!! Another important thing needed for interoperability between the JMI implementations is to include JMI tags (javax.jmi.packagePrefix and javax.jmi.substituteName) in a similar way that IDL tags are included to ensure that the Java interfaces are in the correct package and that they are compilable (there are no name conflicts). Pete, if you decide to do this work and if the RTF members agree to move to MOF 1.4, I am willing to help you by validating the XMI files to make sure that they are valid MOF 1.4 files and that the JMI interfaces generated from these files are OK. Martin ----- Original Message ----- From: "Pete Rivett" To: Cc: Sent: Thursday, March 07, 2002 1:55 AM Subject: UML 1.4.1 should use MOF 1.4 > I'm raising this just in case: I'd have hoped it would be normal practice > to use the latest approved version of an 'underlying' standard. > > In the case of MOF 1.4 there are far more important reasons for moving to > it. The main change in MOF 1.4 is a 'proper' modeled datatype system as > opposed to CORBA datatypes hidden away in typeCodes. Because of this: > a) MOF 1.4 is the basis of the Java Metadata Interface (JMI) which provides > Java APIs to metamodels and is being adopted by a number of repository and > UML tool vendors. Without an official version of UML expressed in MOF 1.4 > people will have to do their own conversion with subsequent interoperability > problems > > b) MOF 1.4 is also the basis of XMI 1.2 and XMI 2.0 (XMI for XML Schemas). > Without being expressed in MOF 1.4, the UML interchange definition cannot be > expressed as an XML Schema. > > c) the proper datatype model provides the opportunity to 'clean up' a > number of datatype-related issues in UML (e.g. issue 4452). And represent > UML's datatypes such as Multiplicity and MultiplicityRange as MOF > (structure) datatypes rather than MOF classes. > > I would expect this to only affect the UML 1.4.1 Concrete metamodel. I would > be willing to draft a proposal for this. Is there a version of this with > already-agreed 1.4.1 changes incorporated? > > > Pete Rivett (pete.rivett@adaptive.com) > Chief Technology Officer, Adaptive Ltd > 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 > > > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. > > If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. > > Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. > From: "Iyengar, Sridhar" To: Martin Matula , Pete Rivett , issues@omg.org Cc: uml-rtf@omg.org Subject: RE: UML 1.4.1 should use MOF 1.4 Date: Fri, 8 Mar 2002 12:07:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ;(9!!K]ld9!Q)!!#1/!! Martin/Pete Thanks for stepping up to this important work. Good news - based on the work done in UML 1.4 (where we defined a MOF compliant interchange model for UML), this work should be straightforward. Also since the changes proposed in 1.4.1 so far are editorial and minor changes to wellformedness rules (i.e no metamodel changes in terms of new classes, attributes or associations)- it may be possible for vendors that support the UML 1.4 XML DTD to continue to use it. Sridhar ------------------------------------------------------------------------ ---- Sridhar Iyengar Unisys Fellow, Director of Advanced Technology 25725, Jeronimo Road Mission Viejo, CA 92691 E-mail : Sridhar.iyengar2@unisys.com Phone : 949-380-5692 Fax : 949-380-6632 ------------------------------------------------------------------------ -------------- > -----Original Message----- > From: Martin Matula [mailto:martin.matula@sun.com] > Sent: Thursday, March 07, 2002 12:05 AM > To: Pete Rivett; issues@omg.org > Cc: uml-rtf@omg.org > Subject: Re: UML 1.4.1 should use MOF 1.4 > > > Another important thing needed for interoperability between the JMI > implementations is to include JMI tags (javax.jmi.packagePrefix and > javax.jmi.substituteName) in a similar way that IDL tags are > included to > ensure that the Java interfaces are in the correct package > and that they are > compilable (there are no name conflicts). > Pete, if you decide to do this work and if the RTF members > agree to move to > MOF 1.4, I am willing to help you by validating the XMI files > to make sure > that they are valid MOF 1.4 files and that the JMI interfaces > generated from > these files are OK. > Martin > > ----- Original Message ----- > From: "Pete Rivett" > To: > Cc: > Sent: Thursday, March 07, 2002 1:55 AM > Subject: UML 1.4.1 should use MOF 1.4 > > > > I'm raising this just in case: I'd have hoped it would be > normal practice > > to use the latest approved version of an 'underlying' standard. > > > > In the case of MOF 1.4 there are far more important reasons > for moving to > > it. The main change in MOF 1.4 is a 'proper' modeled > datatype system as > > opposed to CORBA datatypes hidden away in typeCodes. > Because of this: > > a) MOF 1.4 is the basis of the Java Metadata Interface (JMI) which > provides > > Java APIs to metamodels and is being adopted by a number of > repository and > > UML tool vendors. Without an official version of UML > expressed in MOF 1.4 > > people will have to do their own conversion with subsequent > interoperability > > problems > > > > b) MOF 1.4 is also the basis of XMI 1.2 and XMI 2.0 (XMI for XML > Schemas). > > Without being expressed in MOF 1.4, the UML interchange > definition cannot > be > > expressed as an XML Schema. > > > > c) the proper datatype model provides the opportunity to > 'clean up' a > > number of datatype-related issues in UML (e.g. issue 4452). > And represent > > UML's datatypes such as Multiplicity and MultiplicityRange as MOF > > (structure) datatypes rather than MOF classes. > > > > I would expect this to only affect the UML 1.4.1 Concrete > metamodel. I > would > > be willing to draft a proposal for this. Is there a version > of this with > > already-agreed 1.4.1 changes incorporated? > > > > > > Pete Rivett (pete.rivett@adaptive.com) > > Chief Technology Officer, Adaptive Ltd > > 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 > > > > > > > > The information contained in this email and any attached files are > confidential and intended solely for the addressee(s). The > e-mail may be > legally privileged or prohibited from disclosure and unauthorised use. > > > > If you are not the named addressee you may not use, copy or > disclose this > information to any other person. If you received this > message in error > please notify the sender immediately. > > > > Any views or opinions presented here may be solely those of > the originator > and do not necessarily reflect those of the Company. > > > From: "Pete Rivett" To: "'Iyengar, Sridhar'" , "'Martin Matula'" , Subject: RE: Issue 4946 UML 1.4.1 should use MOF 1.4 - proposed resolution Date: Fri, 8 Mar 2002 19:41:40 -0000 Message-ID: <003d01c1c6d9$45394ab0$114c04c8@CHIMAY> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <529ED587BF6FB24B88F9085D719C548F81F117@USMV-EXCH3.na.uis.unisys.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Gl&!!"A=!!Je!e9L$"e9 Sridhar, You're right - the changes for MOF 1.4 are less substantial than I had expected - especially since UML 1.4 already uses the MOF 1.4 notation for enumerations. In detail these are the changes I propose: - add the JMI-specific tags for prefixes etc. - import the MOF PrimitiveTypes package - Convert the existing UML datatypes (all in the Data_Types package). The MOF primitives and enumerations are obvious, the others I propose as follows: a) Name -> AliasType referring to String b) LocationReference -> AliasType referring to String c) UnlimitedInteger -> AliasType referring to Long (this is based on the current CORBA typecode) d) Geometry -> AliasType referring to String e) MultiplicityRange -> StructureType with 'upper' and 'lower' Fields f) Multiplicity -> CollectionType (1..*, ordered, not unique) of MultiplicityRange g) Expression -> StructureType with 'language' and 'body' Fields h) subtypes of Expression -> AliasTypes referring to Expression (MOF does not support inheritiance of DataTypes) An option would be to reconcile better with UML's own model of DataTypes (classes DataType, Primitive, Enumeration, EnumerationLiteral) as in Issue 4452. However this does not seem to meet the UML 1.4.1 aim of minimal change so I do not propose this. The changes in the DTD and XMI should be minimal but they will end up with an XMI version of '1.2'. If this is felt to be a major problem we could have alternative Concrete model variants for MOF 1.3/XMI 1.1 and MOF 1.4/XMI 1.2 which is not ideal but workable. For management purposes it would be better if these had distinguishable UML version numbers e.g. 1.4.1 and 1.4.2 or 1.4.1a and 1.4.1b. Pete Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd 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: Iyengar, Sridhar [mailto:Sridhar.Iyengar2@unisys.com] > Sent: 08 March 2002 18:08 > To: Martin Matula; Pete Rivett; issues@omg.org > Cc: uml-rtf@omg.org > Subject: RE: UML 1.4.1 should use MOF 1.4 > > > Martin/Pete > > Thanks for stepping up to this important work. > > Good news - based on the work done in UML 1.4 (where we defined a MOF > compliant interchange model for UML), this work should be > straightforward. > > Also since the changes proposed in 1.4.1 so far are editorial > and minor > changes to wellformedness rules (i.e no metamodel changes in > terms of new > classes, attributes or associations)- it may be possible for > vendors that > support the UML 1.4 XML DTD to continue to use it. > > Sridhar > > -------------------------------------------------------------- > ---------- > ---- > Sridhar Iyengar > Unisys Fellow, Director of Advanced Technology > 25725, Jeronimo Road > Mission Viejo, CA 92691 > > E-mail : Sridhar.iyengar2@unisys.com > Phone : 949-380-5692 > Fax : 949-380-6632 > -------------------------------------------------------------- > ---------- > -------------- > > > > > > -----Original Message----- > > From: Martin Matula [mailto:martin.matula@sun.com] > > Sent: Thursday, March 07, 2002 12:05 AM > > To: Pete Rivett; issues@omg.org > > Cc: uml-rtf@omg.org > > Subject: Re: UML 1.4.1 should use MOF 1.4 > > > > > > Another important thing needed for interoperability between the JMI > > implementations is to include JMI tags (javax.jmi.packagePrefix and > > javax.jmi.substituteName) in a similar way that IDL tags are > > included to > > ensure that the Java interfaces are in the correct package > > and that they are > > compilable (there are no name conflicts). > > Pete, if you decide to do this work and if the RTF members > > agree to move to > > MOF 1.4, I am willing to help you by validating the XMI files > > to make sure > > that they are valid MOF 1.4 files and that the JMI interfaces > > generated from > > these files are OK. > > Martin > > > > ----- Original Message ----- > > From: "Pete Rivett" > > To: > > Cc: > > Sent: Thursday, March 07, 2002 1:55 AM > > Subject: UML 1.4.1 should use MOF 1.4 > > > > > > > I'm raising this just in case: I'd have hoped it would be > > normal practice > > > to use the latest approved version of an 'underlying' standard. > > > > > > In the case of MOF 1.4 there are far more important reasons > > for moving to > > > it. The main change in MOF 1.4 is a 'proper' modeled > > datatype system as > > > opposed to CORBA datatypes hidden away in typeCodes. > > Because of this: > > > a) MOF 1.4 is the basis of the Java Metadata Interface > (JMI) which > > provides > > > Java APIs to metamodels and is being adopted by a number of > > repository and > > > UML tool vendors. Without an official version of UML > > expressed in MOF 1.4 > > > people will have to do their own conversion with subsequent > > interoperability > > > problems > > > > > > b) MOF 1.4 is also the basis of XMI 1.2 and XMI 2.0 (XMI for XML > > Schemas). > > > Without being expressed in MOF 1.4, the UML interchange > > definition cannot > > be > > > expressed as an XML Schema. > > > > > > c) the proper datatype model provides the opportunity to > > 'clean up' a > > > number of datatype-related issues in UML (e.g. issue 4452). > > And represent > > > UML's datatypes such as Multiplicity and MultiplicityRange as MOF > > > (structure) datatypes rather than MOF classes. > > > > > > I would expect this to only affect the UML 1.4.1 Concrete > > metamodel. I > > would > > > be willing to draft a proposal for this. Is there a version > > of this with > > > already-agreed 1.4.1 changes incorporated? > > > > > > > > > Pete Rivett (pete.rivett@adaptive.com) > > > Chief Technology Officer, Adaptive Ltd > > > 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 > > > > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. From: "Martin Matula" To: "Pete Rivett" , "'Iyengar, Sridhar'" , References: <003d01c1c6d9$45394ab0$114c04c8@CHIMAY> Subject: Re: Issue 4946 UML 1.4.1 should use MOF 1.4 - proposed resolution Date: Fri, 8 Mar 2002 22:32:25 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: WW,!!*CJe9XN?e9f)_!! Hi Pete, > In detail these are the changes I propose: > - add the JMI-specific tags for prefixes etc. > - import the MOF PrimitiveTypes package > - Convert the existing UML datatypes (all in the Data_Types package). The > MOF primitives and enumerations are obvious, the others I propose as > follows: > a) Name -> AliasType referring to String > b) LocationReference -> AliasType referring to String > c) UnlimitedInteger -> AliasType referring to Long (this is based on the > current CORBA typecode) > d) Geometry -> AliasType referring to String > e) MultiplicityRange -> StructureType with 'upper' and 'lower' Fields > f) Multiplicity -> CollectionType (1..*, ordered, not unique) of > MultiplicityRange > g) Expression -> StructureType with 'language' and 'body' Fields > h) subtypes of Expression -> AliasTypes referring to Expression (MOF does > not support inheritiance of DataTypes) I think if we would leave the datatypes in steps e) - h) untouched, they would still conform to MOF 1.4 and the DTD could stay the same. If we are to make only minimal changes, let's don't change these types - they don't need to be changed as they are classes currently and classes are still supported in MOF 1.4. Martin Date: Fri, 08 Mar 2002 14:26:12 -0800 From: Cris Kobryn Subject: RE: Issue 4946 UML 1.4.1 should use MOF 1.4 - proposed resolution In-reply-to: <013101c1c6e8$c0d0db70$eedc7ac3@praguenb> To: Martin Matula , Pete Rivett , "'Iyengar, Sridhar'" , uml-rtf@omg.org Reply-to: Cris.Kobryn@telelogic.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Type: text/plain; charset=iso-8859-1 X-UIDL: STd!!MZ > > In detail these are the changes I propose: > > - add the JMI-specific tags for prefixes etc. > > - import the MOF PrimitiveTypes package > > - Convert the existing UML datatypes (all in the Data_Types package). The > > MOF primitives and enumerations are obvious, the others I propose as follows: > > a) Name -> AliasType referring to String > > b) LocationReference -> AliasType referring to String > > c) UnlimitedInteger -> AliasType referring to Long (this is > based on the > > current CORBA typecode) > > d) Geometry -> AliasType referring to String > > e) MultiplicityRange -> StructureType with 'upper' and 'lower' Fields > > f) Multiplicity -> CollectionType (1..*, ordered, not unique) of > > MultiplicityRange > > g) Expression -> StructureType with 'language' and 'body' Fields > > h) subtypes of Expression -> AliasTypes referring to > Expression (MOF does > > not support inheritiance of DataTypes) > > I think if we would leave the datatypes in steps e) - h) untouched, they > would still conform to MOF 1.4 and the DTD could stay the same. > If we are to make only minimal changes, let's don't change these types - they > don't need to be changed as they are classes currently and classes are still > supported in MOF 1.4. I concur with Martin. Since we don't want to regenerate the DTD, let's not change these types. -- Cris From: "Pete Rivett" To: "'Martin Matula'" Cc: "'Iyengar, Sridhar'" , Subject: RE: Issue 4946 UML 1.4.1 should use MOF 1.4 - proposed resolution Date: Sat, 9 Mar 2002 23:22:13 -0000 Message-ID: <001101c1c7c1$3f9576e0$4f9123d9@CHIMAY> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <013101c1c6e8$c0d0db70$eedc7ac3@praguenb> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ARb!!CARd9@*#!!h\)!! Hi Martin, The DTD cannot remain identical - it needs to refer to XMI 1.2 as opposed to XMI 1.1 (specifically xmi.version CDATA #FIXED "1.1" needs to be changed to "1.2"). Moreover I'd hope that the invalid link.atts in the DTD would be corrected (UML issue 4810) - this is just wrong XMI. I believe there is a strong argument for making things like Multiplicity datatypes since otherwise in any metamodel-driven application/repository they end up being 'first class'/'managed' objects (with ownership, versioning, access control etc applied depending on the application functionality). It means that for a simple association between 2 classes you end up with 7 objects (1 Association, 2 AssociationEnds, 2 Multiplicities, 2 MultiplicityRanges) - yet more if there is a more complex set of Ranges. And in MOF 1.4 itself, MultiplicityType is a StructureType so why not be consistent with that? BTW it would be trivial to define a XSL stylesheet to convert to and from a UML 1.4 format XMI document for interoperability. Not that I'm aware of any UML tool vendore having yet implemented XMI for UML 1.4. Pete Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd 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: Martin Matula [mailto:martin.matula@sun.com] > Sent: 08 March 2002 21:32 > To: Pete Rivett; 'Iyengar, Sridhar'; uml-rtf@omg.org > Subject: Re: Issue 4946 UML 1.4.1 should use MOF 1.4 - proposed > resolution > > > Hi Pete, > > > In detail these are the changes I propose: > > - add the JMI-specific tags for prefixes etc. > > - import the MOF PrimitiveTypes package > > - Convert the existing UML datatypes (all in the > Data_Types package). The > > MOF primitives and enumerations are obvious, the others I propose as > > follows: > > a) Name -> AliasType referring to String > > b) LocationReference -> AliasType referring to String > > c) UnlimitedInteger -> AliasType referring to Long (this > is based on the > > current CORBA typecode) > > d) Geometry -> AliasType referring to String > > e) MultiplicityRange -> StructureType with 'upper' and > 'lower' Fields > > f) Multiplicity -> CollectionType (1..*, ordered, not unique) of > > MultiplicityRange > > g) Expression -> StructureType with 'language' and 'body' Fields > > h) subtypes of Expression -> AliasTypes referring to > Expression (MOF does > > not support inheritiance of DataTypes) > > I think if we would leave the datatypes in steps e) - h) > untouched, they > would still conform to MOF 1.4 and the DTD could stay the > same. If we are to > make only minimal changes, let's don't change these types - > they don't need > to be changed as they are classes currently and classes are > still supported > in MOF 1.4. > Martin > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. Date: Mon, 11 Mar 2002 11:10:20 +0000 From: Guus Ramackers Organization: Oracle Corporation X-Mailer: Mozilla 4.7 [en-gb] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pete Rivett CC: "'Martin Matula'" , "'Iyengar, Sridhar'" , uml-rtf@omg.org Subject: Re: Issue 4946 UML 1.4.1 should use MOF 1.4 - proposed resolution References: <001101c1c7c1$3f9576e0$4f9123d9@CHIMAY> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: -;h!!4C'!!c]$!!RC!!! Pete, The intention of having UML 1.4.1 is to fix editorial errors - an intermediate step to UMl 2.0. Most of your suggestions technically make sense (and I would like to see them in the UML 2.0 stack), what would actually be the minimal set of changes we could get away with in the DTD? The UML tool vendors would like to avoid or in any case minimize the impact of supporting UML 1.4.1 as a separate XMI format. > xmi.version CDATA #FIXED "1.1" needs to be changed to "1.2" Both versions could be used if this is the only difference. On the other hand, perhaps 1.1 is actually OK: We could approach this problem the other way around. If no changes in the DTD are desired at all, then we could stick with MOF 1.1 and update the editorial errors in the specification. Consolidation is really the intention here - before UML 2.0 hits the market. This would avoid the problem of users getting confused with the fact that a UML 1.4.1 XMI cannot be loaded by a UML 1.4 compatible tool. Since UMl 1.4.1 is an editorial "dot release" (where users will see no difference in semantics or notation) we shouldn't be confusing the users with different XMI files and the associated compatibility issues. It's just not worth it (or rather: it is not desirable from a market perspective). Thanks, Guus Pete Rivett wrote: > Hi Martin, > The DTD cannot remain identical - it needs to refer to XMI 1.2 as > opposed to > XMI 1.1 (specifically > xmi.version CDATA #FIXED "1.1" needs to be changed to > "1.2"). > Moreover I'd hope that the invalid link.atts in the DTD would be > corrected > (UML issue 4810) - this is just wrong XMI. > > I believe there is a strong argument for making things like > Multiplicity > datatypes since otherwise in any metamodel-driven > application/repository > they end up being 'first class'/'managed' objects (with ownership, > versioning, access control etc applied depending on the application > functionality). It means that for a simple association between 2 > classes you > end up with 7 objects (1 Association, 2 AssociationEnds, 2 > Multiplicities, 2 > MultiplicityRanges) - yet more if there is a more complex set of > Ranges. > And in MOF 1.4 itself, MultiplicityType is a StructureType so why > not be > consistent with that? > > BTW it would be trivial to define a XSL stylesheet to convert to and > from a > UML 1.4 format XMI document for interoperability. > Not that I'm aware of any UML tool vendore having yet implemented > XMI for > UML 1.4. > > Pete > > Pete Rivett (pete.rivett@adaptive.com) > Chief Technology Officer, Adaptive Ltd > 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: Martin Matula [mailto:martin.matula@sun.com] > > Sent: 08 March 2002 21:32 > > To: Pete Rivett; 'Iyengar, Sridhar'; uml-rtf@omg.org > > Subject: Re: Issue 4946 UML 1.4.1 should use MOF 1.4 - proposed > > resolution > > > > > > Hi Pete, > > > > > In detail these are the changes I propose: > > > - add the JMI-specific tags for prefixes etc. > > > - import the MOF PrimitiveTypes package > > > - Convert the existing UML datatypes (all in the > > Data_Types package). The > > > MOF primitives and enumerations are obvious, the others I > propose as > > > follows: > > > a) Name -> AliasType referring to String > > > b) LocationReference -> AliasType referring to String > > > c) UnlimitedInteger -> AliasType referring to Long (this > > is based on the > > > current CORBA typecode) > > > d) Geometry -> AliasType referring to String > > > e) MultiplicityRange -> StructureType with 'upper' and > > 'lower' Fields > > > f) Multiplicity -> CollectionType (1..*, ordered, not unique) > of > > > MultiplicityRange > > > g) Expression -> StructureType with 'language' and 'body' > Fields > > > h) subtypes of Expression -> AliasTypes referring to > > Expression (MOF does > > > not support inheritiance of DataTypes) > > > > I think if we would leave the datatypes in steps e) - h) > > untouched, they > > would still conform to MOF 1.4 and the DTD could stay the > > same. If we are to > > make only minimal changes, let's don't change these types - > > they don't need > > to be changed as they are classes currently and classes are > > still supported > > in MOF 1.4. > > Martin > > > > > > The information contained in this email and any attached files are > confidential and intended solely for the addressee(s). The e-mail > may be legally privileged or prohibited from disclosure and > unauthorised use. > > If you are not the named addressee you may not use, copy or disclose > this information to any other person. If you received this message > in error please notify the sender immediately. > > Any views or opinions presented here may be solely those of the > originator and do not necessarily reflect those of the Company. -- Guus Ramackers Product Manager UML Products, Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK e-mail: guus.ramackers@oracle.com work: +44-(0)1189-245101 fax: +44-(0)1189-245148 Reply-To: Joaquin Miller Message-Id: <5.1.0.14.2.20020311082534.00a04508@pop3.joaquin.net> X-Sender: miller%joaquin.net@pop3.joaquin.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Mar 2002 08:32:43 -0800 To: uml-rtf@omg.org From: Joaquin Miller Subject: Re: Issue 4946 UML 1.4.1 should use MOF 1.4 - proposed resolution Cc: ab@omg.org In-Reply-To: <3C8C909C.B230CF05@oracle.com> References: <001101c1c7c1$3f9576e0$4f9123d9@CHIMAY> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_88705191==_.ALT" X-UIDL: A[0e9clO!!CFb!!En$e9 Guus Ramackers wrote: This would avoid the problem of users getting confused with the fact that a UML 1.4.1 XMI cannot be loaded by a UML 1.4 compatible tool. I'm with the others, that we need to bring the XMI for UML up to date. But Guus' point decides the question, i feel. And, in addition to user convenience, it is a bit much to ask vendors to change the XMI format at this point. Maybe we could have a trade here, where OMG sticks with the old XMI until UML 2 and vendors, in exchange, agree to substantial conformance requirements on the use of the trademark. (Requirements designed from the user point of view.) PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 From: "Iyengar, Sridhar" To: Martin Matula , Pete Rivett , uml-rtf@omg.org Subject: RE: Issue 4946 UML 1.4.1 should use MOF 1.4 - proposed resolution Date: Mon, 11 Mar 2002 12:04:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: m/$!!%j0e9I@:e9/2M!! Matin's suggestion is pragmatic and meets the needs that Cris/Guus expressed - leave the DTD unchanged for now while the UML2 work proceeds. This allows the current tools (using UML 1.3 XMI or UML 1.4 XMI) alone. As long as the interchange remains the same (read use UML 1.4 DTD to validate interchange), new tools that plan to use JMI can proceed. I would agree that data type changes can wait for a future revision of UML. Question: The Action Semantics changes need to be handled when the FTF work completes. There a new package is added. What is the plan to address the interchange needs for Action Semantics? ------------------------------------------------------------------------ ---- Sridhar Iyengar Unisys Fellow, Director of Advanced Technology 25725, Jeronimo Road Mission Viejo, CA 92691 E-mail : Sridhar.iyengar2@unisys.com Phone : 949-380-5692 Fax : 949-380-6632 ------------------------------------------------------------------------ -------------- > -----Original Message----- > From: Martin Matula [mailto:martin.matula@sun.com] > Sent: Friday, March 08, 2002 1:32 PM > To: Pete Rivett; Iyengar, Sridhar; uml-rtf@omg.org > Subject: Re: Issue 4946 UML 1.4.1 should use MOF 1.4 - proposed > resolution > > > Hi Pete, > > > In detail these are the changes I propose: > > - add the JMI-specific tags for prefixes etc. > > - import the MOF PrimitiveTypes package > > - Convert the existing UML datatypes (all in the > Data_Types package). The > > MOF primitives and enumerations are obvious, the others I propose as > > follows: > > a) Name -> AliasType referring to String > > b) LocationReference -> AliasType referring to String > > c) UnlimitedInteger -> AliasType referring to Long (this > is based on the > > current CORBA typecode) > > d) Geometry -> AliasType referring to String > > e) MultiplicityRange -> StructureType with 'upper' and > 'lower' Fields > > f) Multiplicity -> CollectionType (1..*, ordered, not unique) of > > MultiplicityRange > > g) Expression -> StructureType with 'language' and 'body' Fields > > h) subtypes of Expression -> AliasTypes referring to > Expression (MOF does > > not support inheritiance of DataTypes) > > I think if we would leave the datatypes in steps e) - h) > untouched, they > would still conform to MOF 1.4 and the DTD could stay the > same. If we are to > make only minimal changes, let's don't change these types - > they don't need > to be changed as they are classes currently and classes are > still supported Date: Mon, 11 Mar 2002 13:57:05 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard Company X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Iyengar, Sridhar" Cc: Martin Matula , Pete Rivett , uml-rtf@omg.org Subject: Re: Issue 4946 UML 1.4.1 should use MOF 1.4 - proposed resolution References: <529ED587BF6FB24B88F9085D719C548F849D3D@USMV-EXCH3.na.uis.unisys.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %nO!!Z?Le9k(Oe9OD7!! "Iyengar, Sridhar" wrote: > > Matin's suggestion is pragmatic and meets the needs that Cris/Guus expressed > - leave the DTD unchanged for now while the UML2 work proceeds. This allows > the current tools (using UML 1.3 XMI or UML 1.4 XMI) alone. > > As long as the interchange remains the same (read use UML 1.4 DTD to > validate interchange), new tools that plan to use JMI can proceed. > > I would agree that data type changes can wait for a future revision of UML. I concur. This is the best pragmatic approach towards logically winding down the evolution of the non-Action Semantics related UML 1.x. > Question: The Action Semantics changes need to be handled when the FTF work > completes. There a new package is added. What is the plan to address the > interchange needs for Action Semantics? My understanding of the responsibilities of an FTF is that they do need to take care of all the consequences of the adoption of the specification that they are handling. In my mind, in case of the Action Semantics FTF this would include whatever needs to be done to handle the interchange needs of the UML 1.4 with Action Semantics specification. So I guess I don't see how the FTF could possibly complete its work without addressing that issue. So I would say that this question needs to be addressed and resolved as a part of the act of completing finalization of the Action Semantics specification. Consequently, I believe this question is an issue that is quite separate from 4946, and it belongs to the Action Semantics FTF. (This is of course not to say that said FTF should go off on its own without consulting anyone else to resolve this issue. That approach will probably not make the finalization very popular:-)). Jishnu. > > -----Original Message----- > > From: Martin Matula [mailto:martin.matula@sun.com] > > Sent: Friday, March 08, 2002 1:32 PM > > To: Pete Rivett; Iyengar, Sridhar; uml-rtf@omg.org > > Subject: Re: Issue 4946 UML 1.4.1 should use MOF 1.4 - proposed > > resolution > > > > > > Hi Pete, > > > > > In detail these are the changes I propose: > > > - add the JMI-specific tags for prefixes etc. > > > - import the MOF PrimitiveTypes package > > > - Convert the existing UML datatypes (all in the > > Data_Types package). The > > > MOF primitives and enumerations are obvious, the others I propose as > > > follows: > > > a) Name -> AliasType referring to String > > > b) LocationReference -> AliasType referring to String > > > c) UnlimitedInteger -> AliasType referring to Long (this > > is based on the > > > current CORBA typecode) > > > d) Geometry -> AliasType referring to String > > > e) MultiplicityRange -> StructureType with 'upper' and > > 'lower' Fields > > > f) Multiplicity -> CollectionType (1..*, ordered, not unique) of > > > MultiplicityRange > > > g) Expression -> StructureType with 'language' and 'body' Fields > > > h) subtypes of Expression -> AliasTypes referring to > > Expression (MOF does > > > not support inheritiance of DataTypes) > > > > I think if we would leave the datatypes in steps e) - h) > > untouched, they > > would still conform to MOF 1.4 and the DTD could stay the > > same. If we are to > > make only minimal changes, let's don't change these types - > > they don't need > > to be changed as they are classes currently and classes are > > still supported > > in MOF 1.4. > > Martin > > > > -- Jishnu Mukerji Senior Systems Architect SSO Staff, Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jishnu_mukerji@hp.com Reply-To: From: "Conrad Bock" To: "Jishnu Mukerji" , "Iyengar, Sridhar" Cc: "Martin Matula" , "Pete Rivett" , Subject: RE: Issue 4946 UML 1.4.1 should use MOF 1.4 - proposed resolution Date: Wed, 20 Mar 2002 19:41:34 -0800 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3C8CFE01.B2CBA7A1@hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: +4A!!fNb!!i8o!!FmMe9 Jishnu, > My understanding of the responsibilities of an FTF is that they do need > to take care of all the consequences of the adoption of the > specification that they are handling. In my mind, in case of the Action > Semantics FTF this would include whatever needs to be done to handle the > interchange needs of the UML 1.4 with Action Semantics specification. Yes, I had assumed the same. BTW, the XMI/IDL for the 1.4 + actions final adopted spec is unchanged from the XMI/IDL for the final revised submission (ad/2001-08-06). It was XMI 1.1 and we'll need to regenerate to the latest version when the time comes. Hopefully Alan Bradbury or someone can help with that as last time. Conrad