Issue 3126: Operations and Constraints Missing from "Physical" Metamodels (uml2-superstructure-ftf) Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com) Nature: Uncategorized Issue Severity: Summary: The "physical" metamodel should include the OCL constraints and operations defined in the UML Specification. This has been done in the MOF 1.3 specification. The operations provide valuable capabilities and should be part of the standard UML facility interfaces. Making the operations part of the "physical" metamodel allows them to be used when defining new constraints in extension metamodels, such as in CWM. Recommendation: Add the specification's constraints and operations to the "physical" metamodel. Note that adding constraints and operations will affect IDL, but it will not affect XMI DTDs. Resolution: Revised Text: Actions taken: December 15, 1999: received issue March 9, 2005: closed issue Discussion: In UML 2.0 the adopted XMI representation of the metamodel does contain the operations used in defining the abstract semantics. End of Annotations:===== From: "Baisley, Donald E" To: issues@omg.org Subject: Operations and Constraints Missing from "Physical" Metamodels (um l-rtf) Date: Wed, 15 Dec 1999 12:58:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: F[*!!0&^!!K'Sd9_G3!! The "physical" metamodel should include the OCL constraints and operations defined in the UML Specification. This has been done in the MOF 1.3 specification. The operations provide valuable capabilities and should be part of the standard UML facility interfaces. Making the operations part of the "physical" metamodel allows them to be used when defining new constraints in extension metamodels, such as in CWM. Recommendation: Add the specification's constraints and operations to the "physical" metamodel. Note that adding constraints and operations will affect IDL, but it will not affect XMI DTDs. Don Baisley Unisys Subject: [issue 3126] was: A proposal on Compliance from UML users Date: Fri, 12 Dec 2003 09:45:25 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A proposal on Compliance from UML users Thread-Index: AcPAtdYp9ltx7kVZRMO3V94UvLwdfgABggJA From: "Karl Frank" To: "Jim Amsden" , "Michael Latta" Cc: "UML Superstructure FTF" X-OriginalArrivalTime: 12 Dec 2003 14:45:26.0555 (UTC) FILETIME=[9493F6B0:01C3C0BE] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id hBCEhQNA017687 Issue 3126 which was assigned to the "Classes" chapter 7 group for which I am the lead, is relevant to this topic. Issue 3126 was filed by Don Baisley of UniSys against UML 1 and remains relevant to UML 2 because UML 2 does not detail what portions of the wordy spec really count when judging conformance of a product with the metamodel. Issue 3126 notes that the UML 1.3 spec introduced OCL constraints and operations, but that the serialization of the metamodel in XML (see Appendix F of ptc/03-08-02) does not mandate the inclusion of these constraints and operations. I propose that the Issue 3126 is an issue against the incompleteness of the spec's definition of compliance. At present the UML 2 superstructure has only one sentence about what conformance to a compliance point means. That sentence is: "Unless otherwise qualified, complying with a package requires complying with its abstract syntax, well-formedness rules, semantics, notation, and XMI schema." (from page 2 of ptc/03-08-02) I propose that this sentence should be followed by a paragraph of explanation stating in detail what counts as "abstract syntax, well-formedness rules, semantics, notation, and XMI schema". For each model element, there are subsections in the spec with labels "semantics" and "notation", but there is no call-out of what counts as "well-formedness rules" and "abstract syntax". It is left for implementers to guess how (for example) abstract classes and operations should be supported in UML 2 compliant products. Issue 3126 proposes that the spec should explicitly explain that the serializatoin of the metamodel include the OCL constraints and operations, and by implication, it seems to propose that the definition of compliance with the metamodel shall include demonstration of support for those constraints and operations. Regards, Karl Frank -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, December 12, 2003 8:42 AM To: Michael Latta Cc: Karl Frank; UML Superstructure FTF Subject: RE: A proposal on Compliance from UML users Michael, Thanks for your patience too. I know this is pretty tedious stuff, and is recovering old ground thought to be resolved. I expect that the L-level will be part of the namespace URI in XMI instance documents referring to the specific XMI Schema used to validate those documents. The fact that there is a specific relationship between the XMI schemas identified by these URIs is not known by XMI or XML processors, but is known by the tools reading such documents and users of those tools. This is where the interoperability happens. "Michael Latta" 12/12/2003 02:02 AM To: Jim Amsden/Raleigh/IBM@IBMUS cc: "Karl Frank" , "UML Superstructure FTF" Subject: RE: A proposal on Compliance from UML users Jim, Thank you for your patience on this. Given what I saw on your EMF site this looks to be workable. We strongly want the L-level definitions to merge in the subset packages, not repeat the merges of fine-grained packages. This ensures that L(n) is a proper superset of L(n-1). I think it is up to the other language designers (CWM etc.) to chart their own course. They can use specialization, or repeat the UML2 example of package merge (either form). This list does not need to get into that. I presume there will be information in the header of the XMI document to indicate which L-level the content conforms to? Since the XMI namespace is not unique there needs to be some way to tell the intended reader level, or there is no point in defining L levels. From a user point of view there is value in knowing Tool A and Tool B agree on their subset of UML 2. But from a technical perspective is there value in knowing if file A conforms to level 3? Are XMI documents going to note the level they require for full import, or not bother? Will there in fact be only one XMI schema for the full language, with subsets being a documentation issue not a technical one? Michael -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Thursday, December 11, 2003 12:10 PM To: Michael Latta Cc: Karl Frank; UML Superstructure FTF Subject: RE: A proposal on Compliance from UML users Michael, The connection between the L-levels is defined by the specification. Ln is fully compatible with Ln+1. Nothing needs to be done to the XMI documents or client applications (assuming they use the same API generator of course). This is because Ln+1 always contains the same or more capabilities as Ln. This, and combine merge are the foundation of the IBM proposal, and it is this compatibility that we are looking for. We don't want to have to rely on specialization to provide the compatibility because it doesn't work for XMI and doesn't scale for API generation. This has nothing to do with mappings, we specifically define the compliance points contents, and how they are defined using package merge to avoid this very issue. The point of model-to-model mappings is for completely different metamodels such as CWM, Java, C, J2EE, etc., not different subsets of UML2. It is our contention that these different metamodels should not in general subclass UML2, but should rather be defined by MOF and relate to UML2 through a mapping. This is MUCH more flexible than using specialization and keeps UML2 decoupled from other metamodels. Abstract classes are not removed by package merge UNLESS the merged and merging class names match. In this case, the properties and associations are merged and are therefore available in the merging class. Nothing is missing from the model compared to the current package merge. It is just that the associations do not have to be both redefined in the merging class and inherited from the merged class. The meaning is the same. We have developed sample applications using both approaches, and they both do the same things. It just that the combine merge results in an API that is much simpler, smaller, doesn't require a lot of unpredictable downcasting, is fully compatible with another API that has more capabilities, etc. We have also implemented all of UML2 using our proposed approach and are actively developing various tools with it. So we're pretty sure this works. You can see the code at http://www.eclipse.org/uml2/. Anyway, our proposal is not for defining a mapping from UML2 to Java for some future JMI2. We only propose that combine merge be use to specify the compliance points, each compliance point is a subset of UML2, the compliance points a leveled subsets, and the XMI schemas for the compliance points are derived from the merged result. This is just about the specification itself. Tools are free to generate Java or other language APIs that exploit inheritance or delegation as they wish to achieve similar results in the platform specific domain. Such tools can leverage the definition of package merge to merge model fragments as part of their API generation, and do not have to start with the merged results as given in the spec. There is no implication that an API must exactly match a one-to-one mapping with the merged packages. Only that the behavior of XMI interchange is maintained and applications using an API should expect to be compatible with a subsequent generation of that API that includes more capabilities. "Michael Latta" 12/11/2003 02:25 PM To: Jim Amsden/Raleigh/IBM@IBMUS cc: "Karl Frank" , "UML Superstructure FTF" Subject: RE: A proposal on Compliance from UML users Jim, While in theory the IBM proposal is similar in structure, the devil is in the details. By using the COMBINE form of package merge, as your message indicated, there would be no real connection between your L levels. Each would be an independent language with no abstract classes in common. While I understand your argument that model transformation is the connection, we are not willing to accept that as the solution. We are well along the route to implementation and do not want to end up with 4 independent metamodels that "happen" to be subsets of each other. We are also concerned about the impact of COMBINE on the resulting model. COMBINE was defined to support EMOF by removing abstract classes and redefinitions, doing this to Superstructure as defined would be a huge problem as there are numerous concrete classes and associations that would need to be manipulated independently, rather than being manipulated via the abstract classes. Michael -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, December 10, 2003 9:25 AM To: Michael Latta Cc: Karl Frank; UML Superstructure FTF Subject: RE: A proposal on Compliance from UML users Michael, Your suggestion is compatible with the IBM proposal. We propose that tool vendors say what compliance point they are compatible with, and what additional capabilities they support. These capabilities are also specified in the UML2 specification and correspond to merged packages. We also propose a single UML2 language captured in a package such as org::omg::uml and that package merge be used to include capabilities into this package to define a compliance point. Our compliance points L0, L1, and L2 correspond to subset levels, with compliance point L3 corresponding to the whole UML2 language. Each compliance point schema is a subset of the next higher compliance point schema making them completely compatible. "Michael Latta" 12/10/2003 12:06 PM To: "Karl Frank" cc: "UML Superstructure FTF" Subject: RE: A proposal on Compliance from UML users We feel that a requirement such as this should be required of all tool vendors for UML 2.0. This is the kind of reference a user needs to make the spec have meaning, and at least shows that someone in the tool company read the spec enough to state their compatibility. But, it does not address HOW the tool will be compatible. Random selection of packages or metaclasses from the spec will not yield a coherent XMI schema. How to define a schema is a key issue. One option is to define only one UML schema for the full language and allow tools to implement their chosen subsets. This is becoming more and more appealing as this discussion progresses. This guarantees one API and one XMI schema that vendors can choose to implement subsets of. Those subsets would be defined as in this statement. Michael -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Tuesday, December 09, 2003 6:35 PM Cc: UML Superstructure FTF Subject: A proposal on Compliance from UML users An engineer at Raytheon made the following concrete proposal to Borland, with goal of improving the definition of compliance. The point of this simple recommendation is that it is consistent with a complex fine-grained compliance scheme and equally consistent with a coarse-grained scheme, and renders either scheme more useful and verifiable, without respect to how compliance testing is (or is not) defined. In brief, the recommendation is that any product that claims compliance of ANY sort with UML must publish a list of exactly what PORTION of the spec it complies with. The proposal requires only a minimal edit to the spec, perhaps a line as follows: Any product that claims compliance with this specification shall list the elements of the metamodel it implements. This list shall identify elements of the metamodel in terms of sections this specification, and shall be published as part of the product documentation in the language of that documentation. as for example, assuming English language documentation set This product implements all the concrete metaclasses specified in Chapter 7. This product implements all the metaclasses, both abstract and concrete, as specified in StateMachines::BehaviorStateMachines, and provide the XMI 2 functionality to export and import models expressed in compliance with that metamodel. - Regards, Karl Frank Subject: RE: [issue 3126] was: A proposal on Compliance from UML users Date: Fri, 12 Dec 2003 15:24:25 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A proposal on Compliance from UML users Thread-Index: AcPAtdYp9ltx7kVZRMO3V94UvLwdfgABggJAAAxQh0A= From: "Karl Frank" To: "UML Superstructure FTF" , "Baisley, Donald E" X-OriginalArrivalTime: 12 Dec 2003 20:24:27.0150 (UTC) FILETIME=[F08472E0:01C3C0ED] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id hBCKMSNA023207 Don Baisley's comments, re: issue 3126 which were in answer to my questions are relevant to the whole FTF discussion on compliance. I asked Don: > Would you agree that issue 3126 should be positioned as an > issue for Compliance and Appendix F? He answered: Yes I would. There needs to be a formal collection of rules (as there is for the other metamodel elements) that establishes a basis of conformance. Of course, this would allow the use of automated tools to test whether the specification's own use of operations and constraints was conformant -- something never done before. Regards, Don -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Friday, December 12, 2003 5:51 AM To: Baisley, Donald E Cc: Tolbert, Doug M Subject: RE: physical metamodel? Thanks for the speedy and clear response. There is a question at the end. In my opinion, this means the issue is relevant to the definition of compliance, in addition to being relevant to Appendix F. For if Appendix F permits some information in the document to be omitted from the serialized representation of the metamodel, that ommission would result in that information being unavailable in that form for establishing conformance. The UML 2 provision for four values of compliance at any one of 38 compliance points includes two, complete and xmi which I think should be understood in light of what must go into the serialized representation of the metamodel of UML 2. I propose to bring issue 3126 into the FTF's current high-priority discussion of the definition of "compliance" which occurs otherwise only on pages 1-3 (as printed, about p 12 of electronic pdf) of the final adopted spec, and consists of this one woefully incomplete bit: "Unless otherwise qualified, complying with a package requires complying with its abstract syntax, well-formedness rules, semantics, notation, and XMI schema." (from page 2 of ptc/03-08-02) (I especially hate it that well-formedness rules are scattered among the semantics, definition, and constraints sections.) Would you agree that this should be positioned as an issue for Compliance and Appendix F? - Karl -----Original Message----- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: Thursday, December 11, 2003 9:38 PM To: Karl Frank Cc: Tolbert, Doug M Subject: RE: physical metamodel? The word "physical" was used in UML 1 to talk about the metamodel that was put into an XML document -- this is the metamodel formally captured in MOF terms. I put quotes around "physical" because it seemed to be an incorrect use of the word. The issue is this: if there are operations and constraints that are defined formally in the specification to be part of the metamodel, then those operations and constraints should be included in the XML serialization of the metamodel along with the classes, attributes, etc. This is not an issue regarding XMI for UML 2. It is an issue that regards what is included in the XML documents referred to in the second paragraphs of appendix A of Infrastructure (ad/03-03-01) and appendix F of Superstructure (ad/03-04-01). Regards, Don -----Original Message----- From: Tolbert, Doug M Sent: Thursday, December 11, 2003 4:01 PM To: Baisley, Donald E Subject: FW: physical metamodel? -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, December 11, 2003 2:41 PM To: Tolbert, Doug M Subject: physical metamodel? Could you help me understand '"physical" metamodel' as Don used this phrase (including the double quotes) in the context of Issue 3126? I think it means the metamodel of UML as expressed in XMI. Is that right? As such it seems like an issue for specifying XMI 2 for UML 2, not an issue intrinsic to the UML 2 specs. Is that also right? Regards, Karl (I am reviewing all the Classes issues doing triage) For reference, here is the text: Summary: The "physical" metamodel should include the OCL constraints and operations defined in the UML Specification. This has been done in the MOF 1.3 specification. The operations provide valuable capabilities and should be part of the standard UML facility interfaces. Making the operations part of the "physical" metamodel allows them to be used when defining new constraints in extension metamodels, such as in CWM. Recommendation: Add the specification's constraints and operations to the "physical" metamodel. -----Original Message----- From: Karl Frank Sent: Friday, December 12, 2003 9:45 AM To: 'Jim Amsden'; Michael Latta Cc: UML Superstructure FTF Subject: [issue 3126] was: A proposal on Compliance from UML users Issue 3126 which was assigned to the "Classes" chapter 7 group for which I am the lead, is relevant to this topic. Issue 3126 was filed by Don Baisley of UniSys against UML 1 and remains relevant to UML 2 because UML 2 does not detail what portions of the wordy spec really count when judging conformance of a product with the metamodel. Issue 3126 notes that the UML 1.3 spec introduced OCL constraints and operations, but that the serialization of the metamodel in XML (see Appendix F of ptc/03-08-02) does not mandate the inclusion of these constraints and operations. I propose that the Issue 3126 is an issue against the incompleteness of the spec's definition of compliance. At present the UML 2 superstructure has only one sentence about what conformance to a compliance point means. That sentence is: "Unless otherwise qualified, complying with a package requires complying with its abstract syntax, well-formedness rules, semantics, notation, and XMI schema." (from page 2 of ptc/03-08-02) I propose that this sentence should be followed by a paragraph of explanation stating in detail what counts as "abstract syntax, well-formedness rules, semantics, notation, and XMI schema". For each model element, there are subsections in the spec with labels "semantics" and "notation", but there is no call-out of what counts as "well-formedness rules" and "abstract syntax". It is left for implementers to guess how (for example) abstract classes and operations should be supported in UML 2 compliant products. Issue 3126 proposes that the spec should explicitly explain that the serializatoin of the metamodel include the OCL constraints and operations, and by implication, it seems to propose that the definition of compliance with the metamodel shall include demonstration of support for those constraints and operations. Regards, Karl Frank -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, December 12, 2003 8:42 AM To: Michael Latta Cc: Karl Frank; UML Superstructure FTF Subject: RE: A proposal on Compliance from UML users Michael, Thanks for your patience too. I know this is pretty tedious stuff, and is recovering old ground thought to be resolved. I expect that the L-level will be part of the namespace URI in XMI instance documents referring to the specific XMI Schema used to validate those documents. The fact that there is a specific relationship between the XMI schemas identified by these URIs is not known by XMI or XML processors, but is known by the tools reading such documents and users of those tools. This is where the interoperability happens. "Michael Latta" 12/12/2003 02:02 AM To: Jim Amsden/Raleigh/IBM@IBMUS cc: "Karl Frank" , "UML Superstructure FTF" Subject: RE: A proposal on Compliance from UML users Jim, Thank you for your patience on this. Given what I saw on your EMF site this looks to be workable. We strongly want the L-level definitions to merge in the subset packages, not repeat the merges of fine-grained packages. This ensures that L(n) is a proper superset of L(n-1). I think it is up to the other language designers (CWM etc.) to chart their own course. They can use specialization, or repeat the UML2 example of package merge (either form). This list does not need to get into that. I presume there will be information in the header of the XMI document to indicate which L-level the content conforms to? Since the XMI namespace is not unique there needs to be some way to tell the intended reader level, or there is no point in defining L levels. From a user point of view there is value in knowing Tool A and Tool B agree on their subset of UML 2. But from a technical perspective is there value in knowing if file A conforms to level 3? Are XMI documents going to note the level they require for full import, or not bother? Will there in fact be only one XMI schema for the full language, with subsets being a documentation issue not a technical one? Michael -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Thursday, December 11, 2003 12:10 PM To: Michael Latta Cc: Karl Frank; UML Superstructure FTF Subject: RE: A proposal on Compliance from UML users Michael, The connection between the L-levels is defined by the specification. Ln is fully compatible with Ln+1. Nothing needs to be done to the XMI documents or client applications (assuming they use the same API generator of course). This is because Ln+1 always contains the same or more capabilities as Ln. This, and combine merge are the foundation of the IBM proposal, and it is this compatibility that we are looking for. We don't want to have to rely on specialization to provide the compatibility because it doesn't work for XMI and doesn't scale for API generation. This has nothing to do with mappings, we specifically define the compliance points contents, and how they are defined using package merge to avoid this very issue. The point of model-to-model mappings is for completely different metamodels such as CWM, Java, C, J2EE, etc., not different subsets of UML2. It is our contention that these different metamodels should not in general subclass UML2, but should rather be defined by MOF and relate to UML2 through a mapping. This is MUCH more flexible than using specialization and keeps UML2 decoupled from other metamodels. Abstract classes are not removed by package merge UNLESS the merged and merging class names match. In this case, the properties and associations are merged and are therefore available in the merging class. Nothing is missing from the model compared to the current package merge. It is just that the associations do not have to be both redefined in the merging class and inherited from the merged class. The meaning is the same. We have developed sample applications using both approaches, and they both do the same things. It just that the combine merge results in an API that is much simpler, smaller, doesn't require a lot of unpredictable downcasting, is fully compatible with another API that has more capabilities, etc. We have also implemented all of UML2 using our proposed approach and are actively developing various tools with it. So we're pretty sure this works. You can see the code at http://www.eclipse.org/uml2/. Anyway, our proposal is not for defining a mapping from UML2 to Java for some future JMI2. We only propose that combine merge be use to specify the compliance points, each compliance point is a subset of UML2, the compliance points a leveled subsets, and the XMI schemas for the compliance points are derived from the merged result. This is just about the specification itself. Tools are free to generate Java or other language APIs that exploit inheritance or delegation as they wish to achieve similar results in the platform specific domain. Such tools can leverage the definition of package merge to merge model fragments as part of their API generation, and do not have to start with the merged results as given in the spec. There is no implication that an API must exactly match a one-to-one mapping with the merged packages. Only that the behavior of XMI interchange is maintained and applications using an API should expect to be compatible with a subsequent generation of that API that includes more capabilities. "Michael Latta" 12/11/2003 02:25 PM To: Jim Amsden/Raleigh/IBM@IBMUS cc: "Karl Frank" , "UML Superstructure FTF" Subject: RE: A proposal on Compliance from UML users Jim, While in theory the IBM proposal is similar in structure, the devil is in the details. By using the COMBINE form of package merge, as your message indicated, there would be no real connection between your L levels. Each would be an independent language with no abstract classes in common. While I understand your argument that model transformation is the connection, we are not willing to accept that as the solution. We are well along the route to implementation and do not want to end up with 4 independent metamodels that "happen" to be subsets of each other. We are also concerned about the impact of COMBINE on the resulting model. COMBINE was defined to support EMOF by removing abstract classes and redefinitions, doing this to Superstructure as defined would be a huge problem as there are numerous concrete classes and associations that would need to be manipulated independently, rather than being manipulated via the abstract classes. Michael -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, December 10, 2003 9:25 AM To: Michael Latta Cc: Karl Frank; UML Superstructure FTF Subject: RE: A proposal on Compliance from UML users Michael, Your suggestion is compatible with the IBM proposal. We propose that tool vendors say what compliance point they are compatible with, and what additional capabilities they support. These capabilities are also specified in the UML2 specification and correspond to merged packages. We also propose a single UML2 language captured in a package such as org::omg::uml and that package merge be used to include capabilities into this package to define a compliance point. Our compliance points L0, L1, and L2 correspond to subset levels, with compliance point L3 corresponding to the whole UML2 language. Each compliance point schema is a subset of the next higher compliance point schema making them completely compatible. "Michael Latta" 12/10/2003 12:06 PM To: "Karl Frank" cc: "UML Superstructure FTF" Subject: RE: A proposal on Compliance from UML users We feel that a requirement such as this should be required of all tool vendors for UML 2.0. This is the kind of reference a user needs to make the spec have meaning, and at least shows that someone in the tool company read the spec enough to state their compatibility. But, it does not address HOW the tool will be compatible. Random selection of packages or metaclasses from the spec will not yield a coherent XMI schema. How to define a schema is a key issue. One option is to define only one UML schema for the full language and allow tools to implement their chosen subsets. This is becoming more and more appealing as this discussion progresses. This guarantees one API and one XMI schema that vendors can choose to implement subsets of. Those subsets would be defined as in this statement. Michael -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Tuesday, December 09, 2003 6:35 PM Cc: UML Superstructure FTF Subject: A proposal on Compliance from UML users An engineer at Raytheon made the following concrete proposal to Borland, with goal of improving the definition of compliance. The point of this simple recommendation is that it is consistent with a complex fine-grained compliance scheme and equally consistent with a coarse-grained scheme, and renders either scheme more useful and verifiable, without respect to how compliance testing is (or is not) defined. In brief, the recommendation is that any product that claims compliance of ANY sort with UML must publish a list of exactly what PORTION of the spec it complies with. The proposal requires only a minimal edit to the spec, perhaps a line as follows: Any product that claims compliance with this specification shall list the elements of the metamodel it implements. This list shall identify elements of the metamodel in terms of sections this specification, and shall be published as part of the product documentation in the language of that documentation. as for example, assuming English language documentation set This product implements all the concrete metaclasses specified in Chapter 7. This product implements all the metaclasses, both abstract and concrete, as specified in StateMachines::BehaviorStateMachines, and provide the XMI 2 functionality to export and import models expressed in compliance with that metamodel. - Regards, Karl Frank Subject: RE: [issue 3126] - and FTF process issue Date: Mon, 15 Dec 2003 08:35:52 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [issue 3126] - and FTF process issue Thread-Index: AcPAtdYp9ltx7kVZRMO3V94UvLwdfgABggJAAAxQh0AAh/eN0A== From: "Pete Rivett" To: "Karl Frank" , "Baisley, Donald E" Cc: , "UML Superstructure FTF" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id hBFDVZNA006371 I agree with the sentiment of Karl's proposal - indeed it's akin to what I proposed along the lines of treating the UML2 abstract syntax as a PIM/specification for tools (which implies that tools need to address the constraints etc). However I do not agree that it's part of Issue 3126 which is merely about whether the OCL is serialized in the XMI for UML2 metamodel itself, which it now is. IMHO we should take care to address the issues as written/submitted and not to try to re-interpret them in the light of more recent knowledge and even what the issue raiser may think today: by amazing coincidence today happens to be the 4th birthday of the issue (it was received on Dec 15th 1999)! An important process point on issue 3126: though this is a shared issue, it is assigned to the MOF2/Infrastructure FTF as the lead, according to Bran's issue assignment spreadsheet. The procedure is that it's up to the lead FTF to propose a resolution and then agree it with the other FTF (and then it gets voted on in each): for such issues the workgroup assignment within Superstructure indicates who should specifically review such changes proposed by the MU2I FTF. Consequently I have included a resolution for 3126, along with about 30 other shared issues, in the MU2I Draft Ballot 2 I sent out last week (to both FTFs): issue 3126 and resolution are below FYI. If the above procedure was not apparent to people please let me know how much time you'd like to review my draft resolutions (they are all 'close no change' except one which just added a new constraint): I'd rather delay than have problems arise during the formal ballot period. I'm wondering if there are other issues where we are duplicating work between the FTFs? Original Issue 3126: ----- The "physical" metamodel should include the OCL constraints and operations defined in the UML Specification. This has been done in the MOF 1.3 specification. The operations provide valuable capabilities and should be part of the standard UML facility interfaces. Making the operations part of the "physical" metamodel allows them to be used when defining new constraints in extension metamodels, such as in CWM. Recommendation: Add the specification's constraints and operations to the "physical" metamodel. Note that adding constraints and operations will affect IDL, but it will not affect XMI DTDs. ------ Proposed Resolution from MU2I FTF: ------------ In UML 2.0 the adopted XMI representation of the metamodel does contain the operations used in defining the abstract semantics. Disposition: Closed, no change ------------ Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, 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: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Friday, December 12, 2003 8:24 PM > To: UML Superstructure FTF; Baisley, Donald E > Subject: RE: [issue 3126] was: A proposal on Compliance from UML users > > Don Baisley's comments, re: issue 3126 which were in answer > to my questions are relevant to the whole FTF discussion on > compliance. I asked Don: > > > Would you agree that issue 3126 should be positioned as an > > issue for Compliance and Appendix F? > > He answered: > > Yes I would. There needs to be a formal collection of rules (as there > is for the other metamodel elements) that establishes a basis of > conformance. Of course, this would allow the use of > automated tools to > test whether the specification's own use of operations and constraints > was conformant -- something never done before. > > Regards, > Don > > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Friday, December 12, 2003 5:51 AM > To: Baisley, Donald E > Cc: Tolbert, Doug M > Subject: RE: physical metamodel? > > Thanks for the speedy and clear response. There is a question at the > end. > > In my opinion, this means the issue is relevant to the definition of > compliance, in addition to being relevant to Appendix F. For > if Appendix > F permits some information in the document to be omitted from the > serialized representation of the metamodel, that ommission > would result > in that information being unavailable in that form for establishing > conformance. > > The UML 2 provision for four values of compliance at any one of 38 > compliance points includes two, complete and xmi which I > think should be > understood in light of what must go into the serialized representation > of the metamodel of UML 2. > > I propose to bring issue 3126 into the FTF's current high-priority > discussion of the definition of "compliance" which occurs > otherwise only > on pages 1-3 (as printed, about p 12 of electronic pdf) of the final > adopted spec, and consists of this one woefully incomplete bit: > > "Unless otherwise qualified, complying with a package requires > complying with its abstract syntax, well-formedness rules, semantics, > notation, and XMI schema." (from page 2 of ptc/03-08-02) > > (I especially hate it that well-formedness rules are > scattered among the > semantics, definition, and constraints sections.) > > Would you agree that this should be positioned as an issue for > Compliance and Appendix F? > > - Karl > > > > -----Original Message----- > From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] > Sent: Thursday, December 11, 2003 9:38 PM > To: Karl Frank > Cc: Tolbert, Doug M > Subject: RE: physical metamodel? > > > The word "physical" was used in UML 1 to talk about the metamodel that > was put into an XML document -- this is the metamodel > formally captured > in MOF terms. I put quotes around "physical" because it > seemed to be an > incorrect use of the word. > > The issue is this: if there are operations and constraints that are > defined formally in the specification to be part of the > metamodel, then > those operations and constraints should be included in the XML > serialization of the metamodel along with the classes, > attributes, etc. > > This is not an issue regarding XMI for UML 2. It is an issue that > regards what is included in the XML documents referred to in > the second > paragraphs of appendix A of Infrastructure (ad/03-03-01) and > appendix F > of Superstructure (ad/03-04-01). > > Regards, > Don > > -----Original Message----- > From: Tolbert, Doug M > Sent: Thursday, December 11, 2003 4:01 PM > To: Baisley, Donald E > Subject: FW: physical metamodel? > > > > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Thursday, December 11, 2003 2:41 PM > To: Tolbert, Doug M > Subject: physical metamodel? > > > Could you help me understand '"physical" metamodel' as Don used this > phrase (including the double quotes) in the context of Issue 3126? > > I think it means the metamodel of UML as expressed in XMI. Is that > right? > > As such it seems like an issue for specifying XMI 2 for UML 2, not an > issue intrinsic to the UML 2 specs. Is that also right? > > Regards, Karl > > (I am reviewing all the Classes issues doing triage) > > For reference, here is the text: > > Summary: > The "physical" metamodel should include the OCL constraints and > operations defined in the UML Specification. This has been > done in the > MOF 1.3 specification. The operations provide valuable > capabilities and > should be part of the standard UML facility interfaces. Making the > operations part of the "physical" metamodel allows them to be > used when > defining new constraints in extension metamodels, such as in CWM. > > Recommendation: Add the specification's constraints and operations to > the "physical" metamodel. > > > > > -----Original Message----- > From: Karl Frank > Sent: Friday, December 12, 2003 9:45 AM > To: 'Jim Amsden'; Michael Latta > Cc: UML Superstructure FTF > Subject: [issue 3126] was: A proposal on Compliance from UML users > > > Issue 3126 which was assigned to the "Classes" chapter 7 > group for which I am the lead, is relevant to this topic. > > Issue 3126 was filed by Don Baisley of UniSys against UML 1 > and remains relevant to UML 2 because UML 2 does not detail > what portions of the wordy spec really count when judging > conformance of a product with the metamodel. > > Issue 3126 notes that the UML 1.3 spec introduced OCL > constraints and operations, but that the serialization of the > metamodel in XML (see Appendix F of ptc/03-08-02) does not > mandate the inclusion of these constraints and operations. > > I propose that the Issue 3126 is an issue against the > incompleteness of the spec's definition of compliance. At > present the UML 2 superstructure has only one sentence about > what conformance to a compliance point means. That sentence is: > > "Unless otherwise qualified, complying with a package > requires complying with its abstract syntax, well-formedness > rules, semantics, notation, a Subject: RE: [issue 3126] - and FTF process issue Date: Mon, 15 Dec 2003 09:04:31 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [issue 3126] - and FTF process issue Thread-Index: AcPAtdYp9ltx7kVZRMO3V94UvLwdfgABggJAAAxQh0AAh/eN0AABw+qg From: "Karl Frank" To: "Pete Rivett" , "Baisley, Donald E" Cc: , "UML Superstructure FTF" X-OriginalArrivalTime: 15 Dec 2003 14:04:36.0578 (UTC) FILETIME=[5F846420:01C3C314] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id hBFE26NA006982 Pete, Hi. Thanks, I stand corrected wrt the process issue. I simply overlooked the assignment to MOF2/InfraStructure in pursuing this issue. - Karl -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Monday, December 15, 2003 8:36 AM To: Karl Frank; Baisley, Donald E Cc: mu2i-ftf@omg.org; UML Superstructure FTF Subject: RE: [issue 3126] - and FTF process issue I agree with the sentiment of Karl's proposal - indeed it's akin to what I proposed along the lines of treating the UML2 abstract syntax as a PIM/specification for tools (which implies that tools need to address the constraints etc). However I do not agree that it's part of Issue 3126 which is merely about whether the OCL is serialized in the XMI for UML2 metamodel itself, which it now is. IMHO we should take care to address the issues as written/submitted and not to try to re-interpret them in the light of more recent knowledge and even what the issue raiser may think today: by amazing coincidence today happens to be the 4th birthday of the issue (it was received on Dec 15th 1999)! An important process point on issue 3126: though this is a shared issue, it is assigned to the MOF2/Infrastructure FTF as the lead, according to Bran's issue assignment spreadsheet. The procedure is that it's up to the lead FTF to propose a resolution and then agree it with the other FTF (and then it gets voted on in each): for such issues the workgroup assignment within Superstructure indicates who should specifically review such changes proposed by the MU2I FTF. Consequently I have included a resolution for 3126, along with about 30 other shared issues, in the MU2I Draft Ballot 2 I sent out last week (to both FTFs): issue 3126 and resolution are below FYI. If the above procedure was not apparent to people please let me know how much time you'd like to review my draft resolutions (they are all 'close no change' except one which just added a new constraint): I'd rather delay than have problems arise during the formal ballot period. I'm wondering if there are other issues where we are duplicating work between the FTFs? Original Issue 3126: ----- The "physical" metamodel should include the OCL constraints and operations defined in the UML Specification. This has been done in the MOF 1.3 specification. The operations provide valuable capabilities and should be part of the standard UML facility interfaces. Making the operations part of the "physical" metamodel allows them to be used when defining new constraints in extension metamodels, such as in CWM. Recommendation: Add the specification's constraints and operations to the "physical" metamodel. Note that adding constraints and operations will affect IDL, but it will not affect XMI DTDs. ------ Proposed Resolution from MU2I FTF: ------------ In UML 2.0 the adopted XMI representation of the metamodel does contain the operations used in defining the abstract semantics. Disposition: Closed, no change ------------ Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, 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: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Friday, December 12, 2003 8:24 PM > To: UML Superstructure FTF; Baisley, Donald E > Subject: RE: [issue 3126] was: A proposal on Compliance from UML users > > Don Baisley's comments, re: issue 3126 which were in answer > to my questions are relevant to the whole FTF discussion on > compliance. I asked Don: > > > Would you agree that issue 3126 should be positioned as an > > issue for Compliance and Appendix F? > > He answered: > > Yes I would. There needs to be a formal collection of rules (as there > is for the other metamodel elements) that establishes a basis of > conformance. Of course, this would allow the use of > automated tools to > test whether the specification's own use of operations and constraints > was conformant -- something never done before. > > Regards, > Don > > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Friday, December 12, 2003 5:51 AM > To: Baisley, Donald E > Cc: Tolbert, Doug M > Subject: RE: physical metamodel? > > Thanks for the speedy and clear response. There is a question at the > end. > > In my opinion, this means the issue is relevant to the definition of > compliance, in addition to being relevant to Appendix F. For > if Appendix > F permits some information in the document to be omitted from the > serialized representation of the metamodel, that ommission > would result > in that information being unavailable in that form for establishing > conformance. > > The UML 2 provision for four values of compliance at any one of 38 > compliance points includes two, complete and xmi which I > think should be > understood in light of what must go into the serialized representation > of the metamodel of UML 2. > > I propose to bring issue 3126 into the FTF's current high-priority > discussion of the definition of "compliance" which occurs > otherwise only > on pages 1-3 (as printed, about p 12 of electronic pdf) of the final > adopted spec, and consists of this one woefully incomplete bit: > > "Unless otherwise qualified, complying with a package requires > complying with its abstract syntax, well-formedness rules, semantics, > notation, and XMI schema." (from page 2 of ptc/03-08-02) > > (I especially hate it that well-formedness rules are > scattered among the > semantics, definition, and constraints sections.) > > Would you agree that this should be positioned as an issue for > Compliance and Appendix F? > > - Karl > > > > -----Original Message----- > From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] > Sent: Thursday, December 11, 2003 9:38 PM > To: Karl Frank > Cc: Tolbert, Doug M > Subject: RE: physical metamodel? > > > The word "physical" was used in UML 1 to talk about the metamodel that > was put into an XML document -- this is the metamodel > formally captured > in MOF terms. I put quotes around "physical" because it > seemed to be an > incorrect use of the word. > > The issue is this: if there are operations and constraints that are > defined formally in the specification to be part of the > metamodel, then > those operations and constraints should be included in the XML > serialization of the metamodel along with the classes, > attributes, etc. > > This is not an issue regarding XMI for UML 2. It is an issue that > regards what is included in the XML documents referred to in > the second > paragraphs of appendix A of Infrastructure (ad/03-03-01) and > appendix F > of Superstructure (ad/03-04-01). > > Regards, > Don > > -----Original Message----- > From: Tolbert, Doug M > Sent: Thursday, December 11, 2003 4:01 PM > To: Baisley, Donald E > Subject: FW: physical metamodel? > > > > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Thursday, December 11, 2003 2:41 PM > To: Tolbert, Doug M > Subject: physical metamodel? > > > Could you help me understand '"physical" metamodel' as Don used this > phrase (including the double quotes) in the context of Issue 3126? > > I think it means the metamodel of UML as expressed in XMI. Is that > right? > > As such it seems like an issue for specifying XMI 2 for UML 2, not an > issue intrinsic to the UML 2 specs. Is that also right? > > Regards, Karl > > (I am reviewing all the Classes issues doing triage) > > For reference, here is the text: > > Summary: > The "physical" metamodel should include the OCL constraints and > operations defined in the UML Specification. This has been > done in the > MOF 1.3 specification. The operations provide valuable > capabilities and > should be part of the standard UML facility interfaces. Making the > operations part of the "physical" metamodel allows them to be > used when > defining new constraints in extension metamodels, such as in CWM. > > Recommendation: Add the specification's constraints and operations to > the "physical" metamodel. > > > > > -----Original Message----- > From: Karl Frank > Sent: Friday, December 12, 2003 9:45 AM > To: 'Jim Amsden'; Michael Latta > Cc: UML Superstructure FTF > Subject: [issue 3126] was: A proposal on Compliance from UML users > > > Issue 3126 which was assigned to the "Classes" chapter 7 > group for which I am the lead, is relevant to this topic. > > Issue 3126 was filed by Don Baisley of UniSys against UML 1 > and remains relevant to UML 2 because UML 2 does not detail > what portions of the wordy spec really count when judging > conformance of a product with the metamodel. > > Issue 3126 notes that the UML 1.3 spec introduced OCL > constraints and operations, but that the serialization of the > metamodel in XML (see Appendix F of ptc/03-08-02) does not > mandate the inclusion of these constraints and operations. > > I propose that the Issue 3126 is an issue against the > incompleteness of the spec's definition of compliance. At > present the UML 2 superstructure has only one sentence about > what conformance to a compliance point means. That sentence is: > > "Unless otherwise qualified, complying with a package > requires complying with its abstract syntax, well-formedness > rules, semantics, notation, and XMI schema." (from page 2 of > ptc/03-08-02) > > I propose that this sentence should be followed by a > paragraph of explanation stating in detail what counts as > "abstract syntax, well-formedness rules, semantics, notation, > and XMI schema". For each model element, there are > subsections in the spec with labels "semantics" and > "notation", but there is no call-out of what counts as > "well-formedness rules" and "abstract syntax". It is left > for implementers to guess how (for example) abstract classes > and operations should be supported in UML 2 compliant products. > > Issue 3126 proposes that the spec should explicitly explain > that the serializatoin of the metamodel include the OCL > constraints and operations, and by implication, it seems to > propose that the definition of compliance with the metamodel > shall include demonstration of support for those constraints > and operations. > > Regards, Karl Frank > > -----Original Message----- > From: Jim Amsden [mailto:jamsden@us.ibm.com] > Sent: Friday, December 12, 2003 8:42 AM > To: Michael Latta > Cc: Karl Frank; UML Superstructure FTF > Subject: RE: A proposal on Compliance from UML users > > > Michael, > Thanks for your patience too. I know this is pretty tedious > stuff, and is > recovering old ground thought to be resolved. > > I expect that the L-level will be part of the namespace URI in XMI > instance documents referring to the specific XMI Schema used > to validate > those documents. The fact that there is a specific > relationship between > the XMI schemas identified by these URIs is not known by XMI or XML > processors, but is known by the tools reading such documents > and users of > those tools. This is where the interoperability happens. > > > > > > "Michael Latta" > 12/12/2003 02:02 AM > > To: Jim Amsden/Raleigh/IBM@IBMUS > cc: "Karl Frank" , "UML > Superstructure > FTF" > Subject: RE: A proposal on Compliance from UML users > > > Jim, > > Thank you for your patience on this. Given what I saw on > your EMF site > this looks to be workable. We strongly want the L-level > definitions to > merge in the subset packages, not repeat the merges of fine-grained > packages. This ensures that L(n) is a proper superset of L(n-1). > > I think it is up to the other language designers (CWM etc.) to chart > their own course. They can use specialization, or repeat the UML2 > example of package merge (either form). This list does not > need to get > into that. > > I presume there will be information in the header of the XMI > document to > indicate which L-level the content conforms to? Since the > XMI namespace > is not unique there needs to be some way to tell the intended reader > level, or there is no point in defining L levels. From a > user point of > view there is value in knowing Tool A and Tool B agree on their subset > of UML 2. But from a technical perspective is there value in > knowing if > file A conforms to level 3? Are XMI documents going to note the level > they require for full import, or not bother? Will there in > fact be only > one XMI schema for the full language, with subsets being a > documentation > issue not a technical one? > > Michael > > > > -----Original Message----- > From: Jim Amsden [mailto:jamsden@us.ibm.com] > Sent: Thursday, December 11, 2003 12:10 PM > To: Michael Latta > Cc: Karl Frank; UML Superstructure FTF > Subject: RE: A proposal on Compliance from UML users > > Michael, > The connection between the L-levels is defined by the > specification. Ln > is > fully compatible with Ln+1. Nothing needs to be done to the XMI > documents > or client applications (assuming they use the same API generator of > course). This is because Ln+1 always contains the same or more > capabilities as Ln. This, and combine merge are the foundation of the > IBM > proposal, and it is this compatibility that we are looking > for. We don't > > want to have to rely on specialization to provide the compatibility > because it doesn't work for XMI and doesn't scale for API generation. > > This has nothing to do with mappings, we specifically define the > compliance points contents, and how they are defined using > package merge > > to avoid this very issue. The point of model-to-model mappings is for > completely different metamodels such as CWM, Java, C, J2EE, etc., not > different subsets of UML2. It is our contention that these different > metamodels should not in general subclass UML2, but should rather be > defined by MOF and relate to UML2 through a mapping. This is > MUCH more > flexible than using specialization and keeps UML2 decoupled > from other > metamodels. > > Abstract classes are not removed by package merge UNLESS the > merged and > merging class names match. In this case, the properties and > associations > > are merged and are therefore available in the merging class. > Nothing is > missing from the model compared to the current package merge. > It is just > > that the associations do not have to be both redefined in the merging > class and inherited from the merged class. The meaning is the > same. We > have developed sample applications using both approaches, and > they both > do > the same things. It just that the combine merge results in an API that > is > much simpler, smaller, doesn't require a lot of unpredictable > downcasting, > is fully compatible with another API that has more capabilities, etc. > > We have also implemented all of UML2 using our proposed > approach and are > > actively developing various tools with it. So we're pretty sure this > works. You can see the code at http://www.eclipse.org/uml2/. > > Anyway, our proposal is not for defining a mapping from UML2 > to Java for > > some future JMI2. We only propose that combine merge be use to specify > the > compliance points, each compliance point is a subset of UML2, the > compliance points a leveled subsets, and the XMI schemas for the > compliance points are derived from the merged result. This is > just about > > the specification itself. Tools are free to generate Java or other > language APIs that exploit inheritance or delegation as they wish to > achieve similar results in the platform specific domain. Such > tools can > leverage the definition of package merge to merge model fragments as > part > of their API generation, and do not have to start with the merged > results > as given in the spec. There is no implication that an API > must exactly > match a one-to-one mapping with the merged packages. Only that the > behavior of XMI interchange is maintained and applications > using an API > should expect to be compatible with a subsequent generation > of that API > that includes more capabilities. > > > > > > > "Michael Latta" > 12/11/2003 02:25 PM > > To: Jim Amsden/Raleigh/IBM@IBMUS > cc: "Karl Frank" , "UML > Superstructure > FTF" > Subject: RE: A proposal on Compliance from UML users > > > Jim, > > While in theory the IBM proposal is similar in structure, the devil is > in the details. By using the COMBINE form of package merge, as your > message indicated, there would be no real connection between your L > levels. Each would be an independent language with no > abstract classes > in common. While I understand your argument that model transformation > is the connection, we are not willing to accept that as the solution. > We are well along the route to implementation and do not want > to end up > with 4 independent metamodels that "happen" to be subsets of > each other. > We are also concerned about the impact of COMBINE on the resulting > model. COMBINE was defined to support EMOF by removing > abstract classes > and redefinitions, doing this to Superstructure as defined would be a > huge problem as there are numerous concrete classes and associations > that would need to be manipulated independently, rather than being > manipulated via the abstract classes. > > Michael > > > > -----Original Message----- > From: Jim Amsden [mailto:jamsden@us.ibm.com] > Sent: Wednesday, December 10, 2003 9:25 AM > To: Michael Latta > Cc: Karl Frank; UML Superstructure FTF > Subject: RE: A proposal on Compliance from UML users > > Michael, > Your suggestion is compatible with the IBM proposal. We propose that > tool > vendors say what compliance point they are compatible with, and what > additional capabilities they support. These capabilities are also > specified in the UML2 specification and correspond to merged packages. > We > also propose a single UML2 language captured in a package such as > org::omg::uml and that package merge be used to include capabilities > into > this package to define a compliance point. Our compliance > points L0, L1, > > and L2 correspond to subset levels, with compliance point L3 > corresponding to the whole UML2 language. Each compliance point schema > is > a subset of the next higher compliance point schema making them > completely > compatible. > > > > > > "Michael Latta" > 12/10/2003 12:06 PM > > To: "Karl Frank" > cc: "UML Superstructure FTF" > > Subject: RE: A proposal on Compliance from UML users > > > We feel that a requirement such as this should be required of > all tool > vendors for UML 2.0. This is the kind of reference a user > needs to make > > the spec have meaning, and at least shows that someone in the tool > company > read the spec enough to state their compatibility. But, it does not > address HOW the tool will be compatible. Random selection of packages > or > metaclasses from the spec will not yield a coherent XMI > schema. How to > define a schema is a key issue. One option is to define only one UML > schema for the full language and allow tools to implement > their chosen > subsets. This is becoming more and more appealing as this discussion > progresses. This guarantees one API and one XMI schema that > vendors can > > choose to implement subsets of. Those subsets would be defined as in > this > statement. > > Michael > > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Tuesday, December 09, 2003 6:35 PM > Cc: UML Superstructure FTF > Subject: A proposal on Compliance from UML users > > An engineer at Raytheon made the following concrete proposal > to Borland, > > with goal of improving the definition of compliance. The > point of this > simple recommendation is that it is consistent with a complex > fine-grained > compliance scheme and equally consistent with a coarse-grained scheme, > and > renders either scheme more useful and verifiable, without > respect to how > > compliance testing is (or is not) defined. > In brief, the recommendation is that any product that claims > compliance > of > ANY sort with UML must publish a list of exactly what PORTION of the > spec > it complies with. > The proposal requires only a minimal edit to the spec, > perhaps a line as > > follows: > > Any product that claims compliance with this specification shall list > the > elements of the metamodel it implements. This list shall identify > elements of the metamodel in terms of sections this > specification, and > shall be published as part of the product documentation in > the language > of > that documentation. > as for example, assuming English language documentation set > > This product implements all the concrete metaclasses specified in > Chapter > 7. > This product implements all the metaclasses, both abstract > and concrete, > > as specified in StateMachines::BehaviorStateMachines, and provide the > XMI > 2 functionality to export and import models expressed in > compliance with > > that metamodel. > - Regards, Karl Frank > > > > > > From: Edwin Seidewitz To: "'Karl Frank'" Cc: UML Superstructure FTF Subject: RE: [issue 3126 AND issue 6248] was: A proposal on Compliance fro m UML users Date: Fri, 12 Dec 2003 18:30:31 -0500 X-Mailer: Internet Mail Service (5.5.2655.55) Karl -- Issue 6248 (the one issue I actually managed to submit) relates directly to the points you make on the lack of clarity in the definition of compliance in the adopted spec. In the text of that issue, I make the recommendation using the compliance discussion in the 2U proposal (ad/2003-01-08) as a basis. I think the 2U proposal contained a particularly good discussion of compliance in Section 0.8, separately addressing XMI, syntax and semantics compliance. (I will try to put together a proposal of specific text for this next week -- but I am just about to head out for the weekend right now...) By the way, I think this is already in the compliance and package merge issues list as part of "defining the dimensions of compliance". To define these dimensions, the spec needs to give a clear definition of what "compliance" means for each dimension. -- Ed Subject: RE: [issue 3126 AND issue 6248] was: A proposal on Compliance from UML users Date: Fri, 12 Dec 2003 20:18:19 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [issue 3126 AND issue 6248] was: A proposal on Compliance from UML users Thread-Index: AcPBCAEj7Z/oZWeYQGyEWXD2Dh9kxwADcrOg From: "Karl Frank" To: "Edwin Seidewitz" Cc: "UML Superstructure FTF" X-OriginalArrivalTime: 13 Dec 2003 01:18:20.0812 (UTC) FILETIME=[FEFFBCC0:01C3C116] Good to be able to discover commonalities to batch some of these more difficult issues instead of working on them in isolation. 3126 was assigned to Classes and hence me, 6248 was recognized from the start as General and hence is on Bran's list. Let's make sure we contintue to consider them together and search out the others that go with them. So the next question is, what other issues turn out, on analysis or on the face of them, to be issues on Dimensions of Compliance? The issue in the compliance and package merge priority list as "defining the dimensions of compliance" does cover these issues, but it is NOT the case that it was known that these issues 3126 and 6248 were under that heading. That heading was not derived from any particular reported issues, but was by consensus of the London joint meeting added to a list of problems the attendees were most concerned about. What I propose is that each team, but especially the General group, should sort out what issue NUMBERS fall under the heading "defining the dimensions of compliance" and add them to the list begun here, so we can consider them as a batch. 3126 6248 -----Original Message----- From: Edwin Seidewitz [mailto:eseidewitz@intelidata.com] Sent: Friday, December 12, 2003 6:31 PM To: Karl Frank Cc: UML Superstructure FTF Subject: RE: [issue 3126 AND issue 6248] was: A proposal on Compliance from UML users Karl -- Issue 6248 (the one issue I actually managed to submit) relates directly to the points you make on the lack of clarity in the definition of compliance in the adopted spec. In the text of that issue, I make the recommendation using the compliance discussion in the 2U proposal (ad/2003-01-08) as a basis. I think the 2U proposal contained a particularly good discussion of compliance in Section 0.8, separately addressing XMI, syntax and semantics compliance. (I will try to put together a proposal of specific text for this next week -- but I am just about to head out for the weekend right now...) By the way, I think this is already in the compliance and package merge issues list as part of "defining the dimensions of compliance". To define these dimensions, the spec needs to give a clear definition of what "compliance" means for each dimension. -- Ed