Issue 15118: We urgently need simple and clear rules we can follow to determine, for each file associated to a given specification (mof2core-rtf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Revision Severity: Critical Summary: "We urgently need simple and clear rules we can follow to determine, for each file associated to a given specification, the following: the value of the cmof:Package or cmof:Profile uri property per clause 10.2 of the MOF2 Core specification. the XMI namespace URI and the correspondence between an XMI namespace and anything that is a kind of cmof package, including a profile. the values of the CMOF tags: org.omg.xmi.nsPrefix and org.omg.xmi.nsURI Based on the UML 2.3 files, it seemed that the OMG document number - e.g., ptc/2009-09-01 for UML 2.3 or ptc/2010-03-01 for SysML 1.2 would have been sufficient to set unique URIs for each identifiable file document. If this is incorrect, then we need clear direction for how to do this." Resolution: Revised Text: Actions taken: March 5, 2010: received issue January 20, 2011: closed issue; Closed; No Change April 25, 2011: closed issue Discussion: Any rules for these values are a matter of (OMG) policy not for the specifications. The MOF 2 Facility specification provides a basic scheme for use of Package::uri in constructing URLs. Disposition: Closed, no change End of Annotations:===== m: "Rouquette, Nicolas F (316A)" To: Pete Adaptive , Ed Seidewitz , Steve Cook , Maged Elaasar , James Bruck , "issues@omg.org" CC: "uml2-rtf@omg.org" , SysML-RTF Date: Fri, 5 Mar 2010 10:15:16 -0800 Subject: Re: Reflection on discussions from today's call. Thread-Topic: Reflection on discussions from today's call. Thread-Index: Acq6LDwnhmcOo+4jRdyyjGfr2ertKQAujA0AAAIyhAAABUpBQAAhqaQAABRgd7EAAouggQAAeUwQABERxEYADcBmAAAG0mvIAAAo4tAAA/81gA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Juergen, Please file an urgent issue against both MOF2 Core and MOF XMI Mapping specificaitons. We urgently need simple and clear rules we can follow to determine, for each file associated to a given specification, the following: the value of the cmof:Package or cmof:Profile uri property per clause 10.2 of the MOF2 Core specification. the XMI namespace URI and the correspondence between an XMI namespace and anything that is a kind of cmof package, including a profile. the values of the CMOF tags: org.omg.xmi.nsPrefix and org.omg.xmi.nsURI Based on the UML 2.3 files, it seemed that the OMG document number . e.g., ptc/2009-09-01 for UML 2.3 or ptc/2010-03-01 for SysML 1.2 would have been sufficient to set unique URIs for each identifiable file document. If this is incorrect, then we need clear direction for how to do this. On 3/5/10 8:28 AM, "Pete Adaptive" wrote: The front page of the document gives the URLs for location of the files, which as I said is distinct from the XMI namespace URI and indeed the MOF package URI. The XMI namespace URI is used for model files to identify their metamodel(s). How this relates to the MOF package URI is undefined (this is a XMI issue). If there is a specific issue number, the above may be added as a comment to that issue. If there is a proposed resolution, I.d be interested in reviewing it. For UML 2 we decided not to distinguish models for the different compliance levels with different XMI namespace URIs. Fortunate as it turns out. I.d hope SysML did the same with UML4SysML. Instead of wishful thinking, please give us clear and simple rules we can follow. Wasting time like this is a luxury I can ill afford. - Nicolas. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 05 March 2010 08:16 To: Ed Seidewitz; Steve Cook; Maged Elaasar; James Bruck Cc: uml2-rtf@omg.org; SysML-RTF Subject: Re: Reflection on discussions from today's call. Ed, Where do you get that every compliance level uses the same URI? The front cover page of UML 2.3, ptc/2009-09-08 says: Associated Normative Machine-Readable Files: ptc/09-09-13 -- http://www.omg.org/spec/UML/20090901/Infrastucture.cmof ptc/09-09-14 -- http://www.omg.org/spec/UML/20090901/Superstructure.cmof ptc/09-09-15 -- http://www.omg.org/spec/UML/20090901/L0.cmof ptc/09-09-16 -- http://www.omg.org/spec/UML/20090901/L1.cmof ptc/09-09-17 -- http://www.omg.org/spec/UML/20090901/L2.cmof ptc/09-09-18 -- http://www.omg.org/spec/UML/20090901/L3.cmof ptc/09-09-19 -- http://www.omg.org/spec/UML/20090901/LM.cmof Since L2 is different than L1 and L2 refers to L1, L2 and L1 must have distinct URIs. Per http://www.ietf.org/rfc/rfc2396.txt, a URI designates an identifiable resource. Since L1.xmi and L2.xmi are identifiable and distinct resources, they must have distinct URIs. The same distinction/identification criteria applies to the set of resources associated to the UML specifications (i.e.,. Infrastructure, superstructure, standard profile and primitive types library). As far as MOF2.0 Core is concerned, check in particular the semantics section of clause 10.2, which also applies to profiles since they are a kind of package: -------------------------- 10.2 Package Identifiers extends Basic::Package with a URI that can be used as an external identifier for a package. Properties uri: String - Provides an identifier for the package that can be used for many purposes. A URI is the universally unique identification of the package following the IETF URI specification, RFC 2396 http://www.ietf.org/rfc/rfc2396.txt. UML 1.4 and MOF 1.4 were assigned URIs to their outermost package. The package URI appears in XMI files when instances of the package.s classes are serialized. Semantics The URI assigned to the package should be unique and remain unchanged. -------------------------- As far as MOF2.0 XMI Mapping is concerned, check in particular table 4.11.1 for the definition of the nsURI and nsPrefix tags: nsURI string nil The namespace URI of the MOF package. nsPrefix string nil The namespace prefix of the MOF package; this is used in schemas. (Any legal XML prefix may be used in documents.) Unfortunately, the tag names in this table are unqualified . they should be qualified . this is a MOF XMI issue if it hasn.t been filed already. However, the mapping rules described in clauses 5.2 and 6.4 indicate that the qualified names for these tags are, respectively: org.omg.xmi.nsPrefix org.omg.xmi.nsURI This could be made clearer in the spec though. The difference between the front cover page of UML 2.3 circa ptc/2009-09-08 and the recent discussion we.ve had on the UML RTF is that we.re changing the extension from .cmof to .xmi since all of these resources (packages, profiles) are CMOF resources serialized in XMI (as opposed to CMOF serialized in a different representation such as Cory.s favorite, RDF). Based on this, I conclude that the revised URIs for UML 2.3 should be as follows: Imfrastructure.xmi =============================== - XMI 2.1 serialization of the UML 2.3 Infrastructure - cmof:package name="InfrastructureLibrary" uri="http://www.omg.org/spec/UML/20090901/Infrastructure.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="infrastructureLibrary" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/UML/20090901/Infrastructure.xmi" Superstructure.xmi =============================== - XMI 2.1 serialization of the UML 2.3 Superstructure - cmof:package name="UML" uri="http://www.omg.org/spec/UML/20090901/Superstructure.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="uml" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/UML/20090901/Superstructure.xmi" L0.xmi =============================== - XMI 2.1 serialization of the L0 package merge map for UML 2.3 - cmof:package name="UML" uri="http://www.omg.org/spec/UML/20090901/L0.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="L0" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/UML/20090901/L0.xmi" L1.xmi =============================== - XMI 2.1 serialization of the L1 package merge map for UML 2.3 - cmof:package name="UML" uri="http://www.omg.org/spec/UML/20090901/L1.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="L1" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/UML/20090901/L1.xmi" L2.xmi =============================== - XMI 2.1 serialization of the L2 package merge map for UML 2.3 - cmof:package name="UML" uri="http://www.omg.org/spec/UML/20090901/L2.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="L2" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/UML/20090901/L2.xmi" L3.xmi =============================== - XMI 2.1 serialization of the L3 package merge map for UML 2.3 - cmof:package name="UML" uri="http://www.omg.org/spec/UML/20090901/L3.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="L3" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/UML/20090901/L3.xmi" LM.xmi =============================== - XMI 2.1 serialization of the LM package merge map for UML 2.3 - cmof:package name="UML" uri="http://www.omg.org/spec/UML/20090901/LM.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="LM" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/UML/20090901/LM.xmi" Depending on whether we call the merged UML metamodel @ L3 .UML-metamodel.xmi. or just .UML.xmi., we would also include: UML-metamodel.xmi =============================== - XMI 2.1 serialization of the UML metamodel merged at L3 - cmof:package name="UML" uri="http://www.omg.org/spec/UML/20090901/UML-metamodel.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="UML" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/UML/20090901/UML-metamodel.xmi" Or UML.xmi =============================== - XMI 2.1 serialization of the UML metamodel merged at L3 - cmof:package name="UML" uri="http://www.omg.org/spec/UML/20090901/UML.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="UML" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/UML/20090901/UML.xmi" But let.s not forget the standard profile (L2 and L3) and the primitive types library! StandardProfileL2.xmi =============================== - XMI 2.1 serialization of the UML Standard Profile at L2 - cmof:profile name="UML" uri="http://www.omg.org/spec/UML/20090901/StandardProfileL2.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="StandardProfile" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/UML/20090901/StandardProfileL2.xmi" StandardProfileL3.xmi =============================== - XMI 2.1 serialization of the UML Standard Profile at L3 - cmof:profile name="UML" uri="http://www.omg.org/spec/UML/20090901/StandardProfileL3.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="StandardProfile" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/UML/20090901/StandardProfileL3.xmi" UMLPrimitiveTypes.xmi =============================== - XMI 2.1 serialization of the UML Primitive Types library - cmof:package name="UMLPrimitiveTypes" uri="http://www.omg.org/spec/UML/20090901/ UMLPrimitiveTypes.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value=" UMLPrimitiveTypes" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/UML/20090901/ UMLPrimitiveTypes.xmi" - Nicolas. On 3/5/10 5:02 AM, "Ed Seidewitz" wrote: Nicolas . OK, if I understand correctly, then you are suggesting that each Ln nsURI should have Ln.xmi in it. If so, I have to disagree. I major point of the compliance level XMI is that every level uses the same UML URI. So I think the nsURIs are correct as they stand for UML 2.3. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, March 05, 2010 1:27 AM To: Ed Seidewitz; Steve Cook; Maged Elaasar; James Bruck Cc: uml2-rtf@omg.org; SysML-RTF Subject: Re: Reflection on discussions from today's call. Ed, It.s a typo. For UML2.3, L1.xmi should have the following CMOF characteristics: cmof:package name=.L1. uri=.http://www.omg.org/spec/UML/20090901/L1.xmi. cmof:tag name=.org.omg.xmi.nsPrefix. value=.uml. cmof:tag name=.org.omg.xmi.nsURI. value=.http://www.omg.org/spec/UML/20090901/L1.xmi. FYI . below is the README.txt for SysML 1.2 where I detailed the CMOF characteristics of each resource and those of the UML 2.3 dependencies. ------------- SysML-profile.xmi ===================== - XMI 2.1 serialization of the SysML Profile - cmof:profile name="SysML" uri="http://www.omg.org/spec/SysML/20100301/SysML.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="sysml" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/SysML/20100301/SysML.xmi" Activities-model.xmi ========================= - XMI 2.1 serialization of the Activities model library - cmof:package name="Activities" uri="http://www.omg.org/spec/SysML/20100301/Activities.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="activities" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/SysML/20100301/Activities.xmi" Blocks-model.xmi ===================== - XMI 2.1 serialization of the Blocks model library - cmof:package name="Blocks" uri="http://www.omg.org/spec/SysML/20100301/Blocks.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="blocks" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/SysML/20100301/Blocks.xmi" UML4SysML.xmi =============================== - XMI 2.1 serialization of the unmerged UML4SysML subset of UML 2.3 - cmof:package name="UML4SysML" uri="http://www.omg.org/spec/SysML/20100301/UML4SysML.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="uml4sysml" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/SysML/20100301/UML4SysML.xmi" SysML-L1.xmi =============================== - XMI 2.1 serialization of the package merge maps of UML4SysML and of UML 2.3 for SysML compliance level 1 - cmof:package name="SysML-L1" uri="http://www.omg.org/spec/SysML/20100301/SysML-L1.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="uml4sysml" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/SysML/20100301/SysML-L1.xmi" SysML-L2.xmi =============================== - XMI 2.1 serialization of the package merge maps of UML4SysML and of UML 2.3 for SysML compliance level 2 - cmof:package name="SysML-L2" uri="http://www.omg.org/spec/SysML/20100301/SysML-L2.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="uml4sysml" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/SysML/20100301/SysML-L2.xmi" SysML-L3.xmi =============================== - XMI 2.1 serialization of the package merge maps of UML4SysML and of UML 2.3 for SysML compliance level 3 - cmof:package name="SysML-L3" uri="http://www.omg.org/spec/SysML/20100301/SysML-L3.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="uml4sysml" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/SysML/20100301/SysML-L3.xmi" UML4SysML-metamodel.xmi =============================== - XMI 2.1 serialization of the merged UML4SysML subset of UML 2.3 - cmof:package name="UML4SysML" uri="http://www.omg.org/spec/SysML/20100301/UML4SysML-metamodel.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="uml4sysml" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/SysML/20100301/UML4SysML-metamodel.xmi" *** Dependencies on UML 2.3 *** Imfrastructure.xmi =============================== - XMI 2.1 serialization of the UML 2.3 Infrastructure - cmof:package name="InfrastructureLibrary" uri="http://www.omg.org/spec/UML/20090901/Infrastructure.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="infrastructureLibrary" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/UML/20090901/Infrastructure.xmi" Superstructure.xmi =============================== - XMI 2.1 serialization of the UML 2.3 Superstructure - cmof:package name="UML" uri="http://www.omg.org/spec/UML/20090901/Superstructure.xmi" - cmof:tag name="org.omg.xmi.nsPrefix" value="uml" - cmof:tag name="org.omg.xmi.nsURI" value="http://www.omg.org/spec/UML/20090901/Superstructure.xmi" *** Instructions for re-generating SysML 1.2 artifacts using Eclipse Helios *** Use Eclipse Helios M5 (or later): http://www.eclipse.org/epp/download.php Add patch: 304719: Support converting a toplevel CMOF package into a metamodel. https://bugs.eclipse.org/bugs/show_bug.cgi?id=304719 a) make sure the following artifacts are in a version control repository: - Infrastructure.xmi - Superstructure.xmi - SysML-L1.xmi - SysML-L2.xmi - UML4SysML.xmi b) open SysML-L3.xmi with UML Editor c) under the UML4SysML.xmi resource, select the UML4SysML package d) menu: UML Editor > Package > OMG Merge... e) accept the default options, which have been configured for this command to produce a merged metamodel for the OMG f) menu: UML Editor > Convert To > Metamodel g) menu: UML Editor > Package > Unapply Profile... there should be 2 profiles: ecore, standard. remove both h) in the properties view, change the name of the SysML-L3 package to UML4SysML i) save as UML4SysML-metamodel.xmi j) Select the following artifacts that have been modified: - Infrastructure.xmi - Superstructure.xmi - SysML-L1.xmi - SysML-L2.xmi - UML4SysML.xmi k) Team > Replace With > Latest from Repository l) open UML4SysML-metamodel.xmi using the text editor. Replace the first two lines of UML4SysML-metamodel.xmi, which are: With the first three lines of UML4SysML.xmi, which are: > > Replace the last two of lines of UML4SysML-metamodel.xmi, which are: With: --------------- - Nicolas. On 3/4/10 2:21 PM, "Ed Seidewitz" wrote: Nicolas . The normative file at http://www.omg.org/spec/UML/20090901/L1.cmof is: > > . Sorry, but that already looks to me exactly like what you are proposing (other than the fact that you accidently used .L0. for the package name rather than .L1.). Am I missing something?? -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, March 04, 2010 5:05 PM To: Steve Cook; Ed Seidewitz; Maged Elaasar; James Bruck Cc: uml2-rtf@omg.org; SysML-RTF Subject: Re: Reflection on discussions from today's call. I checked the fine print of the MOF2 XMI & Core specs and found some mistakes in both UML 2.3 artifacts and SysML 1.2 artifacts w.r.t. The CMOF tag/value & attributes. First, there should be an issue filed against the MOF2 XMI Mapping Specification formal/2007-12-02 unless it.s been reported already. On p. 10, the spec says: The XMI model package has the following tag settings: . tag nsURI set to .http://schema.omg.org/spec/XMI/version. . tag nsPrefix set to .xmi. This is inconsistent with Table 4.11.1 in the same document: nsURI string nil The namespace URI of the MOF package. As supportive evidence of this conclusion, look at the MOF2 Core specification formal/06-01-01 shows in the normative Annex A (p. 71): XMI allows the use of tags to tailor the schemas and documents that are produced using XMI. The following have been explicitly set for EMOF; the others are left at their default values: . tag nsURI set to .http://schema.omg.orb/spec/MOF/2.0/emof.xml . tag nsPrefix set to .emof. The following have been explicitly set for CMOF; the others are left at their default values: . tag nsURI set to .http://schema.omg.orb/spec/MOF/2.0/cmof.xml . tag nsPrefix set to .cmof. I suggest the MOF2 XMI mapping specification clearly emphasizes the rules for setting the value of the .uri. attribute for a CMOF:Package in relation to the org.omg.xmi.nsURI and nsPrefix tags. As far as UML 2.3 is concerned, I think the L1/L2/L3.xmi files need to be fixed to the following: L1.xmi: > > ... L2.xmi: > > ... L3.xmi: > > ... The nsURI and CMOF package uri for L1.xmi should be: "http://www.omg.org/spec/UML/20090901/L1.xmi" Ditto for L2 and L3. There may be other artifacts that need fixing . e.g. The standard profile for example. For SysML 1.2, this means that the correct CMOF tag/values and attributes are as follows: 1) UML4SysML.xmi (unmerged metamodel) > > ... 2) UML4SysML-metamodel.xmi (merged metamodel) > > ... 3) SysML-profile.xmi (profile extending UML4SysML-metamodel.xmi) > ... 4) Activities-model.xmi (library) > > ... 5) Blocks-model.xmi (library) > > ... - Nicolas. On 3/4/10 12:51 PM, "Nicolas F Rouquette" wrote: Hi, I.ve been re-generating SysML 1.2 since the UML 2.3 artifacts have changed. I simplified some of the steps in Steve.s description with this patch: 304719: Support converting a toplevel CMOF package into a metamodel. https://bugs.eclipse.org/bugs/show_bug.cgi?id=304719 Steve.s instructions are incomplete; between 3 and 4, one has to do the following: rename the toplevel package (e.g., for UML; it.s L3 => UML; for SysML; it.s SysML-L3 => UML4SysML-Metamodel) remove the application of profiles (ecore, standard) -- Eclipse uses pathmap URIs for these profiles. add the CMOF tags clean up the XMI header to remove references on Eclipse. In practice, the XMI header cleanup step may have to be repeated whenever an artifact is modified . Eclipse tends to add its own stuff in the XMI header. Given that SysML 1.2 has been assigned document number ptc/2010-03-01, are the tag/value pairs for the SysML 1.2 artifacts correct? 1) UML4SysML.xmi (unmerged metamodel) 2) UML4SysML-metamodel.xmi (merged metamodel) -- same CMOF tag/value pairs as UML4SysML.xmi 3) SysML-profile.xmi (profile extending UML4SysML-metamodel.xmi) 4) Artifact-model.xmi (library) 5) Blocks-model.xmi (library) - Nicolas. On 3/4/10 3:20 AM, "Steve Cook" wrote: Ed ( & question for Maged below) I agree about the second and third points and will formulate the resolution accordingly. On the first point. There is a set of functions whose domain is UML models and whose range is CMOF models. One of these functions maps uml:Package to cmof:Package, uml:Class to cmof:Class, uml:Generalization to cmof:superclass, uml:lowerValue to cmof:lower, uml:Model to cmof:Package, and any applied stereotypes to nothing. This function will map both L3 UML stereotyped models with Model at the root, and L1 unstereotyped models with Package at the root, to the same cmof model. In that rather precise sense, the fact that Model is not available in CMOF is not relevant. We have already agreed that the UML artifact that we should publish as a normative metamodel is the one produced by the following step as published on the wiki: 2. Using MDT/UML Open Source Tooling I. Perform package merge at L3 open L3.uml using the open source UML editor right click the model root and from the main menu do : UML Editor ¡÷ckage ¡÷rge. right click the model root and from the main menu do : UML Editor ¡÷nvert ¡÷tamodel do SaveAs. and rename to L3.merged.uml close the editor Maged: What kind of artifact does that step produce? Does it have Model or Package at its root? Does it contain any stereotypes? The answer to those questions should decide the specification of the format of this artifact. Thanks -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 03 March 2010 19:20 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: Reflection on discussions from today's call. Steve -- Some answers: >In any case, to the extent that the UML abstract syntax metamodel is still supposed to normatively a CMOF model in the end (despite also being representable as a UML model), it should not use the Model construct, since this is not available in CMOF. The fact that Model is not available in CMOF is surely not relevant. This is a UML model: it will also contain Generalizations, which aren.t available in CMOF either. All there needs to be is a functional mapping to the CMOF version. [EVS] It sure is relevant! The UML metamodel is technically a MOF model, since that is how we specify modeling languages in OMG. And CMOF does have generalization . it is just not represented as a separate metaclass in the CMOF abstract syntax, as it is in the UML superstructure. However, every abstract syntax diagram in the UML superstructure specification should be a valid CMOF model, as well as being a valid UML model. That is there should be no constructs used in the abstract syntax diagram that cannot be represented in CMOF . whether or not this representation is the same as in the UML superstructure. That is why we should not use the Model construct in the UML metamodel . because if we changed the package merge diagrams so that the Ln packages where models, these diagrams would be legal UML models (though only at superstructure level L3), but not legal CMOF models. The fact that Model is not available in L2 *is* relevant: if we want to restrict the language that is used to define this normative UML version to L2 (or L1, as per your other note) then we clearly can.t use Model (or Metamodel). In any event I don.t feel strongly about any of this so will modify the approach to use L1 and no stereotypes. >You did not actually correct all the problems with the example that you pointed out in Issue 14448. In particular, since this is supposed to be a serialization of a UML model, the .ownedMember. elements should be .packagedElement.. Well, Pete told me that Issue 14448 was (partially) wrong. Because of the statement: .This mapping is used as a means to explain and formalize how profiles are serialized and exchanged as XMI. Using this Profile to CMOF mapping, rules for mapping CMOF to XMI can be used indirectly to specify mappings from Profiles to XMI.., the correct way to serialize profiles is using ownedMember, because that is the MOF equivalent: it also applies to lower, upper. [EVS] Actually, as I remember the discussion, we eventually came to the consensus that UML profiles are serialized as UML models, not as their equivalent CMOF packages. Note that, even in the example, the outermost element is uml:Profile, not cmof:Package. However, in the earlier discussion on the 14448, Pete did note that the xmi:uml URI in the example, as given in the spec, is for UML 2.0, for which the use of ownedMember is correct. The change from ownedMember to packagedElement for members of packages cam in UML 2.1 (if I remember correctly). So the conclusion of the earlier discussion was that the example in the spec is actually self-consistent, but out of date and thus confusing. In your update to the example, you properly use the (presumed) URI for UML 2.4 . but that means you then need to use packagedElement, not ownedMember. However, I have much sympathy with what you say: and since TestCase3 does it the way you suggest, I am happy to change these examples. >Right now, it looks like the spec allows the modeler to give any names desired to the ends of the extension, though that does not seem very useful . but we should not imply otherwise unless we want to also change the spec to make the naming required on the extension. Ed, I am not sure what you are suggesting here. Do you want me to change the names? If so, how should I document the mapping between the names I choose and the .mof-equivalent. names? And then, if they are different, what would be the correct version of the following? [EVS] Well, you are not sure what I am suggesting, because I didn.t actual suggest anything! I wanted to point out the problem, but I am not exactly sure of the solution. The serialization of the profile application you give below is correct, regardless of what the end names are on the extension. That is because this serialization is based on the end names on the equivalent CMOF association, whose construction is specified, but which are not required to be the same as the end names of the extension that is actually modeled in the profile. Perhaps the simplest thing to do is to simply add constraints to require the ends of the extension to have the same names already given to the equivalent CMOF association, because I can.t see any reason a modeler would want to give different names to the extension ends. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 03 March 2010 15:43 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: Reflection on discussions from today's call. Steve . In general I think this correctly reflects our discussion and decisions. However, I have a couple of comments. 1. On your comment: > Personally I don.t see why we can.t make the root element a Model and use the Metaclass and Metamodel > stereotypes - I think it would make the models more convenient for tools. In the current normative model, the packages L1, L2 and L3 are not models, they are just packages. I don.t think it is worth changing this just for the purpose of resolving Issue 15006. In any case, to the extent that the UML abstract syntax metamodel is still supposed to normatively a CMOF model in the end (despite also being representable as a UML model), it should not use the Model construct, since this is not available in CMOF. As to using the metaclass stereotype, there was some concern about the circularity of having the standard profile that defines this stereotype reference a normative metamodel that uses a stereotype defined in that profile. Personally, I don.t think this is any worse than the other circularities we have in our MOF based approach, but it is probably not worth the complexity of making sure everyone understands this. 2. On the example XMI: You did not actually correct all the problems with the example that you pointed out in Issue 14448. In particular, since this is supposed to be a serialization of a UML model, the .ownedMember. elements should be .packagedElement.. Also, it is not clear to me that the ends of the actual extension have to be named .base_Interface. and .extension_Home.. The spec says that these are the end names for the notionally equivalent CMOF association, but I can.t find anything in the spec that requires these names for the actual extension relationship in the profile model. Right now, it looks like the spec allows the modeler to give any names desired to the ends of the extension, though that does not seem very useful . but we should not imply otherwise unless we want to also change the spec to make the naming required on the extension. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, March 02, 2010 1:12 PM To: uml2-rtf@omg.org Subject: Reflection on discussions from today's call. Today we discussed two topics. 1. Capital letters vs small letters for standard stereotype definitions and applications. We came to a rapid resolution and agreed to use capital letters for both, with the proviso that using small letters for stereotype applications is an obsolete but still valid rendering. 2. The correct hrefs for referring to UML metaclasses from profile definitions. We discussed two main approaches: a. Referring to the cmof definitions, using some special rules to work around the problems of incorrect typing. b. Creating normative merged models of UML in UML, and referring to those. After discussion we decided to go with approach b. Here are some details about how I think that would work. - We need to create normative merged models of UML L2 and L3, in order for standard profiles L2 and L3 to refer to them. - We do not need models of any other compliance levels, because profiles are defined at L2. - The models will be created using the subset of UML L3 that contains the constructs necessary to express metamodels. This avoids any merging issues with the definition of profiles: stereotypes refer to classes defined using UML L3. - These models will be simple to create because they are already created as part of the procedure to generate the CMOF definitions. The following was suggested: - The root element of each of these models will be a Package, not a Model. - The normative UML definitions of UML L2 and L3 will not contain any stereotypes (such as Metaclass and Metamodel). Personally I don.t see why we can.t make the root element a Model and use the Metaclass and Metamodel stereotypes - I think it would make the models more convenient for tools. Here is the example profile from the spec, reworked in a way that I believe conforms to what we.ll end up with. I am also attaching a proposed version of StandardProfileL3.xmi along the same lines. Things to note: the need to define XML namespaces for xmi, uml and cmof; I have omitted any xmi:type attribute for the importedPackage; the use of .xmi file extension for uml xmi files; the date is provisionally 20101201 (and will need to be updated on final publication: this is a disadvantage of date-based versioning). If we go this way, then issue 14092 can be resolved fully. Also 15006 resolution should include the example above (the current example serializes the nsUri and nsPrefix tags wrongly, and this will also resolve 14448). We can also close 13306. Comments on this approach please. Thanks -- Steve