Issue 16913: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) (sbvr-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Revision Severity: Critical Summary: Section 13.2.5 is based on a misunderstanding and misuse of MOF: a) the phrase “In each case where an attribute and an association end represent the same role, the SBVR Metamodel includes a tag that tags both the attribute and the association end. “ is in ignorance of the fact that in MOF2 and UML 2 that “attributes” and “association ends” are both represented as instances of Property: and in such a case there would be a single instance of Property linked to the Class using the attribute meta-property and from the Association by the memberEnd (or ownedEnd) property: eliminating the need to link two separate elements. b) attempting to use MOF Tags to link two properties. In fact MOF Tags are “Simple string name-value pairs”. This is an urgent issue since it affects the production of the SBVR 1.1 artifacts: there is in fact no need for the tags that have caused some of the difficulties producing the machine-readable files: even the file I sent today for the metamodel, which uses the Tag value property does not match this section of the spec which states that value is the empty string. Resolution: Revised Text: Actions taken: December 15, 2011: received issue Discussion: End of Annotations:===== ubject: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Thu, 15 Dec 2011 16:50:43 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: Acy7jLlYRtB6JAE9TPq9DhbQaHkB0Q== From: "Pete Rivett" To: , Cc: , Section 13.2.5 is based on a misunderstanding and misuse of MOF: a) the phrase .In each case where an attribute and an association end represent the same role, the SBVR Metamodel includes a tag that tags both the attribute and the association end. . is in ignorance of the fact that in MOF2 and UML 2 that .attributes. and .association ends. are both represented as instances of Property: and in such a case there would be a single instance of Property linked to the Class using the attribute meta-property and from the Association by the memberEnd (or ownedEnd) property: eliminating the need to link two separate elements. b) attempting to use MOF Tags to link two properties. In fact MOF Tags are .Simple string name-value pairs.. This is an urgent issue since it affects the production of the SBVR 1.1 artifacts: there is in fact no need for the tags that have caused some of the difficulties producing the machine-readable files: even the file I sent today for the metamodel, which uses the Tag value property does not match this section of the spec which states that value is the empty string. Pete From: "Rouquette, Nicolas F (313K)" To: Donald Chapin CC: "issues@omg.org" , Andrew Watson , Pete Rivett Date: Sat, 17 Dec 2011 12:30:19 -0800 Subject: Re: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Topic: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: Acy8+rIroMBQX79/T5+svo2PI3cOew== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Don, Pete's issue is legitimate. I suggest generating the SBVR metamodel such that: - all associations have their memberEnds owned by classes -- i.e., no association-owned ends. - remove the class properties to which you had previously applied SBVR's sameRoleAs tag. I also noticed that some associations have nested element import relationships. What are these for? My QVTO engine currently supports MD 17.0, not 17.0.1 so please remember to send me an MD 17.0 model of SBVR with the fixes made. - Nicolas. On Dec 15, 2011, at 4:50 PM, Pete Rivett wrote: Section 13.2.5 is based on a misunderstanding and misuse of MOF: a) the phrase .In each case where an attribute and an association end represent the same role, the SBVR Metamodel includes a tag that tags both the attribute and the association end. . is in ignorance of the fact that in MOF2 and UML 2 that .attributes. and .association ends. are both represented as instances of Property: and in such a case there would be a single instance of Property linked to the Class using the attribute meta-property and from the Association by thememberEnd (or ownedEnd) property: eliminating the need to link two separate elements. b) attempting to use MOF Tags to link two properties. In fact MOF Tags are .Simple string name-value pairs.. This is an urgent issue since it affects the production of the SBVR 1.1 artifacts: there is in fact no need for the tags that have caused some of the difficulties producing the machine-readable files: even the file I sent today for the metamodel, which uses the Tag value property does not match this section of the spec which states that value is the empty string. Pete From: "Rouquette, Nicolas F (313K)" To: Donald Chapin CC: "issues@omg.org" , Andrew Watson , Pete Rivett Date: Sat, 17 Dec 2011 19:50:32 -0800 Subject: Re: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Topic: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: Acy9ODGg5th7MhdYQnm8My7n9O2Fmw== 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 Don, See below. On Dec 17, 2011, at 6:35 PM, Donald Chapin wrote: Hi Nicolas, The SBVR v1.1 is finished and any change to the definition of .sameRole. requires an Issue and a Ballot. When we make that fix is up to Andrew and whether or not he determines it to be an Urgent Issue. Yes, it's Andrew's call. However, the solution will not be to change who the association ends belong to. SBVR is specifically not an .attribute-based. specification. Rather it uses a fact-based paradigm. SBVR.s use of MOF as defined in Clause 13 reflects this. Indeed, SBVR1.1 says: 13.2.4 MOF Associations for SBVR Binary Verb Concepts MOF Elements of the SBVR Metamodel Each binary verb concept is represented in MOF terms as an association. Association names match verb concept wordings. If a verb concept has only one verb concept wording, the association's name is the expression of that verb concept wording, but with subscripts raised to normal text. The names of the association's ends are the placeholder expressions from the verb concept wording. The ends are owned by the association so that individual links can be serialized using XMI. However, the resolution of issue 9695 in MOF 2.4.1 makes the last sentence unnecessary; see section 8.2.1 (EBNF rules for XML Schema production) 7. Issue 9695: remove .unreferenced. and add clarification The declaration of an Association consists of the names of its AssociationEnd XML elements (whether or not they are owned by the Association). If anything, this confirms that not having an executable OMG specification for the MOF XML Schema & Document production rules specified in EBNF in the MOF/XMI actually creates problems within OMG specifications. In this case, the point is that the clarifications introduced in MOF 2.4.1, section 8.2.1, rule 7 make the definition of the MOF tag "sameRoleAs" in SBVR 1.1 logically redundant and introduce an unnecessary complication in the definition of the SBVR 1.1 MOF 2.4.1 metamodel. I.m traveling back to London tomorrow and all night Sunday night. I.m be back in touch as soon as I can get back into work after the trip; maybe Monday afternoon, for sure Tuesday. ok. The element import relationships define synonyms or alias. All this is exactly how it was done in SBVR v1.0. The SBVR v1.1 RTF made absolutely no changes in the way that SBVR uses MOF as a syntax to interchange SBVR semantics. As far as MOF 2.4.1 is concerned, ElementImport has no relevance for XML Schema or Document production. I understand that they are important for SBVR but they are effectively ignored for XML Schema/Document production per MOF/XMI 2.4.1. - Nicolas. I have implemented the Magic Draw as the SBVR Clause 13 to the last detail. Donald From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 17 December 2011 12:30 To: Donald Chapin Cc: issues@omg.org; Andrew Watson; Pete Rivett Subject: Re: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Don, Pete's issue is legitimate. I suggest generating the SBVR metamodel such that: - all associations have their memberEnds owned by classes -- i.e., no association-owned ends. - remove the class properties to which you had previously applied SBVR's sameRoleAs tag. I also noticed that some associations have nested element import relationships. What are these for? My QVTO engine currently supports MD 17.0, not 17.0.1 so please remember to send me an MD 17.0 model of SBVR with the fixes made. - Nicolas. On Dec 15, 2011, at 4:50 PM, Pete Rivett wrote: Section 13.2.5 is based on a misunderstanding and misuse of MOF: a) the phrase .In each case where an attribute and an association end represent the same role, the SBVR Metamodel includes a tag that tags both the attribute and the association end. . is in ignorance of the fact that in MOF2 and UML 2 that .attributes. and .association ends. are both represented as instances of Property: and in such a case there would be a single instance of Property linked to the Class using the attribute meta-property and from the Association by thememberEnd (or ownedEnd) property: eliminating the need to link two separate elements. b) attempting to use MOF Tags to link two properties. In fact MOF Tags are .Simple string name-value pairs.. This is an urgent issue since it affects the production of the SBVR 1.1 artifacts: there is in fact no need for the tags that have caused some of the difficulties producing the machine-readable files: even the file I sent today for the metamodel, which uses the Tag value property does not match this section of the spec which states that value is the empty string. Pete Date: Mon, 09 Jan 2012 18:24:52 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Pete Rivett CC: "sbvr-rtf@omg.org" Subject: Re: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: q09NOweb021717 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1326756301.73254@1OUpWMGcd4usCEY+nSX3FQ X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Pete, the particular trick here is that none of the association ends are owned by the classes. Per clause 13, all of the association ends (per se) are owned by the associations. The 'attribute' is a "derived" Property of the class that refers to the corresponding association end. What I understand you to say is that there is only one Property involved -- and it IS both the attribute owned by the class and the association end owned by the association. That is exactly the intent, but I can't envisage the UML model. Can a Property have two owners? Or can a class have an 'unownedAttribute'? What is the term for the association between the class and the Property that is owned by the association? The point is that it is not 'ownedAttribute'. (If the association end is actually an attribute of the class, the simpler model would have been to make the class the owner of the association end. The subtle intent, however, is to place the association end identifier in two scopes: that of the class and that of the association, because from an SBVR point-of-view those are two different terms. The one owned by the association appears only in the definition of the association, while the one owned by the class appears in text as a property of the instances of the class.) -Ed Juergen Boldt wrote: Subject: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Thu, 15 Dec 2011 16:50:43 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: Acy7jLlYRtB6JAE9TPq9DhbQaHkB0Q== From: "Pete Rivett" To: , Cc: , Section 13.2.5 is based on a misunderstanding and misuse of MOF: a) the phrase .In each case where an attribute and an association end represent the same role, the SBVR Metamodel includes a tag that tags both the attribute and the association end. . is in ignorance of the fact that in MOF2 and UML 2 that .attributes. and .association ends. are both represented as instances of Property: and in such a case there would be a single instance of Property linked to the Class using the attribute meta-property and from the Association by the /memberEnd/ (or /ownedEnd/) property: eliminating the need to link two separate elements. b) attempting to use MOF Tags to link two properties. In fact MOF Tags are .Simple string name-value pairs.. This is an urgent issue since it affects the production of the SBVR 1.1 artifacts: there is in fact no need for the tags that have caused some of the difficulties producing the machine-readable files: even the file I sent today for the metamodel, which uses the Tag /value/ property does not match this section of the spec which states that /value/ is the empty string. Pete Best regards, -Juergen Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." From: "Donald Chapin" To: "Pete Rivett" , Cc: "Andrew Watson" , Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Fri, 13 Jan 2012 12:27:36 -0000 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJKt/vhqpiJyZT42GQlejSR+2KGNpUOY7Kw X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4F10233E.008D, actions=tag X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2012.1.11.215414:17:8.317, ip=81.149.51.65, rules=__TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __FRAUD_SUBJ_A, __PHISH_SPEAR_SUBJECT, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __FRAUD_CONTACT_NUM, ECARD_KNOWN_DOMAINS, __CP_URI_IN_BODY, __C230066_P5, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_50_70, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, MULTIPLE_RCPTS, RDNS_SUSP, __FRAUD_WEBMAIL, FORGED_MUA_OUTLOOK X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4F102342.0010,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Pete, I.ve have responded to your points in-line below. I have shown below how SBVR complies with the relevant OMG specifications. I have also shown that the three places, where the mechanics of the SBVR XMI file I produced for the Santa Clara meet were not exactly correct, can and will be easily fixed next week with a revised SBVR v1.1 XMI file. There is nothing to be fixed in SBVR.s use of the UML 2.4.1 and XMI 2.4.1 specifications, so this Issue has a .No Change. disposition. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 09 January 2012 21:39 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Subject: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Thu, 15 Dec 2011 16:50:43 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: Acy7jLlYRtB6JAE9TPq9DhbQaHkB0Q== From: "Pete Rivett" To: , Cc: , Section 13.2.5 is based on a misunderstanding and misuse of MOF: a) the phrase .In each case where an attribute and an association end represent the same role, the SBVR Metamodel includes a tag that tags both the attribute and the association end. . is in ignorance of the fact that in MOF2 and UML 2 that .attributes. and .association ends. are both represented as instances of Property: and in such a case there would be a single instance of Property linked to the Class using the attribute meta-property and from the Association by the memberEnd (or ownedEnd) property: eliminating the need to link two separate elements. First, this is about who owns the Association End. MOF supports two options for ownership of the Association End: and the Association and the Class. SBVR Clause 13 used the Association ownership of the Association End to support open world semantics (see SBVR Clause 13.3.2). This Association ownership of the Association Ends use of MOF is exactly as it was in SBVR v1.0. Secondly, the problem we had in December with the .sameRole TAG. coming through as a stereotype which MOF does not support is a directly result of my being told to implement the .sameRole Tag. that way by Nicolas. I should have been told to use your MOF Profile to create MOF Tags. I will get that from Nicolas an produce both kinds of MOF Tags correctly. Third, the use of the .sameRole Tag. is necessary to interchange some SBVR linguistic semantics (attributive namespaces) that are not part of UML or MOF (see SBVR Clause 13.2.5). The bottom line on this particular point is that, once I have generated MOF Tags correctly using your MOF Profile, there is nothing wrong with the SBVR specification or the XMI file that I am generating. b) attempting to use MOF Tags to link two properties. In fact MOF Tags are .Simple string name-value pairs.. Yes, that is part of the story. It is also true that in the XMI 2.4.1 specification MOF Tags and have 0..* elements which are each specified by an XMI:id. SBVR uses two elements in MOF .sameRole Tags., each specified by an XMI:id (even though at first glance they look like qualified names). This is exactly what the SBVR v1.0 XMI file (attached) did. In this attached SBVR v1.0 XMI file you will be that each element of a MOF Tag is defined as an XMI:id. It is exactly what I tried to do for the SBVR v1.1. Since I did not at the time know of the existence of a MOF Profile and was not given it while I was in Santa Clara, I was not able to produce the MOF Tags correctly. I will do this correctly next week as well. On this particular point there is no problem of SBVR.s use of the XMI 2.4.1 specification. This is an urgent issue since it affects the production of the SBVR 1.1 artifacts: there is in fact no need for the tags that have caused some of the difficulties producing the machine-readable files: even the file I sent today for the metamodel, which uses the Tag value property does not match this section of the spec which states that value is the empty string. The problem of .value. not being am empty string has to do with the way Magic Draw exports XMI. I will find a work around and produce an XMI file with the MOF Tag values properly empty. So there is not SBVR specification Issue on this particular point. Pete Best regards, -Juergen Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org SBVR-model v1-0.xml Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Fri, 13 Jan 2012 08:53:42 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: AczSD053xYO/IQLnQ+OgZQ3TNgkh6QAA8RUw From: "Pete Rivett" To: "Andrew Watson" , "Donald Chapin" Cc: , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q0DGrtFM012515 I don't have time for a full response now, but just wanted to flag that I disagree with at least part of Don's response. Just because SBVR 1.0 'got away' with an invalid use of Tags does not make it valid: especially when it is used as the basis of urgent issue(s) on another standard - XMI. Pete -----Original Message----- From: Andrew Watson [mailto:andrew@omg.org] Sent: Friday, January 13, 2012 8:20 AM To: Donald Chapin Cc: Pete Rivett; sbvr-rtf@omg.org; nicolas.f.rouquette@jpl.nasa.gov Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Donald, Thanks for CC'ing me on your note to Pete. You wrote: > I've have responded to your points in-line below. > > I have shown below how SBVR complies with the relevant OMG > specifications. I have also shown that the three places, where the > mechanics of the SBVR XMI file I produced for the Santa Clara meet > were not exactly correct, can and will be easily fixed next week with > a revised SBVR v1.1 XMI file. > > There is nothing to be fixed in SBVR's use of the UML 2.4.1 and XMI > 2.4.1 specifications, so this Issue has a "No Change" disposition. >From my reading of your response to Pete (which I've snipped in the interests of brevity), I think you're saying that there's no need for changes between the SBVR 1.0 and SBVR 1.1 specifications in response to this issue, but there will be changes in the SBVR 1.1 XMI file in response. Is this so? If there are any changes made to the XMI file in response to this issue, the issue should be labelled "Resolved" rather than "Closed No Change". (But of course the most important thing is that the XMI file be correct, and it's great to hear that it will be ...) Needless to say, the RTF has to vote on the resolution, regardless of whether it's "Resolved" or "Closed No Change". Thanks, Andrew Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Fri, 13 Jan 2012 17:51:16 -0800 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: AQJKt/vhqpiJyZT42GQlejSR+2KGNpUOY7KwgAC+IgA= From: "Pete Rivett" To: "Donald Chapin" Cc: , , , (Before getting bogged down in the point at the start of the email I suggest readers peek ahead to **) To the technical issue, my concern is about use of the link from Element to Tag to represent a relationship between the Elements. That.s like saying in UML that 2 elements can be related by applying the same stereotype to them! As per the MOF spec, .A Tag represents a single piece of information that can be associated with any number of model elements. . In this case there is no information since the .value. property is empty on all of these. Furthermore there is nothing whatsoever in MOF semantics to support the critical aspect of .same role. . which is that any update to the class-owned property is reflected when reading the association-owned property and vice-versa. As far as MOF is concerned they are 2 entirely independent properties with no relationship to each other. To achieve what I think you wanted the properties would need to be both derived (from each other) and updateable (with update logic to update the other property). The SBVR spec says nothing about this. Just because this was present in SBVR 1.0 does not make it right. Hence this new urgent issue . which affects the formal publishing of a correct SBVR 1.1 so that the same problems are not carried forward. ** The good news is that I believe that the above, and the points in your email, are moot. I did some digging back to 2007 and came across the attached email conversation between myself and Don back in 2007. It seems that the driver for use of both attributes and association ends was the restriction in XMI that did not allow serialization of Association instances when one/both ends were owned by a Class. The big news is that the solution did not need to .wait for SMOF. since XMI 2.4 added that capability (as resolution to issue 9695). Hence it is sufficient in SBVR to have all ends owned by classes and that gives the option of serializing as attributes or associations on a case-by-case basis to represent the open/closed semantics required. So there is no need to have both attributes and association ends with the clunky and suspect use of Tags to link them (with no reconciliation of updates between them). Regards Pete PS while reading through the SBVR 1.1 spec I noticed frequent mention to .MOF 2.0. (you.re using .MOF 2.4.1. . I suggest just using .MOF 2.) and examples of XMI (e.g. in 13.6) that do not comply with the XMI 2.4.1 rules: specifically that every XML element (except those that have an href or an xmi:idref) have an xmi:type attribute. This is not part of the urgent issue but just thought I.d mention it. From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: Friday, January 13, 2012 4:28 AM To: Pete Rivett; sbvr-rtf@omg.org Cc: Andrew Watson; nicolas.f.rouquette@jpl.nasa.gov Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Pete, I.ve have responded to your points in-line below. I have shown below how SBVR complies with the relevant OMG specifications. I have also shown that the three places, where the mechanics of the SBVR XMI file I produced for the Santa Clara meet were not exactly correct, can and will be easily fixed next week with a revised SBVR v1.1 XMI file. There is nothing to be fixed in SBVR.s use of the UML 2.4.1 and XMI 2.4.1 specifications, so this Issue has a .No Change. disposition. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 09 January 2012 21:39 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Subject: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Thu, 15 Dec 2011 16:50:43 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: Acy7jLlYRtB6JAE9TPq9DhbQaHkB0Q== From: "Pete Rivett" To: , Cc: , Section 13.2.5 is based on a misunderstanding and misuse of MOF: a) the phrase .In each case where an attribute and an association end represent the same role, the SBVR Metamodel includes a tag that tags both the attribute and the association end. . is in ignorance of the fact that in MOF2 and UML 2 that .attributes. and .association ends. are both represented as instances of Property: and in such a case there would be a single instance of Property linked to the Class using the attribute meta-property and from the Association by the memberEnd (or ownedEnd) property: eliminating the need to link two separate elements. First, this is about who owns the Association End. MOF supports two options for ownership of the Association End: and the Association and the Class. SBVR Clause 13 used the Association ownership of the Association End to support open world semantics (see SBVR Clause 13.3.2). This Association ownership of the Association Ends use of MOF is exactly as it was in SBVR v1.0. Secondly, the problem we had in December with the .sameRole TAG. coming through as a stereotype which MOF does not support is a directly result of my being told to implement the .sameRole Tag. that way by Nicolas. I should have been told to use your MOF Profile to create MOF Tags. I will get that from Nicolas an produce both kinds of MOF Tags correctly. Third, the use of the .sameRole Tag. is necessary to interchange some SBVR linguistic semantics (attributive namespaces) that are not part of UML or MOF (see SBVR Clause 13.2.5). The bottom line on this particular point is that, once I have generated MOF Tags correctly using your MOF Profile, there is nothing wrong with the SBVR specification or the XMI file that I am generating. b) attempting to use MOF Tags to link two properties. In fact MOF Tags are .Simple string name-value pairs.. Yes, that is part of the story. It is also true that in the XMI 2.4.1 specification MOF Tags and have 0..* elements which are each specified by an XMI:id. SBVR uses two elements in MOF .sameRole Tags., each specified by an XMI:id (even though at first glance they look like qualified names). This is exactly what the SBVR v1.0 XMI file (attached) did. In this attached SBVR v1.0 XMI file you will be that each element of a MOF Tag is defined as an XMI:id. It is exactly what I tried to do for the SBVR v1.1. Since I did not at the time know of the existence of a MOF Profile and was not given it while I was in Santa Clara, I was not able to produce the MOF Tags correctly. I will do this correctly next week as well. On this particular point there is no problem of SBVR.s use of the XMI 2.4.1 specification. This is an urgent issue since it affects the production of the SBVR 1.1 artifacts: there is in fact no need for the tags that have caused some of the difficulties producing the machine-readable files: even the file I sent today for the metamodel, which uses the Tag value property does not match this section of the spec which states that value is the empty string. The problem of .value. not being am empty string has to do with the way Magic Draw exports XMI. I will find a work around and produce an XMI file with the MOF Tag values properly empty. So there is not SBVR specification Issue on this particular point. Pete Best regards, -Juergen Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C7F470.E3C63240" Subject: RE: SBVR XSDs Needed Date: Tue, 11 Sep 2007 04:40:09 -0800 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SBVR XSDs Needed Thread-Index: Acfl5NuFk0nz5zRVQIibMpKV3KpPZQACAZTgAeUU7RAAaT12gABUdkPAABpY7OAAInWzcADAbHlg References: <004d01c7f078$89f33e30$0200a8c0@DonaldChapin> <674FC3679265A241ACB4BF58BA0EB3BE51A41E@DHOST001-50.DEX001.intermedia.net> From: "Pete Rivett" To: "Baisley, Donald E" Cc: Hi Don, See below. To summarize the current status of my 4 points: 1. I think you're agreeing to fix, though I have already done so in the CMOF and XSD I sent you. 2. Is the only one outstanding. Where I think the solution is to have 2 sets of files. The CMOF and XSD I sent represent one set: the other would import this metamodel and apply the aliases. 3. The CMOF and XSD I sent already does what you need - as I understand your requirement 4. I just noticed that elementImports are not NamedElements so cannot be named or aliased in any case. So my removal of aliases for elementImports is correct Pete -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: Friday, September 07, 2007 8:13 PM To: Pete Rivett Cc: Donald.Chapin@btinternet.com Subject: RE: SBVR XSDs Needed Hi Pete, 1. Since Namespace.ownedMember is derived (Figure 9.38 in formal/05-07-05), Package.ownedMember which redefines it is necessarily derived according to the definition of .isConsistentWith.. Figure 12.4 in formal/06-01-01 and Figure 10.5 in formal/05-07-05 do not show ownedType as derived . so ownedType appears to not be derived for EMOF. But ownedType is derived in Constructs, so that makes it derived in CMOF (necessitated by .isConsistentWith.). The end result is that both ownedMember and ownedType are derived in CMOF. Is this the bug you were talking about?[Pete Rivett] the bug was that the non-derived Package::ownedMember redefined the derived Namespace::ownedmember. The fix was that in UML 2.1 the former has been replaced by Package::packagedElement. So even then ownedType is still derived and not serialized. Does this mean that EMOF XMI documents cannot be read as CMOF XMI? Is EMOF not a subset for purposes of interchange?. Is it just different? That is bad news. It would be best if ownedMember and ownedType both have XMI tags making them writeable. ownedType is one of the cases where a property becomes derived at a higher level of UML. Another is that at LM Class::general is not derived but it is at L1. For such cases importers of a 'lower' level need to apply the derivatino semantic- in the former case to set packagedElement/ownedMember and in the latter to create a Generalization element. Based on your request, I will change the use of ownedType to ownedMember in the SBVR Metamodel XML. This XML change requires no change to the SBVR specification. 2. When a class has a name in a package and also an alias in the same package, then there are two ways to refer to the one class in the package. Both are perfectly valid. Both names are in the namespace for the one class. [Pete Rivett] OK I see what you're trying to achieve now, though looking at the spec that's not strictly speaking the description of alias - quoting from formal 5/7/5 (my emphasis) "Specifies the name that should be added to the namespace of the importing Package in lieu of the name of the imported PackagableElement." For writing XML, it means that either name can be used . both mean the same thing. In a MOF repository, there is just one class, so when reading XML, finding either name puts something in the same class. When writing XML from a repository, use either name, not both.[Pete Rivett] would you expect a single file to use the same anme consistently for a single class? We use aliases for synonyms in order to keep the SBVR XMI in sync with the SBVR vocabulary. We discussed this at the end of last year. If your MOF tooling cannot handle generating an XSD for a metamodel that has element imports, then I can generate the XSD when I generate the metamodel XML.[Pete Rivett] it would make the XSD even less useful for validation - since one could not readily specify that only one of the 2 names should be used. Our tooling cannot generate such an XSD. If you can then do you need me to do anythign else? You are correct that the XMI 2.1 Specification does not talk about element imports or their aliases. It also does not talk about ownedMember, ownedType or a lot of specific things. But one would assume that XMI works for element imports as it does for owned elements.[Pete Rivett] The point is that it does not address the possibility of using 2 different XML element names for the same metamodel element. And even the MOF/Infra spec states that the alias is for use instead of the original name (see above) An attempt to change how this works now would be problematic at this late point in time.[Pete Rivett] Maybe there could be 2 separate XSD/XMI files for the different purposes based on what you hinted at with respect to imports into a 'dummy' package. 3. The rationale for using attributes in addition to associations is explained in greater detail in 13.3.2. The brief explanation you mentioned points to 13.3.2. SBVR.s metamodel needs this workaround until SMOF comes along and provides another means by which an XMI document can distinguish the open and closed cases. I discussed this workaround with you before proposing it as a way to have a more typical MOF metamodel for SBVR. Without this workaround, SBVR would need to stay with the previous RDF-like use of MOF, which some OMG folks did not like. Note that SBVR.s metamodel is aimed at supporting XMI interchange. If a repository has other means of handling open/closed, then the repository model can be transformed to take advantage of those means. But SBVR.s metamodel must support an XMI interchange capability that handles the distinction. [Pete Rivett] The correction I proposed, with the attribute linked to the association, and XSD I generated, does allow XMI interchange expression of relationships either as attributes or Association instances (links)! It presumes that we relax the current formal XMI restriction (in the spec but not our implementation) that Association instances may only be interchanged if the Association owns both of its ends - but that is a minor change/hassle compared to havign the attributes and ends completely unrelated As you explained to me months ago, if a MOF class owns an attribute that is the end of some association, then the XMI documents don.t get to use individual links of that association. So we use our workaround until SMOF gives us a better way. Best regards, Don -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, September 06, 2007 5:32 PM To: Donald.Chapin@btinternet.com Cc: Baisley, Donald E Subject: RE: SBVR XSDs Needed I've been with a customer in Germany the last 3 days with little email access (or time to read them!). I will be on a con call for about 7 hours tomorrow starting 9am EDT so will not be available. Responses in maroon. I did not make the changes I did lightly (and they did take a fair amount of time and energy). Without them I could not have used our technology to generate the schema (with the possible exception of issue 3). Pete -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: Thursday, September 06, 2007 12:25 PM To: Pete Rivett Cc: 'Baisley, Donald E' Subject: FW: SBVR XSDs Needed Importance: High Hi Pete, Do I need to arrange a telecon for you, Don and me; or can you answer Don.s questions without needing to talk with him? I.m concerned that Don may need to produce a revised XMI file that doesn.t need to be tweaked so that the XMI and XSD files are in synch and agree with SBVR Clause 13 . and time is passing. Thanks, Donald -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: 04 September 2007 20:58 To: Pete Rivett Cc: Donald.Chapin@btinternet.com Subject: RE: SBVR XSDs Needed Hi Pete, Please see comments in blue below. Don -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Sunday, September 02, 2007 5:27 PM To: Baisley, Donald E Cc: Donald.Chapin@btinternet.com Subject: RE: SBVR XSDs Needed Importance: High I've just looked at SBVR.xml as per Don's voicemail. It has the following problems: 1) ownedType is incorrectly used instead of ownedMember (ownedType is derived and hence not serialized). This was a simple edit to fix via global edit. Where in Infrastructure 2.0 or MOF 2.0 is it documented that ownedType is derived? I am looking at formal/05-07-05 and formal/06-01-01. MOF 2.0 says .Namespace::ownedMember (Note that this is abstract, so appropriate specializations must be used.).. [Pete Rivett] Figure 11.26 of formal/5-7-5. Now namespace::ownedMember is derived (hence the quote in the MOF 2.0 spec) but Package::ownedMember is not. This was a bug and package::packagedMember was introduced instead (though at UML 2.1 which does not apply to MOF 2.0). However if you look at the later UML specs you can see that ownedType has always been shown as derived. And if you look at the UML metamodel itself, it uses ownedMember. 2) elementImport is used for elements in the same package (it is only valid for elements in a differetn package). SBVR uses elementImport for aliasing (based on synonyms in the SBVR vocabulary) . one model element can have two names. The only clue I can find in the Infrastructure 2.0 or MOF 2.0 specifications about importing being from a .different. package is that the introduction to ElementImport uses the word .another. in a general statement that makes no claim to being a limitation. There is no constraint that prevents importing from the same package. I discussed this with you at the end of last year when deciding to take SBVR.s new approach to using MOF. [Pete Rivett] What I'm having a problem with is the formal meaning of such an alias. It's clearer when from a different package - the alias overrides the other name. Though the application of this is generally only for 'programming language' or maybe OCL expressions. The XMI spec says nothing about such aliases. It gets worse if the alias is in the same package: what would you expect to happen? To completely replace the original name (I think not since you want 2 names)? For example in XMI which is the current topic, when exporting would you expect the same instance to be exported twice as two XML elements with different XML element names? It was really the lack of reference to aliases in XMI and lack of ability to answer these questions that led me to delete them. If importing from that same Package is not going to be supported, then I suppose I will have to import twice to get the desired result. I can do a package import of everything into a dummy package and then do element imports from there. [Pete Rivett] Hmm still not sure what effect you're trying to achieve. It's not clear what effect you're tryign to achieve with elementImports - to take an example we have: which is followed by: which I assume is intended to renam it to behavioral business rule. However later on we have the following which, as far as the XSD and XMI interchange is concerned, puts the first word back from 'behavioral' to 'operative'. So I ignored the elementImports. [Pete Rivett] You did not respond what you were trying to achieve. 3) There are many cases where an association end is owned by a class, but the end is not properly tied up with the association. I see there is a tag, org.omg.sbvr.sameRole, very briefly mentioned (but not justified) in section 13.2.5 of the SBVR spec. MOF has no functionality for recognizing this tag; and already has functionality for linking 'attributes' to association roles so don't see why it's needed. Attributes are used for complete extensions and links are used with an open world assumption. [Pete Rivett] OK I remember the issue now - would be useful to explain this in 13.2.5 of SBVR. However I don't necessarily agree with the resolution in terms of a MOF implementation. I guess I missed this when balloted - what Issue number was it? MOF does not need to handle this at this time. SMOF will hopefully support open/closed without the need for the work-around. The XSD generation can ignore these .sameRole. tags. The XSD must keep them separate, as in the metamodel. For example: Should be tied up in MOF with the Association element: However the association does not reference the end owned by the class, nor vice versa. What I think you should have is the following, changes in olive: I wrote XSL to fix up this based on the sbvr tags. Without that, no MOF repository is going to be able to maintain the attribute and the association in synch. No MOF repository should be expected to keep these in synch until SMOF comes along with a solution. [Pete Rivett] Not keeping them in synch seems crazy and wrong - and not what a repository should be about. For now, software that uses a MOF repository for SBVR can use the tags to know what is going on.[Pete Rivett] Which is what I did by doing the substitution/deletion. No MOF repository can be expected to know about the tags. 4) There is an xmiName tag applied to a few elementImports which is pointless since the names of the imports themselves are never made use of. For example: Since I was filtering out the elementImports I wrote some more XSL to remove these. These need to stay, along with the element imports. [Pete Rivett] What use would you expect the name for an import element (as opposed to the alias it introduces) to have. As naming it seems pointless (except possible for management purposes) then renaming it seems more so. Attached is the fixed CMOF metamodel and the XSD. Also the XSL file I used to make the fixes. I lost track of the URI you agreed to use so you may want to adjust that in the header. This UR (and the ns prefix) should also be recorded in the metamodel as XMI Tags. Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Hello House, 135 Somerford Road, Christchurch, BH23 3PY, UK Tel: +44 (0)1202 491243 Fax: +44 (0)1202 491241 http://www.adaptive.com -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: Friday, August 24, 2007 2:25 AM To: Pete Rivett Cc: Donald.Chapin@btinternet.com Subject: SBVR XSDs Needed Hi Pete, Can you please create XSDs for each of the attached files (which I just sent to the SBVR-FTF mailing list)? Each file gives a package that is already .merged.. Please send the files to the SBVR-FTF mailing list. Also, please let me know if you find errors in the files. Gene Mutschler was able to load them with his CMOF tool. Thanks, Don X-Originating-IP: [76.93.4.87] From: Don Baisley To: Pete Rivett , Donald Chapin CC: , , Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Mon, 16 Jan 2012 11:25:27 -0800 X-OriginalArrivalTime: 16 Jan 2012 19:25:28.0365 (UTC) FILETIME=[9ABB75D0:01CCD484] Hi Pete, We would all like MOF and XMI to more directly support SBVR's metamodel. Particularly, we would all like each binary verb concept to show up as a single association in MOF. 1. Serialization of individual links has open world semantics (implying that the extension might be incompletely represented in the document). 2. Serialization of a property's values with respect to an object has closed world semantics for that property of that object (the extension is completely represented). It is good that XMI 2.4 allows serialization of association links regardless of whether ends are owned by classes. However, that is not enough to allow ownership of SBVR's assocation ends to transfer to SBVR's classes. The ownership of SBVR's association ends correctly matches the namespace requirements. Transferring the ownership of all ends to classes will cause name conflicts. Regarding your point about use of tags, I find that the meaning of a tag is up to whoever defines it. Tags are for extensibility. SBVR uses the "org.omg.sbvr.sameRole" tag to represent a certain piece of inforation about a group of elements -- that they are mutually related -- they represent the same role. That is a perfectly legitimate us of a tag. It would be nice for MOF and XMI to make that tag unnecessary. Example (from SBVR 13.2.5): Verb concept: thing is in set There is a binary association called "thing is in set" with two ends, "thing" and "set". Also, in the "set" class, there is an "element" property, which is effectively a redefinition of the "thing" end of the "thing is in set" association. We use the "org.omg.sbvr.sameRole" tag to relate set.element to the "thing" end of the association "thing is in set". We could remove that tag if we could use MOF's "redefinedProperty" to show the relationship. "set.element" redefines the "thing" end of the association called "thing is in set". But UML infrastructure constraints prevent that sort of redefinition. The other change that has been suggested, moving ownership of association ends to classes, will require major rework and will not be completed anytime soon. It will required inventing and documenting new generation patterns for the MOF and the XML. It requires redoing some complicated diagrams and reworking many examples. It is a large change that will require a lot of rework and testing. Since some problems need fixing in MOF/XMI anyway, it would be best for MOF to support a class-owned property being able to redefine an association end that is owned by an association. Or MOF could provide some other means in a metamodel to indicate that an association end owned by an association is visible as a property in a class. This is a normal thing in information modeling (not program modeling). That way, the name scoping remains correct and what people see in model diagrams will match what is in MOF and XMI. In the meantime, the "org.omg.sbvr.sameRole" tag does the job. Perhaps MOF/XMI will provide a means for removing the tags in SBVR 1.2. Best regards, Don -------------------------------------------------------------------------------- Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Fri, 13 Jan 2012 17:51:16 -0800 From: pete.rivett@adaptive.com To: Donald.Chapin@BusinessSemantics.com CC: donbaisley@live.com; nicolas.f.rouquette@jpl.nasa.gov; andrew@omg.org; sbvr-rtf@omg.org (Before getting bogged down in the point at the start of the email I suggest readers peek ahead to **) To the technical issue, my concern is about use of the link from Element to Tag to represent a relationship between the Elements. That.s like saying in UML that 2 elements can be related by applying the same stereotype to them! As per the MOF spec, .A Tag represents a single piece of information that can be associated with any number of model elements. . In this case there is no information since the .value. property is empty on all of these. Furthermore there is nothing whatsoever in MOF semantics to support the critical aspect of .same role. . which is that any update to the class-owned property is reflected when reading the association-owned property and vice-versa. As far as MOF is concerned they are 2 entirely independent properties with no relationship to each other. To achieve what I think you wanted the properties would need to be both derived (from each other) and updateable (with update logic to update the other property). The SBVR spec says nothing about this. Just because this was present in SBVR 1.0 does not make it right. Hence this new urgent issue . which affects the formal publishing of a correct SBVR 1.1 so that the same problems are not carried forward. ** The good news is that I believe that the above, and the points in your email, are moot. I did some digging back to 2007 and came across the attached email conversation between myself and Don back in 2007. It seems that the driver for use of both attributes and association ends was the restriction in XMI that did not allow serialization of Association instances when one/both ends were owned by a Class. The big news is that the solution did not need to .wait for SMOF. since XMI 2.4 added that capability (as resolution to issue 9695). Hence it is sufficient in SBVR to have all ends owned by classes and that gives the option of serializing as attributes or associations on a case-by-case basis to represent the open/closed semantics required. So there is no need to have both attributes and association ends with the clunky and suspect use of Tags to link them (with no reconciliation of updates between them). Regards Pete PS while reading through the SBVR 1.1 spec I noticed frequent mention to .MOF 2.0. (you.re using .MOF 2.4.1. . I suggest just using .MOF 2.) and examples of XMI (e.g. in 13.6) that do not comply with the XMI 2.4.1 rules: specifically that every XML element (except those that have an href or an xmi:idref) have an xmi:type attribute. This is not part of the urgent issue but just thought I.d mention it. From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: Friday, January 13, 2012 4:28 AM To: Pete Rivett; sbvr-rtf@omg.org Cc: Andrew Watson; nicolas.f.rouquette@jpl.nasa.gov Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Pete, I.ve have responded to your points in-line below. I have shown below how SBVR complies with the relevant OMG specifications. I have also shown that the three places, where the mechanics of the SBVR XMI file I produced for the Santa Clara meet were not exactly correct, can and will be easily fixed next week with a revised SBVR v1.1 XMI file. There is nothing to be fixed in SBVR.s use of the UML 2.4.1 and XMI 2.4.1 specifications, so this Issue has a .No Change. disposition. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 09 January 2012 21:39 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Subject: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Thu, 15 Dec 2011 16:50:43 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: Acy7jLlYRtB6JAE9TPq9DhbQaHkB0Q== From: "Pete Rivett" To: , Cc: , Section 13.2.5 is based on a misunderstanding and misuse of MOF: a) the phrase .In each case where an attribute and an association end represent the same role, the SBVR Metamodel includes a tag that tags both the attribute and the association end. . is in ignorance of the fact that in MOF2 and UML 2 that .attributes. and .association ends. are both represented as instances of Property: and in such a case there would be a single instance of Property linked to the Class using the attribute meta-property and from the Association by the memberEnd (or ownedEnd) property: eliminating the need to link two separate elements. First, this is about who owns the Association End. MOF supports two options for ownership of the Association End: and the Association and the Class. SBVR Clause 13 used the Association ownership of the Association End to support open world semantics (see SBVR Clause 13.3.2). This Association ownership of the Association Ends use of MOF is exactly as it was in SBVR v1.0. Secondly, the problem we had in December with the .sameRole TAG. coming through as a stereotype which MOF does not support is a directly result of my being told to implement the .sameRole Tag. that way by Nicolas. I should have been told to use your MOF Profile to create MOF Tags. I will get that from Nicolas an produce both kinds of MOF Tags correctly. Third, the use of the .sameRole Tag. is necessary to interchange some SBVR linguistic semantics (attributive namespaces) that are not part of UML or MOF (see SBVR Clause 13.2.5). The bottom line on this particular point is that, once I have generated MOF Tags correctly using your MOF Profile, there is nothing wrong with the SBVR specification or the XMI file that I am generating. b) attempting to use MOF Tags to link two properties. In fact MOF Tags are .Simple string name-value pairs.. Yes, that is part of the story. It is also true that in the XMI 2.4.1 specification MOF Tags and have 0..* elements which are each specified by an XMI:id. SBVR uses two elements in MOF .sameRole Tags., each specified by an XMI:id (even though at first glance they look like qualified names). This is exactly what the SBVR v1.0 XMI file (attached) did. In this attached SBVR v1.0 XMI file you will be that each element of a MOF Tag is defined as an XMI:id. It is exactly what I tried to do for the SBVR v1.1. Since I did not at the time know of the existence of a MOF Profile and was not given it while I was in Santa Clara, I was not able to produce the MOF Tags correctly. I will do this correctly next week as well. On this particular point there is no problem of SBVR.s use of the XMI 2.4.1 specification. This is an urgent issue since it affects the production of the SBVR 1.1 artifacts: there is in fact no need for the tags that have caused some of the difficulties producing the machine-readable files: even the file I sent today for the metamodel, which uses the Tag value property does not match this section of the spec which states that value is the empty string. The problem of .value. not being am empty string has to do with the way Magic Draw exports XMI. I will find a work around and produce an XMI file with the MOF Tag values properly empty. So there is not SBVR specification Issue on this particular point. Pete Best regards, -Juergen Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org --Forwarded Message Attachment-- Subject: RE: SBVR XSDs Needed Date: Tue, 11 Sep 2007 04:40:09 -0800 From: pete.rivett@adaptive.com To: Donald.Baisley@unisys.com CC: Donald.Chapin@btinternet.com Hi Don, See below. To summarize the current status of my 4 points: 1. I think you're agreeing to fix, though I have already done so in the CMOF and XSD I sent you. 2. Is the only one outstanding. Where I think the solution is to have 2 sets of files. The CMOF and XSD I sent represent one set: the other would import this metamodel and apply the aliases. 3. The CMOF and XSD I sent already does what you need - as I understand your requirement 4. I just noticed that elementImports are not NamedElements so cannot be named or aliased in any case. So my removal of aliases for elementImports is correct Pete -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: Friday, September 07, 2007 8:13 PM To: Pete Rivett Cc: Donald.Chapin@btinternet.com Subject: RE: SBVR XSDs Needed Hi Pete, 1. Since Namespace.ownedMember is derived (Figure 9.38 in formal/05-07-05), Package.ownedMember which redefines it is necessarily derived according to the definition of .isConsistentWith.. Figure 12.4 in formal/06-01-01 and Figure 10.5 in formal/05-07-05 do not show ownedType as derived . so ownedType appears to not be derived for EMOF. But ownedType is derived in Constructs, so that makes it derived in CMOF (necessitated by .isConsistentWith.). The end result is that both ownedMember and ownedType are derived in CMOF. Is this the bug you were talking about?[Pete Rivett] the bug was that the non-derived Package::ownedMember redefined the derived Namespace::ownedmember. The fix was that in UML 2.1 the former has been replaced by Package::packagedElement. So even then ownedType is still derived and not serialized. Does this mean that EMOF XMI documents cannot be read as CMOF XMI? Is EMOF not a subset for purposes of interchange?. Is it just different? That is bad news. It would be best if ownedMember and ownedType both have XMI tags making them writeable. ownedType is one of the cases where a property becomes derived at a higher level of UML. Another is that at LM Class::general is not derived but it is at L1. For such cases importers of a 'lower' level need to apply the derivatino semantic- in the former case to set packagedElement/ownedMember and in the latter to create a Generalization element. Based on your request, I will change the use of ownedType to ownedMember in the SBVR Metamodel XML. This XML change requires no change to the SBVR specification. 2. When a class has a name in a package and also an alias in the same package, then there are two ways to refer to the one class in the package. Both are perfectly valid. Both names are in the namespace for the one class. [Pete Rivett] OK I see what you're trying to achieve now, though looking at the spec that's not strictly speaking the description of alias - quoting from formal 5/7/5 (my emphasis) "Specifies the name that should be added to the namespace of the importing Package in lieu of the name of the imported PackagableElement." For writing XML, it means that either name can be used . both mean the same thing. In a MOF repository, there is just one class, so when reading XML, finding either name puts something in the same class. When writing XML from a repository, use either name, not both.[Pete Rivett] would you expect a single file to use the same anme consistently for a single class? We use aliases for synonyms in order to keep the SBVR XMI in sync with the SBVR vocabulary. We discussed this at the end of last year. If your MOF tooling cannot handle generating an XSD for a metamodel that has element imports, then I can generate the XSD when I generate the metamodel XML.[Pete Rivett] it would make the XSD even less useful for validation - since one could not readily specify that only one of the 2 names should be used. Our tooling cannot generate such an XSD. If you can then do you need me to do anythign else? You are correct that the XMI 2.1 Specification does not talk about element imports or their aliases. It also does not talk about ownedMember, ownedType or a lot of specific things. But one would assume that XMI works for element imports as it does for owned elements.[Pete Rivett] The point is that it does not address the possibility of using 2 different XML element names for the same metamodel element. And even the MOF/Infra spec states that the alias is for use instead of the original name (see above) An attempt to change how this works now would be problematic at this late point in time.[Pete Rivett] Maybe there could be 2 separate XSD/XMI files for the different purposes based on what you hinted at with respect to imports into a 'dummy' package. 3. The rationale for using attributes in addition to associations is explained in greater detail in 13.3.2. The brief explanation you mentioned points to 13.3.2. SBVR.s metamodel needs this workaround until SMOF comes along and provides another means by which an XMI document can distinguish the open and closed cases. I discussed this workaround with you before proposing it as a way to have a more typical MOF metamodel for SBVR. Without this workaround, SBVR would need to stay with the previous RDF-like use of MOF, which some OMG folks did not like. Note that SBVR.s metamodel is aimed at supporting XMI interchange. If a repository has other means of handling open/closed, then the repository model can be transformed to take advantage of those means. But SBVR.s metamodel must support an XMI interchange capability that handles the distinction. [Pete Rivett] The correction I proposed, with the attribute linked to the association, and XSD I generated, does allow XMI interchange expression of relationships either as attributes or Association instances (links)! It presumes that we relax the current formal XMI restriction (in the spec but not our implementation) that Association instances may only be interchanged if the Association owns both of its ends - but that is a minor change/hassle compared to havign the attributes and ends completely unrelated As you explained to me months ago, if a MOF class owns an attribute that is the end of some association, then the XMI documents don.t get to use individual links of that association. So we use our workaround until SMOF gives us a better way. Best regards, Don -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, September 06, 2007 5:32 PM To: Donald.Chapin@btinternet.com Cc: Baisley, Donald E Subject: RE: SBVR XSDs Needed I've been with a customer in Germany the last 3 days with little email access (or time to read them!). I will be on a con call for about 7 hours tomorrow starting 9am EDT so will not be available. Responses in maroon. I did not make the changes I did lightly (and they did take a fair amount of time and energy). Without them I could not have used our technology to generate the schema (with the possible exception of issue 3). Pete -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: Thursday, September 06, 2007 12:25 PM To: Pete Rivett Cc: 'Baisley, Donald E' Subject: FW: SBVR XSDs Needed Importance: High Hi Pete, Do I need to arrange a telecon for you, Don and me; or can you answer Don.s questions without needing to talk with him? I.m concerned that Don may need to produce a revised XMI file that doesn.t need to be tweaked so that the XMI and XSD files are in synch and agree with SBVR Clause 13 . and time is passing. Thanks, Donald -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: 04 September 2007 20:58 To: Pete Rivett Cc: Donald.Chapin@btinternet.com Subject: RE: SBVR XSDs Needed Hi Pete, Please see comments in blue below. Don -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Sunday, September 02, 2007 5:27 PM To: Baisley, Donald E Cc: Donald.Chapin@btinternet.com Subject: RE: SBVR XSDs Needed Importance: High I've just looked at SBVR.xml as per Don's voicemail. It has the following problems: 1) ownedType is incorrectly used instead of ownedMember (ownedType is derived and hence not serialized). This was a simple edit to fix via global edit. Where in Infrastructure 2.0 or MOF 2.0 is it documented that ownedType is derived? I am looking at formal/05-07-05 and formal/06-01-01. MOF 2.0 says .Namespace::ownedMember (Note that this is abstract, so appropriate specializations must be used.).. [Pete Rivett] Figure 11.26 of formal/5-7-5. Now namespace::ownedMember is derived (hence the quote in the MOF 2.0 spec) but Package::ownedMember is not. This was a bug and package::packagedMember was introduced instead (though at UML 2.1 which does not apply to MOF 2.0). However if you look at the later UML specs you can see that ownedType has always been shown as derived. And if you look at the UML metamodel itself, it uses ownedMember. 2) elementImport is used for elements in the same package (it is only valid for elements in a differetn package). SBVR uses elementImport for aliasing (based on synonyms in the SBVR vocabulary) . one model element can have two names. The only clue I can find in the Infrastructure 2.0 or MOF 2.0 specifications about importing being from a .different. package is that the introduction to ElementImport uses the word .another. in a general statement that makes no claim to being a limitation. There is no constraint that prevents importing from the same package. I discussed this with you at the end of last year when deciding to take SBVR.s new approach to using MOF. [Pete Rivett] What I'm having a problem with is the formal meaning of such an alias. It's clearer when from a different package - the alias overrides the other name. Though the application of this is generally only for 'programming language' or maybe OCL expressions. The XMI spec says nothing about such aliases. It gets worse if the alias is in the same package: what would you expect to happen? To completely replace the original name (I think not since you want 2 names)? For example in XMI which is the current topic, when exporting would you expect the same instance to be exported twice as two XML elements with different XML element names? It was really the lack of reference to aliases in XMI and lack of ability to answer these questions that led me to delete them. If importing from that same Package is not going to be supported, then I suppose I will have to import twice to get the desired result. I can do a package import of everything into a dummy package and then do element imports from there. [Pete Rivett] Hmm still not sure what effect you're trying to achieve. It's not clear what effect you're tryign to achieve with elementImports - to take an example we have: which is followed by: which I assume is intended to renam it to behavioral business rule. However later on we have the following which, as far as the XSD and XMI interchange is concerned, puts the first word back from 'behavioral' to 'operative'. So I ignored the elementImports. [Pete Rivett] You did not respond what you were trying to achieve. 3) There are many cases where an association end is owned by a class, but the end is not properly tied up with the association. I see there is a tag, org.omg.sbvr.sameRole, very briefly mentioned (but not justified) in section 13.2.5 of the SBVR spec. MOF has no functionality for recognizing this tag; and already has functionality for linking 'attributes' to association roles so don't see why it's needed. Attributes are used for complete extensions and links are used with an open world assumption. [Pete Rivett] OK I remember the issue now - would be useful to explain this in 13.2.5 of SBVR. However I don't necessarily agree with the resolution in terms of a MOF implementation. I guess I missed this when balloted - what Issue number was it? MOF does not need to handle this at this time. SMOF will hopefully support open/closed without the need for the work-around. The XSD generation can ignore these .sameRole. tags. The XSD must keep them separate, as in the metamodel. For example: Should be tied up in MOF with the Association element: However the association does not reference the end owned by the class, nor vice versa. What I think you should have is the following, changes in olive: I wrote XSL to fix up this based on the sbvr tags. Without that, no MOF repository is going to be able to maintain the attribute and the association in synch. No MOF repository should be expected to keep these in synch until SMOF comes along with a solution. [Pete Rivett] Not keeping them in synch seems crazy and wrong - and not what a repository should be about. For now, software that uses a MOF repository for SBVR can use the tags to know what is going on.[Pete Rivett] Which is what I did by doing the substitution/deletion. No MOF repository can be expected to know about the tags. 4) There is an xmiName tag applied to a few elementImports which is pointless since the names of the imports themselves are never made use of. For example: Since I was filtering out the elementImports I wrote some more XSL to remove these. These need to stay, along with the element imports. [Pete Rivett] What use would you expect the name for an import element (as opposed to the alias it introduces) to have. As naming it seems pointless (except possible for management purposes) then renaming it seems more so. Attached is the fixed CMOF metamodel and the XSD. Also the XSL file I used to make the fixes. I lost track of the URI you agreed to use so you may want to adjust that in the header. This UR (and the ns prefix) should also be recorded in the metamodel as XMI Tags. Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Hello House, 135 Somerford Road, Christchurch, BH23 3PY, UK Tel: +44 (0)1202 491243 Fax: +44 (0)1202 491241 http://www.adaptive.com -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: Friday, August 24, 2007 2:25 AM To: Pete Rivett Cc: Donald.Chapin@btinternet.com Subject: SBVR XSDs Needed Hi Pete, Can you please create XSDs for each of the attached files (which I just sent to the SBVR-FTF mailing list)? Each file gives a package that is already .merged.. Please send the files to the SBVR-FTF mailing list. Also, please let me know if you find errors in the files. Gene Mutschler was able to load them with his CMOF tool. Thanks, Don From: "Donald Chapin" To: "'Pete Rivett'" , "'Andrew Watson'" Cc: , Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Tue, 17 Jan 2012 13:49:31 -0000 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJKt/vhqpiJyZT42GQlejSR+2KGNgF2++2cAXwm5ngCfhwNN5TpQunA X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4F157C6E.00AE, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.17.125118:17:7.944, ip=81.149.51.65, rules=__TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __FRAUD_SUBJ_A, __PHISH_SPEAR_SUBJECT, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, MULTIPLE_RCPTS, RDNS_SUSP, FORGED_MUA_OUTLOOK, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4F157C72.0051,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Hi Pete, Nicolas Rouquette's Urgent Issue regarding ambiguities, omissions and contradictions in the XMI 2.4.1 XML Schema Production stands independent of SBVR. This Urgent Issue is about any and all XMI-based XML Schemas and the brokenness of the OMG-wide ability to interchange model content using XML with XMI XSDs as their XML Schema. The US government logged two Issues on this same topic around the end of November. I'm sure that Dr. Kshemendra Paul, who gave the Keynote in Santa Clara, would not be happy to learn that his people cannot do what they need to do because an OMG model content interchange specification is broken. Donald -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 13 January 2012 16:54 To: Andrew Watson; Donald Chapin Cc: sbvr-rtf@omg.org; nicolas.f.rouquette@jpl.nasa.gov Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) I don't have time for a full response now, but just wanted to flag that I disagree with at least part of Don's response. Just because SBVR 1.0 'got away' with an invalid use of Tags does not make it valid: especially when it is used as the basis of urgent issue(s) on another standard - XMI. Pete -----Original Message----- From: Andrew Watson [mailto:andrew@omg.org] Sent: Friday, January 13, 2012 8:20 AM To: Donald Chapin Cc: Pete Rivett; sbvr-rtf@omg.org; nicolas.f.rouquette@jpl.nasa.gov Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Donald, Thanks for CC'ing me on your note to Pete. You wrote: > I've have responded to your points in-line below. > > I have shown below how SBVR complies with the relevant OMG > specifications. I have also shown that the three places, where the > mechanics of the SBVR XMI file I produced for the Santa Clara meet > were not exactly correct, can and will be easily fixed next week with > a revised SBVR v1.1 XMI file. > > There is nothing to be fixed in SBVR's use of the UML 2.4.1 and XMI > 2.4.1 specifications, so this Issue has a "No Change" disposition. >From my reading of your response to Pete (which I've snipped in the interests of brevity), I think you're saying that there's no need for changes between the SBVR 1.0 and SBVR 1.1 specifications in response to this issue, but there will be changes in the SBVR 1.1 XMI file in response. Is this so? If there are any changes made to the XMI file in response to this issue, the issue should be labelled "Resolved" rather than "Closed No Change". (But of course the most important thing is that the XMI file be correct, and it's great to hear that it will be ...) Needless to say, the RTF has to vote on the resolution, regardless of whether it's "Resolved" or "Closed No Change". Thanks, Andrew From: "Donald Chapin" To: "'Pete Rivett'" Cc: , , , "'Don Baisley'" Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Tue, 17 Jan 2012 15:48:28 -0000 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJKt/vhqpiJyZT42GQlejSR+2KGNgF2++2cAN/1QHsBlUxGXJT1jAkA X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4F15984F.0035, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.17.145714:17:7.944, ip=81.149.51.65, rules=__TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __FRAUD_SUBJ_A, __PHISH_SPEAR_SUBJECT, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, BODY_SIZE_10000_PLUS, __MIME_HTML, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, MULTIPLE_RCPTS, RDNS_SUSP, __FRAUD_WEBMAIL, FORGED_MUA_OUTLOOK X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020D.4F159854.00CB,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Pete, SBVR.s use of MOF/XMI in SBVR Clause 13 is as a syntax for interchanging SBVR semantics, not MOF or UML semantics (see SBVR Subclause 13.2): The SBVR Vocabulary is mapped to MOF elements that make up the SBVR Metamodel. It should not be construed from this one-way mapping that a MOF class is the same thing as an SBVR concept or that there is any semantic equivalence between MOF and SBVR. SBVR model content is represented in MOF-based SBVR models according to the SBVR Metamodel. MOF-based SBVR models instantiate the SBVR Metamodel, not the UML Metamodel. Another transform would be needed to represent SBVR model content using UML. Both the mapping of the SBVR Vocabulary to MOF and the representation of SBVR model content using MOF are described below, divided using the following headings . When you see an XMI .class. in an SBVR interchange file, based on Clause 13 it has to be read as either an SBVR noun concept or SBVR verb concept one or three or more roles . it does not carry UML/MOF class semantics. This is true for everything in an SBVR interchange file. The use of the .sameRole MOF Tag. communicates that the SBVR designation represented as an MOF/XMI attribute of a given class is in the SBVR attributive namespace of the SBVR subject concept represented by the MOF/XMI class. All the .sameRole MOF Tag. says is that this SBVR designation is one designation of the SBVR verb concept role represented as the association end referenced in the .sameRole MOF Tag. (see SBVR Subclauses 8.3.5 and 13.2.5). This capability is an important part of the SBVR semantics. Don has answered the technical questions about SBVR.s use of MOF and XMI much better than I could as he was part of it original development when he worked at Unisys. You raised a point about the SBVR v1.1 specification referencing MOF 2.0. This wording fix was an oversight as we decided to use MOF/XMI 2.4.1 to support the resolution of Issue 10577 because XMI 2.4.1 XML Schema production rules support omitting abstract classes from the XML Schema. We will change the reference from MOF 2.0 to MOF 2.4.1. Marking some classes as abstract is fundamental to the resolution of Issue 10577 (attached; raised in 2007 and accepted in SBVR v1.1 Ballot 6) which clarified the distinction between: · those SBVR concepts defined just to support unambiguous human discourse on the subject of SBVR business vocabularies and business rules but have no SBVR content in an SBVR interchange file (these are marked as abstract), and · those SBVR concepts for which SBVR business vocabulary, and optionally business rules, content will be interchanged in SBVR interchange files which are files that use the SBVR XSD. Therefore the use of MOF/XMI 2.4.1 is absolutely essential to SBVR v1.1. It would be ideal if MOF fully supported SBVR semantics, but currently it does not. SBVR.s use of MOF tag fits what the MOF/XMI 2.4.1 specification says - as I explained in an earlier email and Don reinforced. The question is whether or not SBVR complies with the wording of the XMI 2.4.1 specification as it stands - not whether SBVR complies with an interpretation of the XMI 2.4.1 specification that adds more than the specification says or with an implementation of the XMI 2.4.1 specification in somebody's tool. Donald From: Don Baisley [mailto:donbaisley@live.com] Sent: 16 January 2012 19:25 To: Pete Rivett; Donald Chapin Cc: nicolas.f.rouquette@jpl.nasa.gov; andrew@omg.org; sbvr-rtf@omg.org Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Hi Pete, We would all like MOF and XMI to more directly support SBVR's metamodel. Particularly, we would all like each binary verb concept to show up as a single association in MOF. 1. Serialization of individual links has open world semantics (implying that the extension might be incompletely represented in the document). 2. Serialization of a property's values with respect to an object has closed world semantics for that property of that object (the extension is completely represented). It is good that XMI 2.4 allows serialization of association links regardless of whether ends are owned by classes. However, that is not enough to allow ownership of SBVR's assocation ends to transfer to SBVR's classes. The ownership of SBVR's association ends correctly matches the namespace requirements. Transferring the ownership of all ends to classes will cause name conflicts. Regarding your point about use of tags, I find that the meaning of a tag is up to whoever defines it. Tags are for extensibility. SBVR uses the "org.omg.sbvr.sameRole" tag to represent a certain piece of inforation about a group of elements -- that they are mutually related -- they represent the same role. That is a perfectly legitimate us of a tag. It would be nice for MOF and XMI to make that tag unnecessary. Example (from SBVR 13.2.5): Verb concept: thing is in set There is a binary association called "thing is in set" with two ends, "thing" and "set". Also, in the "set" class, there is an "element" property, which is effectively a redefinition of the "thing" end of the "thing is in set" association. We use the "org.omg.sbvr.sameRole" tag to relate set.element to the "thing" end of the association "thing is in set". We could remove that tag if we could use MOF's "redefinedProperty" to show the relationship. "set.element" redefines the "thing" end of the association called "thing is in set". But UML infrastructure constraints prevent that sort of redefinition. The other change that has been suggested, moving ownership of association ends to classes, will require major rework and will not be completed anytime soon. It will required inventing and documenting new generation patterns for the MOF and the XML. It requires redoing some complicated diagrams and reworking many examples. It is a large change that will require a lot of rework and testing. Since some problems need fixing in MOF/XMI anyway, it would be best for MOF to support a class-owned property being able to redefine an association end that is owned by an association. Or MOF could provide some other means in a metamodel to indicate that an association end owned by an association is visible as a property in a class. This is a normal thing in information modeling (not program modeling). That way, the name scoping remains correct and what people see in model diagrams will match what is in MOF and XMI. In the meantime, the "org.omg.sbvr.sameRole" tag does the job. Perhaps MOF/XMI will provide a means for removing the tags in SBVR 1.2. Best regards, Don -------------------------------------------------------------------------------- Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Fri, 13 Jan 2012 17:51:16 -0800 From: pete.rivett@adaptive.com To: Donald.Chapin@BusinessSemantics.com CC: donbaisley@live.com; nicolas.f.rouquette@jpl.nasa.gov; andrew@omg.org; sbvr-rtf@omg.org (Before getting bogged down in the point at the start of the email I suggest readers peek ahead to **) To the technical issue, my concern is about use of the link from Element to Tag to represent a relationship between the Elements. That.s like saying in UML that 2 elements can be related by applying the same stereotype to them! As per the MOF spec, .A Tag represents a single piece of information that can be associated with any number of model elements. . In this case there is no information since the .value. property is empty on all of these. Furthermore there is nothing whatsoever in MOF semantics to support the critical aspect of .same role. . which is that any update to the class-owned property is reflected when reading the association-owned property and vice-versa. As far as MOF is concerned they are 2 entirely independent properties with no relationship to each other. To achieve what I think you wanted the properties would need to be both derived (from each other) and updateable (with update logic to update the other property). The SBVR spec says nothing about this. Just because this was present in SBVR 1.0 does not make it right. Hence this new urgent issue . which affects the formal publishing of a correct SBVR 1.1 so that the same problems are not carried forward. ** The good news is that I believe that the above, and the points in your email, are moot. I did some digging back to 2007 and came across the attached email conversation between myself and Don back in 2007. It seems that the driver for use of both attributes and association ends was the restriction in XMI that did not allow serialization of Association instances when one/both ends were owned by a Class. The big news is that the solution did not need to .wait for SMOF. since XMI 2.4 added that capability (as resolution to issue 9695). Hence it is sufficient in SBVR to have all ends owned by classes and that gives the option of serializing as attributes or associations on a case-by-case basis to represent the open/closed semantics required. So there is no need to have both attributes and association ends with the clunky and suspect use of Tags to link them (with no reconciliation of updates between them). Regards Pete PS while reading through the SBVR 1.1 spec I noticed frequent mention to .MOF 2.0. (you.re using .MOF 2.4.1. . I suggest just using .MOF 2.) and examples of XMI (e.g. in 13.6) that do not comply with the XMI 2.4.1 rules: specifically that every XML element (except those that have an href or an xmi:idref) have an xmi:type attribute. This is not part of the urgent issue but just thought I.d mention it. From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: Friday, January 13, 2012 4:28 AM To: Pete Rivett; sbvr-rtf@omg.org Cc: Andrew Watson; nicolas.f.rouquette@jpl.nasa.gov Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Pete, I.ve have responded to your points in-line below. I have shown below how SBVR complies with the relevant OMG specifications. I have also shown that the three places, where the mechanics of the SBVR XMI file I produced for the Santa Clara meet were not exactly correct, can and will be easily fixed next week with a revised SBVR v1.1 XMI file. There is nothing to be fixed in SBVR.s use of the UML 2.4.1 and XMI 2.4.1 specifications, so this Issue has a .No Change. disposition. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 09 January 2012 21:39 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Subject: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Thu, 15 Dec 2011 16:50:43 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: Acy7jLlYRtB6JAE9TPq9DhbQaHkB0Q== From: "Pete Rivett" To: , Cc: , Section 13.2.5 is based on a misunderstanding and misuse of MOF: a) the phrase .In each case where an attribute and an association end represent the same role, the SBVR Metamodel includes a tag that tags both the attribute and the association end. . is in ignorance of the fact that in MOF2 and UML 2 that .attributes. and .association ends. are both represented as instances of Property: and in such a case there would be a single instance of Property linked to the Class using the attribute meta-property and from the Association by the memberEnd (or ownedEnd) property: eliminating the need to link two separate elements. First, this is about who owns the Association End. MOF supports two options for ownership of the Association End: and the Association and the Class. SBVR Clause 13 used the Association ownership of the Association End to support open world semantics (see SBVR Clause 13.3.2). This Association ownership of the Association Ends use of MOF is exactly as it was in SBVR v1.0. Secondly, the problem we had in December with the .sameRole TAG. coming through as a stereotype which MOF does not support is a directly result of my being told to implement the .sameRole Tag. that way by Nicolas. I should have been told to use your MOF Profile to create MOF Tags. I will get that from Nicolas an produce both kinds of MOF Tags correctly. Third, the use of the .sameRole Tag. is necessary to interchange some SBVR linguistic semantics (attributive namespaces) that are not part of UML or MOF (see SBVR Clause 13.2.5). The bottom line on this particular point is that, once I have generated MOF Tags correctly using your MOF Profile, there is nothing wrong with the SBVR specification or the XMI file that I am generating. b) attempting to use MOF Tags to link two properties. In fact MOF Tags are .Simple string name-value pairs.. Yes, that is part of the story. It is also true that in the XMI 2.4.1 specification MOF Tags and have 0..* elements which are each specified by an XMI:id. SBVR uses two elements in MOF .sameRole Tags., each specified by an XMI:id (even though at first glance they look like qualified names). This is exactly what the SBVR v1.0 XMI file (attached) did. In this attached SBVR v1.0 XMI file you will be that each element of a MOF Tag is defined as an XMI:id. It is exactly what I tried to do for the SBVR v1.1. Since I did not at the time know of the existence of a MOF Profile and was not given it while I was in Santa Clara, I was not able to produce the MOF Tags correctly. I will do this correctly next week as well. On this particular point there is no problem of SBVR.s use of the XMI 2.4.1 specification. This is an urgent issue since it affects the production of the SBVR 1.1 artifacts: there is in fact no need for the tags that have caused some of the difficulties producing the machine-readable files: even the file I sent today for the metamodel, which uses the Tag value property does not match this section of the spec which states that value is the empty string. The problem of .value. not being am empty string has to do with the way Magic Draw exports XMI. I will find a work around and produce an XMI file with the MOF Tag values properly empty. So there is not SBVR specification Issue on this particular point. Pete Best regards, -Juergen Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org --Forwarded Message Attachment-- Subject: RE: SBVR XSDs Needed Date: Tue, 11 Sep 2007 04:40:09 -0800 From: pete.rivett@adaptive.com To: Donald.Baisley@unisys.com CC: Donald.Chapin@btinternet.com Hi Don, See below. To summarize the current status of my 4 points: 1. I think you're agreeing to fix, though I have already done so in the CMOF and XSD I sent you. 2. Is the only one outstanding. Where I think the solution is to have 2 sets of files. The CMOF and XSD I sent represent one set: the other would import this metamodel and apply the aliases. 3. The CMOF and XSD I sent already does what you need - as I understand your requirement 4. I just noticed that elementImports are not NamedElements so cannot be named or aliased in any case. So my removal of aliases for elementImports is correct Pete -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: Friday, September 07, 2007 8:13 PM To: Pete Rivett Cc: Donald.Chapin@btinternet.com Subject: RE: SBVR XSDs Needed Hi Pete, 1. Since Namespace.ownedMember is derived (Figure 9.38 in formal/05-07-05), Package.ownedMember which redefines it is necessarily derived according to the definition of .isConsistentWith.. Figure 12.4 in formal/06-01-01 and Figure 10.5 in formal/05-07-05 do not show ownedType as derived . so ownedType appears to not be derived for EMOF. But ownedType is derived in Constructs, so that makes it derived in CMOF (necessitated by .isConsistentWith.). The end result is that both ownedMember and ownedType are derived in CMOF. Is this the bug you were talking about?[Pete Rivett] the bug was that the non-derived Package::ownedMember redefined the derived Namespace::ownedmember. The fix was that in UML 2.1 the former has been replaced by Package::packagedElement. So even then ownedType is still derived and not serialized. Does this mean that EMOF XMI documents cannot be read as CMOF XMI? Is EMOF not a subset for purposes of interchange?. Is it just different? That is bad news. It would be best if ownedMember and ownedType both have XMI tags making them writeable. ownedType is one of the cases where a property becomes derived at a higher level of UML. Another is that at LM Class::general is not derived but it is at L1. For such cases importers of a 'lower' level need to apply the derivatino semantic- in the former case to set packagedElement/ownedMember and in the latter to create a Generalization element. Based on your request, I will change the use of ownedType to ownedMember in the SBVR Metamodel XML. This XML change requires no change to the SBVR specification. 2. When a class has a name in a package and also an alias in the same package, then there are two ways to refer to the one class in the package. Both are perfectly valid. Both names are in the namespace for the one class. [Pete Rivett] OK I see what you're trying to achieve now, though looking at the spec that's not strictly speaking the description of alias - quoting from formal 5/7/5 (my emphasis) "Specifies the name that should be added to the namespace of the importing Package in lieu of the name of the imported PackagableElement." For writing XML, it means that either name can be used . both mean the same thing. In a MOF repository, there is just one class, so when reading XML, finding either name puts something in the same class. When writing XML from a repository, use either name, not both.[Pete Rivett] would you expect a single file to use the same anme consistently for a single class? We use aliases for synonyms in order to keep the SBVR XMI in sync with the SBVR vocabulary. We discussed this at the end of last year. If your MOF tooling cannot handle generating an XSD for a metamodel that has element imports, then I can generate the XSD when I generate the metamodel XML.[Pete Rivett] it would make the XSD even less useful for validation - since one could not readily specify that only one of the 2 names should be used. Our tooling cannot generate such an XSD. If you can then do you need me to do anythign else? You are correct that the XMI 2.1 Specification does not talk about element imports or their aliases. It also does not talk about ownedMember, ownedType or a lot of specific things. But one would assume that XMI works for element imports as it does for owned elements.[Pete Rivett] The point is that it does not address the possibility of using 2 different XML element names for the same metamodel element. And even the MOF/Infra spec states that the alias is for use instead of the original name (see above) An attempt to change how this works now would be problematic at this late point in time.[Pete Rivett] Maybe there could be 2 separate XSD/XMI files for the different purposes based on what you hinted at with respect to imports into a 'dummy' package. 3. The rationale for using attributes in addition to associations is explained in greater detail in 13.3.2. The brief explanation you mentioned points to 13.3.2. SBVR.s metamodel needs this workaround until SMOF comes along and provides another means by which an XMI document can distinguish the open and closed cases. I discussed this workaround with you before proposing it as a way to have a more typical MOF metamodel for SBVR. Without this workaround, SBVR would need to stay with the previous RDF-like use of MOF, which some OMG folks did not like. Note that SBVR.s metamodel is aimed at supporting XMI interchange. If a repository has other means of handling open/closed, then the repository model can be transformed to take advantage of those means. But SBVR.s metamodel must support an XMI interchange capability that handles the distinction. [Pete Rivett] The correction I proposed, with the attribute linked to the association, and XSD I generated, does allow XMI interchange expression of relationships either as attributes or Association instances (links)! It presumes that we relax the current formal XMI restriction (in the spec but not our implementation) that Association instances may only be interchanged if the Association owns both of its ends - but that is a minor change/hassle compared to havign the attributes and ends completely unrelated As you explained to me months ago, if a MOF class owns an attribute that is the end of some association, then the XMI documents don.t get to use individual links of that association. So we use our workaround until SMOF gives us a better way. Best regards, Don -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, September 06, 2007 5:32 PM To: Donald.Chapin@btinternet.com Cc: Baisley, Donald E Subject: RE: SBVR XSDs Needed I've been with a customer in Germany the last 3 days with little email access (or time to read them!). I will be on a con call for about 7 hours tomorrow starting 9am EDT so will not be available. Responses in maroon. I did not make the changes I did lightly (and they did take a fair amount of time and energy). Without them I could not have used our technology to generate the schema (with the possible exception of issue 3). Pete -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: Thursday, September 06, 2007 12:25 PM To: Pete Rivett Cc: 'Baisley, Donald E' Subject: FW: SBVR XSDs Needed Importance: High Hi Pete, Do I need to arrange a telecon for you, Don and me; or can you answer Don.s questions without needing to talk with him? I.m concerned that Don may need to produce a revised XMI file that doesn.t need to be tweaked so that the XMI and XSD files are in synch and agree with SBVR Clause 13 . and time is passing. Thanks, Donald -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: 04 September 2007 20:58 To: Pete Rivett Cc: Donald.Chapin@btinternet.com Subject: RE: SBVR XSDs Needed Hi Pete, Please see comments in blue below. Don -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Sunday, September 02, 2007 5:27 PM To: Baisley, Donald E Cc: Donald.Chapin@btinternet.com Subject: RE: SBVR XSDs Needed Importance: High I've just looked at SBVR.xml as per Don's voicemail. It has the following problems: 1) ownedType is incorrectly used instead of ownedMember (ownedType is derived and hence not serialized). This was a simple edit to fix via global edit. Where in Infrastructure 2.0 or MOF 2.0 is it documented that ownedType is derived? I am looking at formal/05-07-05 and formal/06-01-01. MOF 2.0 says .Namespace::ownedMember (Note that this is abstract, so appropriate specializations must be used.).. [Pete Rivett] Figure 11.26 of formal/5-7-5. Now namespace::ownedMember is derived (hence the quote in the MOF 2.0 spec) but Package::ownedMember is not. This was a bug and package::packagedMember was introduced instead (though at UML 2.1 which does not apply to MOF 2.0). However if you look at the later UML specs you can see that ownedType has always been shown as derived. And if you look at the UML metamodel itself, it uses ownedMember. 2) elementImport is used for elements in the same package (it is only valid for elements in a differetn package). SBVR uses elementImport for aliasing (based on synonyms in the SBVR vocabulary) . one model element can have two names. The only clue I can find in the Infrastructure 2.0 or MOF 2.0 specifications about importing being from a .different. package is that the introduction to ElementImport uses the word .another. in a general statement that makes no claim to being a limitation. There is no constraint that prevents importing from the same package. I discussed this with you at the end of last year when deciding to take SBVR.s new approach to using MOF. [Pete Rivett] What I'm having a problem with is the formal meaning of such an alias. It's clearer when from a different package - the alias overrides the other name. Though the application of this is generally only for 'programming language' or maybe OCL expressions. The XMI spec says nothing about such aliases. It gets worse if the alias is in the same package: what would you expect to happen? To completely replace the original name (I think not since you want 2 names)? For example in XMI which is the current topic, when exporting would you expect the same instance to be exported twice as two XML elements with different XML element names? It was really the lack of reference to aliases in XMI and lack of ability to answer these questions that led me to delete them. If importing from that same Package is not going to be supported, then I suppose I will have to import twice to get the desired result. I can do a package import of everything into a dummy package and then do element imports from there. [Pete Rivett] Hmm still not sure what effect you're trying to achieve. It's not clear what effect you're tryign to achieve with elementImports - to take an example we have: which is followed by: which I assume is intended to renam it to behavioral business rule. However later on we have the following which, as far as the XSD and XMI interchange is concerned, puts the first word back from 'behavioral' to 'operative'. So I ignored the elementImports. [Pete Rivett] You did not respond what you were trying to achieve. 3) There are many cases where an association end is owned by a class, but the end is not properly tied up with the association. I see there is a tag, org.omg.sbvr.sameRole, very briefly mentioned (but not justified) in section 13.2.5 of the SBVR spec. MOF has no functionality for recognizing this tag; and already has functionality for linking 'attributes' to association roles so don't see why it's needed. Attributes are used for complete extensions and links are used with an open world assumption. [Pete Rivett] OK I remember the issue now - would be useful to explain this in 13.2.5 of SBVR. However I don't necessarily agree with the resolution in terms of a MOF implementation. I guess I missed this when balloted - what Issue number was it? MOF does not need to handle this at this time. SMOF will hopefully support open/closed without the need for the work-around. The XSD generation can ignore these .sameRole. tags. The XSD must keep them separate, as in the metamodel. For example: Should be tied up in MOF with the Association element: However the association does not reference the end owned by the class, nor vice versa. What I think you should have is the following, changes in olive: I wrote XSL to fix up this based on the sbvr tags. Without that, no MOF repository is going to be able to maintain the attribute and the association in synch. No MOF repository should be expected to keep these in synch until SMOF comes along with a solution. [Pete Rivett] Not keeping them in synch seems crazy and wrong - and not what a repository should be about. For now, software that uses a MOF repository for SBVR can use the tags to know what is going on.[Pete Rivett] Which is what I did by doing the substitution/deletion. No MOF repository can be expected to know about the tags. 4) There is an xmiName tag applied to a few elementImports which is pointless since the names of the imports themselves are never made use of. For example: Since I was filtering out the elementImports I wrote some more XSL to remove these. These need to stay, along with the element imports. [Pete Rivett] What use would you expect the name for an import element (as opposed to the alias it introduces) to have. As naming it seems pointless (except possible for management purposes) then renaming it seems more so. Attached is the fixed CMOF metamodel and the XSD. Also the XSL file I used to make the fixes. I lost track of the URI you agreed to use so you may want to adjust that in the header. This UR (and the ns prefix) should also be recorded in the metamodel as XMI Tags. Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Hello House, 135 Somerford Road, Christchurch, BH23 3PY, UK Tel: +44 (0)1202 491243 Fax: +44 (0)1202 491241 http://www.adaptive.com -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: Friday, August 24, 2007 2:25 AM To: Pete Rivett Cc: Donald.Chapin@btinternet.com Subject: SBVR XSDs Needed Hi Pete, Can you please create XSDs for each of the attached files (which I just sent to the SBVR-FTF mailing list)? Each file gives a package that is already .merged.. Please send the files to the SBVR-FTF mailing list. Also, please let me know if you find errors in the files. Gene Mutschler was able to load them with his CMOF tool. Thanks, Don Issue 10577.doc Date: Wed, 18 Jan 2012 17:45:50 +0000 To: sbvr-rtf@omg.org, Pete Rivett From: Andrew Watson Subject: Re: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Good Afternoon, On 15th December Pete Rivett filed issue 16913 against SBVR, and asked that it be resolved Urgently: > Section 13.2.5 is based on a misunderstanding and misuse of MOF: > > a) the phrase "In each case where an attribute and an association end > represent the same role, the SBVR Metamodel includes a tag that tags both > the attribute and the association end." is in ignorance of the fact that > in MOF2 and UML 2 that "attributes" and "association ends" are both > represented as instances of Property: and in such a case there would be a > single instance of Property linked to the Class using the attribute > meta-property and from the Association by the memberEnd (or ownedEnd) > property: eliminating the need to link two separate elements. > > b) attempting to use MOF Tags to link two properties. In fact MOF Tags > are "Simple string name-value pairs". > > This is an urgent issue since it affects the production of the SBVR 1.1 > artifacts: there is in fact no need for the tags that have caused some of > the difficulties producing the machine-readable files: even the file I > sent today for the metamodel, which uses the Tag value property does not > match this section of the spec which states that value is the empty string. Some procedural background: The SBVR 1.1 RTF was chartered on 28th September 2007. Its comment deadline passed on 29th February 2008. Its most recent delivery deadline was set for the Santa Clara (December 2011) meeting, and it completed a report in time for that meeting. The delivery deadline has now been extended to 30th March: http://www.omg.org/techprocess/meetings/schedule/SBVR_RTF.html The SBVR 1.2 RTF was chartered on 16th December 2011. Its comment deadline was 15th January 2012, as it also has a delivery deadline of 30th March: http://www.omg.org/techprocess/meetings/schedule/SBVR_1.2_RTF.html (We therefore have the rather unusual situation that the two RTFs exist simultaneously, and have the same delivery deadline). If this issue had not been declared as Urgent, because it was filed after the SBVR 1.1 RTF comment deadline the 1.1 RTF would not be obliged to include a resolution in its report, but could do so if it chose. However, if the SBVR 1.1 RTF were not to resolve the issue, the SBVR 1.2 RTF would be obliged to handle it, since the issue came in before the 1.2 RTF comment deadline. If the Technical Director (right now, that's me) declares this issue as Urgent, (s)he can direct a particular RTF to resolve it, and ensure that a resolution is available within two weeks (see P&P 4.4.1.5). If (s)he does, (s)he "will propose specific wording for the clarification". After careful consideration, I have decided not to declare this issue as urgent. Since this may be a controversial decision, I'll explain how I reached it. Firstly, at the moment it seems likely that either the SBVR 1.1 or 1.2 RTF would vote to close the issue with no change to the specification. Certainly this is the only resolution that has so far been discussed by members of either RTF, and in the absence of any other advice, it would have to be the "specific wording" that I would propose as a default resolution. While there is ongoing work to provide an SBVR 1.1 XMI file that implements the existing 1.1 RTF resolutions, procedurally speaking finishing that is separable from resolving this issue. Secondly, while every issue that reports a problem with an OMG specification is important, a defining characteristic of an Urgent issue is that it's critically important to some implementer. I don't currently know of any SBVR implementers looking for clarification here. Thirdly, as the RTF deadlines stand, the issue will in any case be resolved in a report delivered around 20th February. Hence flagging the issue as "Urgent" would never have speeded up the availability of a resolution by much. While it's certainly possible for RTF report deadlines to be moved, delaying the availability of a resolution, if that resolution is "no change", the point is moot. In spite of this decision not to formally flag the issue as "Urgent", I suggest that one of the two RTFs should vote soon on a resolution for this issue, to help clear away some of the uncertainty. If anyone has any questions, please drop me a note. Thanks, Andrew From: "Donald Chapin" To: Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Fri, 20 Jan 2012 13:10:20 -0000 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJKt/vhqpiJyZT42GQlejSR+2KGNpUZd+gQ X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4F1967C0.006B, actions=tag X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2012.1.20.123015:17:9.975, ip=81.149.51.65, rules=__TO_MALFORMED_2, __TO_NO_NAME, __FRAUD_SUBJ_A, __PHISH_SPEAR_SUBJECT, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, DOC_ATTACHED, __ANY_URI, LINK_TO_IMAGE, __FRAUD_BODY_WEBMAIL, __FRAUD_CONTACT_NUM, ECARD_KNOWN_DOMAINS, __CP_URI_IN_BODY, __C230066_P5, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __IMGSPAM_BODY, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_50_70, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, FORGED_MUA_OUTLOOK, IMGSPAM_BODY X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4F1967C2.0233,ss=1,re=0.000,vtr=str,vl=0,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Attached is a draft resolution to SBVR Issue3 16913 for discussion in today.s SBVR RTF telecon. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 09 January 2012 21:39 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Subject: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Thu, 15 Dec 2011 16:50:43 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: Acy7jLlYRtB6JAE9TPq9DhbQaHkB0Q== From: "Pete Rivett" To: , Cc: , Section 13.2.5 is based on a misunderstanding and misuse of MOF: a) the phrase .In each case where an attribute and an association end represent the same role, the SBVR Metamodel includes a tag that tags both the attribute and the association end. . is in ignorance of the fact that in MOF2 and UML 2 that .attributes. and .association ends. are both represented as instances of Property: and in such a case there would be a single instance of Property linked to the Class using the attribute meta-property and from the Association by the memberEnd (or ownedEnd) property: eliminating the need to link two separate elements. b) attempting to use MOF Tags to link two properties. In fact MOF Tags are .Simple string name-value pairs.. This is an urgent issue since it affects the production of the SBVR 1.1 artifacts: there is in fact no need for the tags that have caused some of the difficulties producing the machine-readable files: even the file I sent today for the metamodel, which uses the Tag value property does not match this section of the spec which states that value is the empty string. Pete Best regards, -Juergen Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org Issue 16913 - ''org.omg.sbvr.sameRole' Use of MOF Tag -- was [Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2)].doc Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Fri, 20 Jan 2012 07:48:06 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: AczUhK/lBjA/jfESRp25cqO7jiYe0gDApszQ From: "Pete Rivett" To: "Don Baisley" , "Donald Chapin" Cc: , , Ø It is good that XMI 2.4 allows serialization of association links regardless of whether ends are owned by classes. However, that is not enough to allow ownership of SBVR's assocation ends to transfer to SBVR's classes. The ownership of SBVR's association ends correctly matches the namespace requirements. Transferring the ownership of all ends to classes will cause name conflicts. But each end is also represented as an attribute/Property owned by the class so how would this introduce naming conflicts that are not already there? You just need to retain each class-owned attribute named exactly as-is and ensure it.s a member of the appropriate association. Maybe that.s the .major rework. you mention? To keep other names you could use aliases, though they would need to be owned by another package. I recall seeing that SBVR already makes use of ElementImports to give aliases to some elements in the same package. This is invalid use of ElementImport: the UML/MOF specs clearly state that ElementImports are only for elements .in another package.. I recently confirmed with the UML team that .another. does mean literally that (confirmed by OCL) and it cannot be interpreted to mean the same package. Ø Regarding your point about use of tags, I find that the meaning of a tag is up to whoever defines it. Tags are for extensibility. SBVR uses the "org.omg.sbvr.sameRole" tag to represent a certain piece of inforation about a group of elements -- that they are mutually related -- they represent the same role. That is a perfectly legitimate us of a tag. It would be legitimate if the certain piece of information were represented in the .value. property of the Tag (for example representing the unique name/identifier of the role relevant to those 2 elements only): but as used in the current SBVR spec that value property is defined to be empty for all of the Tags! Hence the tags are indistinguishable and are in effect a Boolean flag indicating merely that the element has been tagged. An implementation would be entitled to combine all these indistinguishable tags into one Tag that references all the elements so tagged. Ø Or MOF could provide some other means in a metamodel to indicate that an association end owned by an association is visible as a property in a class. But would it not still need to be somehow qualified in order to avoid namespace conflicts? Regards Pete From: Don Baisley [mailto:donbaisley@live.com] Sent: Monday, January 16, 2012 11:25 AM To: Pete Rivett; Donald Chapin Cc: nicolas.f.rouquette@jpl.nasa.gov; andrew@omg.org; sbvr-rtf@omg.org Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Hi Pete, We would all like MOF and XMI to more directly support SBVR's metamodel. Particularly, we would all like each binary verb concept to show up as a single association in MOF. 1. Serialization of individual links has open world semantics (implying that the extension might be incompletely represented in the document). 2. Serialization of a property's values with respect to an object has closed world semantics for that property of that object (the extension is completely represented). It is good that XMI 2.4 allows serialization of association links regardless of whether ends are owned by classes. However, that is not enough to allow ownership of SBVR's assocation ends to transfer to SBVR's classes. The ownership of SBVR's association ends correctly matches the namespace requirements. Transferring the ownership of all ends to classes will cause name conflicts. Regarding your point about use of tags, I find that the meaning of a tag is up to whoever defines it. Tags are for extensibility. SBVR uses the "org.omg.sbvr.sameRole" tag to represent a certain piece of inforation about a group of elements -- that they are mutually related -- they represent the same role. That is a perfectly legitimate us of a tag. It would be nice for MOF and XMI to make that tag unnecessary. Example (from SBVR 13.2.5): Verb concept: thing is in set There is a binary association called "thing is in set" with two ends, "thing" and "set". Also, in the "set" class, there is an "element" property, which is effectively a redefinition of the "thing" end of the "thing is in set" association. We use the "org.omg.sbvr.sameRole" tag to relate set.element to the "thing" end of the association "thing is in set". We could remove that tag if we could use MOF's "redefinedProperty" to show the relationship. "set.element" redefines the "thing" end of the association called "thing is in set". But UML infrastructure constraints prevent that sort of redefinition. The other change that has been suggested, moving ownership of association ends to classes, will require major rework and will not be completed anytime soon. It will required inventing and documenting new generation patterns for the MOF and the XML. It requires redoing some complicated diagrams and reworking many examples. It is a large change that will require a lot of rework and testing. Since some problems need fixing in MOF/XMI anyway, it would be best for MOF to support a class-owned property being able to redefine an association end that is owned by an association. Or MOF could provide some other means in a metamodel to indicate that an association end owned by an association is visible as a property in a class. This is a normal thing in information modeling (not program modeling). That way, the name scoping remains correct and what people see in model diagrams will match what is in MOF and XMI. In the meantime, the "org.omg.sbvr.sameRole" tag does the job. Perhaps MOF/XMI will provide a means for removing the tags in SBVR 1.2. Best regards, Don -------------------------------------------------------------------------------- Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Fri, 13 Jan 2012 17:51:16 -0800 From: pete.rivett@adaptive.com To: Donald.Chapin@BusinessSemantics.com CC: donbaisley@live.com; nicolas.f.rouquette@jpl.nasa.gov; andrew@omg.org; sbvr-rtf@omg.org (Before getting bogged down in the point at the start of the email I suggest readers peek ahead to **) To the technical issue, my concern is about use of the link from Element to Tag to represent a relationship between the Elements. That.s like saying in UML that 2 elements can be related by applying the same stereotype to them! As per the MOF spec, .A Tag represents a single piece of information that can be associated with any number of model elements. . In this case there is no information since the .value. property is empty on all of these. Furthermore there is nothing whatsoever in MOF semantics to support the critical aspect of .same role. . which is that any update to the class-owned property is reflected when reading the association-owned property and vice-versa. As far as MOF is concerned they are 2 entirely independent properties with no relationship to each other. To achieve what I think you wanted the properties would need to be both derived (from each other) and updateable (with update logic to update the other property). The SBVR spec says nothing about this. Just because this was present in SBVR 1.0 does not make it right. Hence this new urgent issue . which affects the formal publishing of a correct SBVR 1.1 so that the same problems are not carried forward. ** The good news is that I believe that the above, and the points in your email, are moot. I did some digging back to 2007 and came across the attached email conversation between myself and Don back in 2007. It seems that the driver for use of both attributes and association ends was the restriction in XMI that did not allow serialization of Association instances when one/both ends were owned by a Class. The big news is that the solution did not need to .wait for SMOF. since XMI 2.4 added that capability (as resolution to issue 9695). Hence it is sufficient in SBVR to have all ends owned by classes and that gives the option of serializing as attributes or associations on a case-by-case basis to represent the open/closed semantics required. So there is no need to have both attributes and association ends with the clunky and suspect use of Tags to link them (with no reconciliation of updates between them). Regards Pete PS while reading through the SBVR 1.1 spec I noticed frequent mention to .MOF 2.0. (you.re using .MOF 2.4.1. . I suggest just using .MOF 2.) and examples of XMI (e.g. in 13.6) that do not comply with the XMI 2.4.1 rules: specifically that every XML element (except those that have an href or an xmi:idref) have an xmi:type attribute. This is not part of the urgent issue but just thought I.d mention it. From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: Friday, January 13, 2012 4:28 AM To: Pete Rivett; sbvr-rtf@omg.org Cc: Andrew Watson; nicolas.f.rouquette@jpl.nasa.gov Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Pete, I.ve have responded to your points in-line below. I have shown below how SBVR complies with the relevant OMG specifications. I have also shown that the three places, where the mechanics of the SBVR XMI file I produced for the Santa Clara meet were not exactly correct, can and will be easily fixed next week with a revised SBVR v1.1 XMI file. There is nothing to be fixed in SBVR.s use of the UML 2.4.1 and XMI 2.4.1 specifications, so this Issue has a .No Change. disposition. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 09 January 2012 21:39 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Subject: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Thu, 15 Dec 2011 16:50:43 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: Acy7jLlYRtB6JAE9TPq9DhbQaHkB0Q== From: "Pete Rivett" To: , Cc: , Section 13.2.5 is based on a misunderstanding and misuse of MOF: a) the phrase .In each case where an attribute and an association end represent the same role, the SBVR Metamodel includes a tag that tags both the attribute and the association end. . is in ignorance of the fact that in MOF2 and UML 2 that .attributes. and .association ends. are both represented as instances of Property: and in such a case there would be a single instance of Property linked to the Class using the attribute meta-property and from the Association by the memberEnd (or ownedEnd) property: eliminating the need to link two separate elements. First, this is about who owns the Association End. MOF supports two options for ownership of the Association End: and the Association and the Class. SBVR Clause 13 used the Association ownership of the Association End to support open world semantics (see SBVR Clause 13.3.2). This Association ownership of the Association Ends use of MOF is exactly as it was in SBVR v1.0. Secondly, the problem we had in December with the .sameRole TAG. coming through as a stereotype which MOF does not support is a directly result of my being told to implement the .sameRole Tag. that way by Nicolas. I should have been told to use your MOF Profile to create MOF Tags. I will get that from Nicolas an produce both kinds of MOF Tags correctly. Third, the use of the .sameRole Tag. is necessary to interchange some SBVR linguistic semantics (attributive namespaces) that are not part of UML or MOF (see SBVR Clause 13.2.5). The bottom line on this particular point is that, once I have generated MOF Tags correctly using your MOF Profile, there is nothing wrong with the SBVR specification or the XMI file that I am generating. b) attempting to use MOF Tags to link two properties. In fact MOF Tags are .Simple string name-value pairs.. Yes, that is part of the story. It is also true that in the XMI 2.4.1 specification MOF Tags and have 0..* elements which are each specified by an XMI:id. SBVR uses two elements in MOF .sameRole Tags., each specified by an XMI:id (even though at first glance they look like qualified names). This is exactly what the SBVR v1.0 XMI file (attached) did. In this attached SBVR v1.0 XMI file you will be that each element of a MOF Tag is defined as an XMI:id. It is exactly what I tried to do for the SBVR v1.1. Since I did not at the time know of the existence of a MOF Profile and was not given it while I was in Santa Clara, I was not able to produce the MOF Tags correctly. I will do this correctly next week as well. On this particular point there is no problem of SBVR.s use of the XMI 2.4.1 specification. This is an urgent issue since it affects the production of the SBVR 1.1 artifacts: there is in fact no need for the tags that have caused some of the difficulties producing the machine-readable files: even the file I sent today for the metamodel, which uses the Tag value property does not match this section of the spec which states that value is the empty string. The problem of .value. not being am empty string has to do with the way Magic Draw exports XMI. I will find a work around and produce an XMI file with the MOF Tag values properly empty. So there is not SBVR specification Issue on this particular point. Pete Best regards, -Juergen Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org --Forwarded Message Attachment-- Subject: RE: SBVR XSDs Needed Date: Tue, 11 Sep 2007 04:40:09 -0800 From: pete.rivett@adaptive.com To: Donald.Baisley@unisys.com CC: Donald.Chapin@btinternet.com Hi Don, See below. To summarize the current status of my 4 points: 1. I think you're agreeing to fix, though I have already done so in the CMOF and XSD I sent you. 2. Is the only one outstanding. Where I think the solution is to have 2 sets of files. The CMOF and XSD I sent represent one set: the other would import this metamodel and apply the aliases. 3. The CMOF and XSD I sent already does what you need - as I understand your requirement 4. I just noticed that elementImports are not NamedElements so cannot be named or aliased in any case. So my removal of aliases for elementImports is correct Pete -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: Friday, September 07, 2007 8:13 PM To: Pete Rivett Cc: Donald.Chapin@btinternet.com Subject: RE: SBVR XSDs Needed Hi Pete, 1. Since Namespace.ownedMember is derived (Figure 9.38 in formal/05-07-05), Package.ownedMember which redefines it is necessarily derived according to the definition of .isConsistentWith.. Figure 12.4 in formal/06-01-01 and Figure 10.5 in formal/05-07-05 do not show ownedType as derived . so ownedType appears to not be derived for EMOF. But ownedType is derived in Constructs, so that makes it derived in CMOF (necessitated by .isConsistentWith.). The end result is that both ownedMember and ownedType are derived in CMOF. Is this the bug you were talking about?[Pete Rivett] the bug was that the non-derived Package::ownedMember redefined the derived Namespace::ownedmember. The fix was that in UML 2.1 the former has been replaced by Package::packagedElement. So even then ownedType is still derived and not serialized. Does this mean that EMOF XMI documents cannot be read as CMOF XMI? Is EMOF not a subset for purposes of interchange?. Is it just different? That is bad news. It would be best if ownedMember and ownedType both have XMI tags making them writeable. ownedType is one of the cases where a property becomes derived at a higher level of UML. Another is that at LM Class::general is not derived but it is at L1. For such cases importers of a 'lower' level need to apply the derivatino semantic- in the former case to set packagedElement/ownedMember and in the latter to create a Generalization element. Based on your request, I will change the use of ownedType to ownedMember in the SBVR Metamodel XML. This XML change requires no change to the SBVR specification. 2. When a class has a name in a package and also an alias in the same package, then there are two ways to refer to the one class in the package. Both are perfectly valid. Both names are in the namespace for the one class. [Pete Rivett] OK I see what you're trying to achieve now, though looking at the spec that's not strictly speaking the description of alias - quoting from formal 5/7/5 (my emphasis) "Specifies the name that should be added to the namespace of the importing Package in lieu of the name of the imported PackagableElement." For writing XML, it means that either name can be used . both mean the same thing. In a MOF repository, there is just one class, so when reading XML, finding either name puts something in the same class. When writing XML from a repository, use either name, not both.[Pete Rivett] would you expect a single file to use the same anme consistently for a single class? We use aliases for synonyms in order to keep the SBVR XMI in sync with the SBVR vocabulary. We discussed this at the end of last year. If your MOF tooling cannot handle generating an XSD for a metamodel that has element imports, then I can generate the XSD when I generate the metamodel XML.[Pete Rivett] it would make the XSD even less useful for validation - since one could not readily specify that only one of the 2 names should be used. Our tooling cannot generate such an XSD. If you can then do you need me to do anythign else? You are correct that the XMI 2.1 Specification does not talk about element imports or their aliases. It also does not talk about ownedMember, ownedType or a lot of specific things. But one would assume that XMI works for element imports as it does for owned elements.[Pete Rivett] The point is that it does not address the possibility of using 2 different XML element names for the same metamodel element. And even the MOF/Infra spec states that the alias is for use instead of the original name (see above) An attempt to change how this works now would be problematic at this late point in time.[Pete Rivett] Maybe there could be 2 separate XSD/XMI files for the different purposes based on what you hinted at with respect to imports into a 'dummy' package. 3. The rationale for using attributes in addition to associations is explained in greater detail in 13.3.2. The brief explanation you mentioned points to 13.3.2. SBVR.s metamodel needs this workaround until SMOF comes along and provides another means by which an XMI document can distinguish the open and closed cases. I discussed this workaround with you before proposing it as a way to have a more typical MOF metamodel for SBVR. Without this workaround, SBVR would need to stay with the previous RDF-like use of MOF, which some OMG folks did not like. Note that SBVR.s metamodel is aimed at supporting XMI interchange. If a repository has other means of handling open/closed, then the repository model can be transformed to take advantage of those means. But SBVR.s metamodel must support an XMI interchange capability that handles the distinction. [Pete Rivett] The correction I proposed, with the attribute linked to the association, and XSD I generated, does allow XMI interchange expression of relationships either as attributes or Association instances (links)! It presumes that we relax the current formal XMI restriction (in the spec but not our implementation) that Association instances may only be interchanged if the Association owns both of its ends - but that is a minor change/hassle compared to havign the attributes and ends completely unrelated As you explained to me months ago, if a MOF class owns an attribute that is the end of some association, then the XMI documents don.t get to use individual links of that association. So we use our workaround until SMOF gives us a better way. Best regards, Don -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, September 06, 2007 5:32 PM To: Donald.Chapin@btinternet.com Cc: Baisley, Donald E Subject: RE: SBVR XSDs Needed I've been with a customer in Germany the last 3 days with little email access (or time to read them!). I will be on a con call for about 7 hours tomorrow starting 9am EDT so will not be available. Responses in maroon. I did not make the changes I did lightly (and they did take a fair amount of time and energy). Without them I could not have used our technology to generate the schema (with the possible exception of issue 3). Pete -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: Thursday, September 06, 2007 12:25 PM To: Pete Rivett Cc: 'Baisley, Donald E' Subject: FW: SBVR XSDs Needed Importance: High Hi Pete, Do I need to arrange a telecon for you, Don and me; or can you answer Don.s questions without needing to talk with him? I.m concerned that Don may need to produce a revised XMI file that doesn.t need to be tweaked so that the XMI and XSD files are in synch and agree with SBVR Clause 13 . and time is passing. Thanks, Donald -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: 04 September 2007 20:58 To: Pete Rivett Cc: Donald.Chapin@btinternet.com Subject: RE: SBVR XSDs Needed Hi Pete, Please see comments in blue below. Don -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Sunday, September 02, 2007 5:27 PM To: Baisley, Donald E Cc: Donald.Chapin@btinternet.com Subject: RE: SBVR XSDs Needed Importance: High I've just looked at SBVR.xml as per Don's voicemail. It has the following problems: 1) ownedType is incorrectly used instead of ownedMember (ownedType is derived and hence not serialized). This was a simple edit to fix via global edit. Where in Infrastructure 2.0 or MOF 2.0 is it documented that ownedType is derived? I am looking at formal/05-07-05 and formal/06-01-01. MOF 2.0 says .Namespace::ownedMember (Note that this is abstract, so appropriate specializations must be used.).. [Pete Rivett] Figure 11.26 of formal/5-7-5. Now namespace::ownedMember is derived (hence the quote in the MOF 2.0 spec) but Package::ownedMember is not. This was a bug and package::packagedMember was introduced instead (though at UML 2.1 which does not apply to MOF 2.0). However if you look at the later UML specs you can see that ownedType has always been shown as derived. And if you look at the UML metamodel itself, it uses ownedMember. 2) elementImport is used for elements in the same package (it is only valid for elements in a differetn package). SBVR uses elementImport for aliasing (based on synonyms in the SBVR vocabulary) . one model element can have two names. The only clue I can find in the Infrastructure 2.0 or MOF 2.0 specifications about importing being from a .different. package is that the introduction to ElementImport uses the word .another. in a general statement that makes no claim to being a limitation. There is no constraint that prevents importing from the same package. I discussed this with you at the end of last year when deciding to take SBVR.s new approach to using MOF. [Pete Rivett] What I'm having a problem with is the formal meaning of such an alias. It's clearer when from a different package - the alias overrides the other name. Though the application of this is generally only for 'programming language' or maybe OCL expressions. The XMI spec says nothing about such aliases. It gets worse if the alias is in the same package: what would you expect to happen? To completely replace the original name (I think not since you want 2 names)? For example in XMI which is the current topic, when exporting would you expect the same instance to be exported twice as two XML elements with different XML element names? It was really the lack of reference to aliases in XMI and lack of ability to answer these questions that led me to delete them. If importing from that same Package is not going to be supported, then I suppose I will have to import twice to get the desired result. I can do a package import of everything into a dummy package and then do element imports from there. [Pete Rivett] Hmm still not sure what effect you're trying to achieve. It's not clear what effect you're tryign to achieve with elementImports - to take an example we have: which is followed by: which I assume is intended to renam it to behavioral business rule. However later on we have the following which, as far as the XSD and XMI interchange is concerned, puts the first word back from 'behavioral' to 'operative'. So I ignored the elementImports. [Pete Rivett] You did not respond what you were trying to achieve. 3) There are many cases where an association end is owned by a class, but the end is not properly tied up with the association. I see there is a tag, org.omg.sbvr.sameRole, very briefly mentioned (but not justified) in section 13.2.5 of the SBVR spec. MOF has no functionality for recognizing this tag; and already has functionality for linking 'attributes' to association roles so don't see why it's needed. Attributes are used for complete extensions and links are used with an open world assumption. [Pete Rivett] OK I remember the issue now - would be useful to explain this in 13.2.5 of SBVR. However I don't necessarily agree with the resolution in terms of a MOF implementation. I guess I missed this when balloted - what Issue number was it? MOF does not need to handle this at this time. SMOF will hopefully support open/closed without the need for the work-around. The XSD generation can ignore these .sameRole. tags. The XSD must keep them separate, as in the metamodel. For example: Should be tied up in MOF with the Association element: However the association does not reference the end owned by the class, nor vice versa. What I think you should have is the following, changes in olive: I wrote XSL to fix up this based on the sbvr tags. Without that, no MOF repository is going to be able to maintain the attribute and the association in synch. No MOF repository should be expected to keep these in synch until SMOF comes along with a solution. [Pete Rivett] Not keeping them in synch seems crazy and wrong - and not what a repository should be about. For now, software that uses a MOF repository for SBVR can use the tags to know what is going on.[Pete Rivett] Which is what I did by doing the substitution/deletion. No MOF repository can be expected to know about the tags. 4) There is an xmiName tag applied to a few elementImports which is pointless since the names of the imports themselves are never made use of. For example: Since I was filtering out the elementImports I wrote some more XSL to remove these. These need to stay, along with the element imports. [Pete Rivett] What use would you expect the name for an import element (as opposed to the alias it introduces) to have. As naming it seems pointless (except possible for management purposes) then renaming it seems more so. Attached is the fixed CMOF metamodel and the XSD. Also the XSL file I used to make the fixes. I lost track of the URI you agreed to use so you may want to adjust that in the header. This UR (and the ns prefix) should also be recorded in the metamodel as XMI Tags. Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Hello House, 135 Somerford Road, Christchurch, BH23 3PY, UK Tel: +44 (0)1202 491243 Fax: +44 (0)1202 491241 http://www.adaptive.com -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: Friday, August 24, 2007 2:25 AM To: Pete Rivett Cc: Donald.Chapin@btinternet.com Subject: SBVR XSDs Needed Hi Pete, Can you please create XSDs for each of the attached files (which I just sent to the SBVR-FTF mailing list)? Each file gives a package that is already .merged.. Please send the files to the SBVR-FTF mailing list. Also, please let me know if you find errors in the files. Gene Mutschler was able to load them with his CMOF tool. Thanks, Don Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Fri, 20 Jan 2012 17:40:15 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: AQJKt/vhqpiJyZT42GQlejSR+2KGNgF2++2cAN/1QHsBlUxGXJT1jAkAgATCjDA= From: "Pete Rivett" To: "Donald Chapin" Cc: , , , "Don Baisley" See inline responses. Let me know if we.ve reached the point of a call being more productive than email on this (and the related .alias. issue I just raised). Unfortunately I have a standing clash with the SBVR RTF call slot at 8 Pacific on Fridays. Cheers, Pete From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: Tuesday, January 17, 2012 7:48 AM To: Pete Rivett Cc: nicolas.f.rouquette@jpl.nasa.gov; andrew@omg.org; sbvr-rtf@omg.org; 'Don Baisley' Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Pete, SBVR.s use of MOF/XMI in SBVR Clause 13 is as a syntax for interchanging SBVR semantics, not MOF or UML semantics (see SBVR Subclause 13.2): The SBVR Vocabulary is mapped to MOF elements that make up the SBVR Metamodel. It should not be construed from this one-way mapping that a MOF class is the same thing as an SBVR concept or that there is any semantic equivalence between MOF and SBVR. SBVR model content is represented in MOF-based SBVR models according to the SBVR Metamodel. MOF-based SBVR models instantiate the SBVR Metamodel, not the UML Metamodel. Another transform would be needed to represent SBVR model content using UML. Both the mapping of the SBVR Vocabulary to MOF and the representation of SBVR model content using MOF are described below, divided using the following headings . When you see an XMI .class. in an SBVR interchange file, based on Clause 13 it has to be read as either an SBVR noun concept or SBVR verb concept one or three or more roles . it does not carry UML/MOF class semantics. This is true for everything in an SBVR interchange file. [PJR] Not quite sure what you mean by .an XMI .class..: do you mean a cmof:Class such as .term. (which is a class in the XMI file we had from you)? If it.s a cmof:Class then by definition CMOF provides the semantics such as the ability to have ownedAttributes, participate in Generalization, Associations etc. and also a set of constraints. And of course to allow serialization via XMI. It.s instances of .term. (i.e. elements of type sbvr:term) that have semantics entirely provided by SBVR and for which I can see examples in 13.6.2 of the SBVR spec. It.s important to maintain the distinction that anything in the cmof: namespace has CMOF semantics and anything in the sbvr: namespace has SBVR semantics. [I.m using .cmof:. here since you used it in the model you submitted: MOF 2.4 actually uses the uml: namespace prefix (except for Tags) since it re-uses UML for metamodel structure] In summary, to use what I think is your terminology, the SBVR Metamodel uses MOF semantics, MOF-based SBVR models use SBVR semantics. The use of the .sameRole MOF Tag. communicates that the SBVR designation represented as an MOF/XMI attribute of a given class is in the SBVR attributive namespace of the SBVR subject concept represented by the MOF/XMI class. All the .sameRole MOF Tag. says is that this SBVR designation is one designation of the SBVR verb concept role represented as the association end referenced in the .sameRole MOF Tag. (see SBVR Subclauses 8.3.5 and 13.2.5). This capability is an important part of the SBVR semantics. [PJR] But the current use of MOF tags, with no information on the tag, is not the way to achieve such a relationship as I.ve explained in response to Don B. [PJR] Through this use of MOF Tags you.re trying to represent a rich SVBR concept not at the SBVR level but at the MOF level. You are in effect attempting to add a new capability to MOF but without anything that is interpretable by MOF. If .same role. is .an important part of the SBVR semantics. as you say, why not represent it in the SBVR metamodel so that the relationships can be properly and specifically represented in XMI and the XSD schema? Would you use a MOF Tag to represent the relationship between an SBVR term and its signifier text? As a comparison, ODM has a very similar notion of .equivalentProperty. in the ODM metamodel itself and does not try to ineffectively graft the notion onto MOF. Conversely how would you do the same thing in a specific vocabulary such as that in Section 13.6.2 to allow the representation of distinct (but related) representations of .company appoints officer. and .company appointed officers are. (the latter representing the complete set)? Since MOF tags are not available I presume there is a SBVR specific representation. Don has answered the technical questions about SBVR.s use of MOF and XMI much better than I could as he was part of it original development when he worked at Unisys. [PJR] I replied separately to that. It seems to come down to an issue of rework. You raised a point about the SBVR v1.1 specification referencing MOF 2.0. This wording fix was an oversight as we decided to use MOF/XMI 2.4.1 to support the resolution of Issue 10577 because XMI 2.4.1 XML Schema production rules support omitting abstract classes from the XML Schema. We will change the reference from MOF 2.0 to MOF 2.4.1. Marking some classes as abstract is fundamental to the resolution of Issue 10577 (attached; raised in 2007 and accepted in SBVR v1.1 Ballot 6) which clarified the distinction between: · those SBVR concepts defined just to support unambiguous human discourse on the subject of SBVR business vocabularies and business rules but have no SBVR content in an SBVR interchange file (these are marked as abstract), and · those SBVR concepts for which SBVR business vocabulary, and optionally business rules, content will be interchanged in SBVR interchange files which are files that use the SBVR XSD. Therefore the use of MOF/XMI 2.4.1 is absolutely essential to SBVR v1.1. It would be ideal if MOF fully supported SBVR semantics, but currently it does not. [PJR] XMI now seems to include what SBVR needs: the ability to use serialization of links for class-owned attributes (13.2.4 states . The ends are owned by the association so that individual links can be serialized using XMI..). SBVR.s use of MOF tag fits what the MOF/XMI 2.4.1 specification says - as I explained in an earlier email and Don reinforced. [PJR] And I responded to in disagreement The question is whether or not SBVR complies with the wording of the XMI 2.4.1 specification as it stands - not whether SBVR complies with an interpretation of the XMI 2.4.1 specification that adds more than the specification says or with an implementation of the XMI 2.4.1 specification in somebody's tool. [PJR] I agree, though we need to look not only at the XMI spec but the MOF spec which is the basis of defining XMI, and the UML spec which is the basis of defining MOF. For example it.s the MOF spec that defines MOF Tags and I have used quotes from that as the basis of my comments. Likewise (for the new issue of aliases) I quoted not only from the specification but checked my reading of it with the UML team. Donald From: Don Baisley [mailto:donbaisley@live.com] Sent: 16 January 2012 19:25 To: Pete Rivett; Donald Chapin Cc: nicolas.f.rouquette@jpl.nasa.gov; andrew@omg.org; sbvr-rtf@omg.org Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Hi Pete, We would all like MOF and XMI to more directly support SBVR's metamodel. Particularly, we would all like each binary verb concept to show up as a single association in MOF. 1. Serialization of individual links has open world semantics (implying that the extension might be incompletely represented in the document). 2. Serialization of a property's values with respect to an object has closed world semantics for that property of that object (the extension is completely represented). It is good that XMI 2.4 allows serialization of association links regardless of whether ends are owned by classes. However, that is not enough to allow ownership of SBVR's assocation ends to transfer to SBVR's classes. The ownership of SBVR's association ends correctly matches the namespace requirements. Transferring the ownership of all ends to classes will cause name conflicts. Regarding your point about use of tags, I find that the meaning of a tag is up to whoever defines it. Tags are for extensibility. SBVR uses the "org.omg.sbvr.sameRole" tag to represent a certain piece of inforation about a group of elements -- that they are mutually related -- they represent the same role. That is a perfectly legitimate us of a tag. It would be nice for MOF and XMI to make that tag unnecessary. Example (from SBVR 13.2.5): Verb concept: thing is in set There is a binary association called "thing is in set" with two ends, "thing" and "set". Also, in the "set" class, there is an "element" property, which is effectively a redefinition of the "thing" end of the "thing is in set" association. We use the "org.omg.sbvr.sameRole" tag to relate set.element to the "thing" end of the association "thing is in set". We could remove that tag if we could use MOF's "redefinedProperty" to show the relationship. "set.element" redefines the "thing" end of the association called "thing is in set". But UML infrastructure constraints prevent that sort of redefinition. The other change that has been suggested, moving ownership of association ends to classes, will require major rework and will not be completed anytime soon. It will required inventing and documenting new generation patterns for the MOF and the XML. It requires redoing some complicated diagrams and reworking many examples. It is a large change that will require a lot of rework and testing. Since some problems need fixing in MOF/XMI anyway, it would be best for MOF to support a class-owned property being able to redefine an association end that is owned by an association. Or MOF could provide some other means in a metamodel to indicate that an association end owned by an association is visible as a property in a class. This is a normal thing in information modeling (not program modeling). That way, the name scoping remains correct and what people see in model diagrams will match what is in MOF and XMI. In the meantime, the "org.omg.sbvr.sameRole" tag does the job. Perhaps MOF/XMI will provide a means for removing the tags in SBVR 1.2. Best regards, Don -------------------------------------------------------------------------------- Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Fri, 13 Jan 2012 17:51:16 -0800 From: pete.rivett@adaptive.com To: Donald.Chapin@BusinessSemantics.com CC: donbaisley@live.com; nicolas.f.rouquette@jpl.nasa.gov; andrew@omg.org; sbvr-rtf@omg.org (Before getting bogged down in the point at the start of the email I suggest readers peek ahead to **) To the technical issue, my concern is about use of the link from Element to Tag to represent a relationship between the Elements. That.s like saying in UML that 2 elements can be related by applying the same stereotype to them! As per the MOF spec, .A Tag represents a single piece of information that can be associated with any number of model elements. . In this case there is no information since the .value. property is empty on all of these. Furthermore there is nothing whatsoever in MOF semantics to support the critical aspect of .same role. . which is that any update to the class-owned property is reflected when reading the association-owned property and vice-versa. As far as MOF is concerned they are 2 entirely independent properties with no relationship to each other. To achieve what I think you wanted the properties would need to be both derived (from each other) and updateable (with update logic to update the other property). The SBVR spec says nothing about this. Just because this was present in SBVR 1.0 does not make it right. Hence this new urgent issue . which affects the formal publishing of a correct SBVR 1.1 so that the same problems are not carried forward. ** The good news is that I believe that the above, and the points in your email, are moot. I did some digging back to 2007 and came across the attached email conversation between myself and Don back in 2007. It seems that the driver for use of both attributes and association ends was the restriction in XMI that did not allow serialization of Association instances when one/both ends were owned by a Class. The big news is that the solution did not need to .wait for SMOF. since XMI 2.4 added that capability (as resolution to issue 9695). Hence it is sufficient in SBVR to have all ends owned by classes and that gives the option of serializing as attributes or associations on a case-by-case basis to represent the open/closed semantics required. So there is no need to have both attributes and association ends with the clunky and suspect use of Tags to link them (with no reconciliation of updates between them). Regards Pete PS while reading through the SBVR 1.1 spec I noticed frequent mention to .MOF 2.0. (you.re using .MOF 2.4.1. . I suggest just using .MOF 2.) and examples of XMI (e.g. in 13.6) that do not comply with the XMI 2.4.1 rules: specifically that every XML element (except those that have an href or an xmi:idref) have an xmi:type attribute. This is not part of the urgent issue but just thought I.d mention it. From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: Friday, January 13, 2012 4:28 AM To: Pete Rivett; sbvr-rtf@omg.org Cc: Andrew Watson; nicolas.f.rouquette@jpl.nasa.gov Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Pete, I.ve have responded to your points in-line below. I have shown below how SBVR complies with the relevant OMG specifications. I have also shown that the three places, where the mechanics of the SBVR XMI file I produced for the Santa Clara meet were not exactly correct, can and will be easily fixed next week with a revised SBVR v1.1 XMI file. There is nothing to be fixed in SBVR.s use of the UML 2.4.1 and XMI 2.4.1 specifications, so this Issue has a .No Change. disposition. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 09 January 2012 21:39 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Subject: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Thu, 15 Dec 2011 16:50:43 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: Acy7jLlYRtB6JAE9TPq9DhbQaHkB0Q== From: "Pete Rivett" To: , Cc: , Section 13.2.5 is based on a misunderstanding and misuse of MOF: a) the phrase .In each case where an attribute and an association end represent the same role, the SBVR Metamodel includes a tag that tags both the attribute and the association end. . is in ignorance of the fact that in MOF2 and UML 2 that .attributes. and .association ends. are both represented as instances of Property: and in such a case there would be a single instance of Property linked to the Class using the attribute meta-property and from the Association by the memberEnd (or ownedEnd) property: eliminating the need to link two separate elements. First, this is about who owns the Association End. MOF supports two options for ownership of the Association End: and the Association and the Class. SBVR Clause 13 used the Association ownership of the Association End to support open world semantics (see SBVR Clause 13.3.2). This Association ownership of the Association Ends use of MOF is exactly as it was in SBVR v1.0. Secondly, the problem we had in December with the .sameRole TAG. coming through as a stereotype which MOF does not support is a directly result of my being told to implement the .sameRole Tag. that way by Nicolas. I should have been told to use your MOF Profile to create MOF Tags. I will get that from Nicolas an produce both kinds of MOF Tags correctly. Third, the use of the .sameRole Tag. is necessary to interchange some SBVR linguistic semantics (attributive namespaces) that are not part of UML or MOF (see SBVR Clause 13.2.5). The bottom line on this particular point is that, once I have generated MOF Tags correctly using your MOF Profile, there is nothing wrong with the SBVR specification or the XMI file that I am generating. b) attempting to use MOF Tags to link two properties. In fact MOF Tags are .Simple string name-value pairs.. Yes, that is part of the story. It is also true that in the XMI 2.4.1 specification MOF Tags and have 0..* elements which are each specified by an XMI:id. SBVR uses two elements in MOF .sameRole Tags., each specified by an XMI:id (even though at first glance they look like qualified names). This is exactly what the SBVR v1.0 XMI file (attached) did. In this attached SBVR v1.0 XMI file you will be that each element of a MOF Tag is defined as an XMI:id. It is exactly what I tried to do for the SBVR v1.1. Since I did not at the time know of the existence of a MOF Profile and was not given it while I was in Santa Clara, I was not able to produce the MOF Tags correctly. I will do this correctly next week as well. On this particular point there is no problem of SBVR.s use of the XMI 2.4.1 specification. This is an urgent issue since it affects the production of the SBVR 1.1 artifacts: there is in fact no need for the tags that have caused some of the difficulties producing the machine-readable files: even the file I sent today for the metamodel, which uses the Tag value property does not match this section of the spec which states that value is the empty string. The problem of .value. not being am empty string has to do with the way Magic Draw exports XMI. I will find a work around and produce an XMI file with the MOF Tag values properly empty. So there is not SBVR specification Issue on this particular point. Pete Best regards, -Juergen Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org --Forwarded Message Attachment-- Subject: RE: SBVR XSDs Needed Date: Tue, 11 Sep 2007 04:40:09 -0800 From: pete.rivett@adaptive.com To: Donald.Baisley@unisys.com CC: Donald.Chapin@btinternet.com Hi Don, See below. To summarize the current status of my 4 points: 1. I think you're agreeing to fix, though I have already done so in the CMOF and XSD I sent you. 2. Is the only one outstanding. Where I think the solution is to have 2 sets of files. The CMOF and XSD I sent represent one set: the other would import this metamodel and apply the aliases. 3. The CMOF and XSD I sent already does what you need - as I understand your requirement 4. I just noticed that elementImports are not NamedElements so cannot be named or aliased in any case. So my removal of aliases for elementImports is correct Pete -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: Friday, September 07, 2007 8:13 PM To: Pete Rivett Cc: Donald.Chapin@btinternet.com Subject: RE: SBVR XSDs Needed Hi Pete, 1. Since Namespace.ownedMember is derived (Figure 9.38 in formal/05-07-05), Package.ownedMember which redefines it is necessarily derived according to the definition of .isConsistentWith.. Figure 12.4 in formal/06-01-01 and Figure 10.5 in formal/05-07-05 do not show ownedType as derived . so ownedType appears to not be derived for EMOF. But ownedType is derived in Constructs, so that makes it derived in CMOF (necessitated by .isConsistentWith.). The end result is that both ownedMember and ownedType are derived in CMOF. Is this the bug you were talking about?[Pete Rivett] the bug was that the non-derived Package::ownedMember redefined the derived Namespace::ownedmember. The fix was that in UML 2.1 the former has been replaced by Package::packagedElement. So even then ownedType is still derived and not serialized. Does this mean that EMOF XMI documents cannot be read as CMOF XMI? Is EMOF not a subset for purposes of interchange?. Is it just different? That is bad news. It would be best if ownedMember and ownedType both have XMI tags making them writeable. ownedType is one of the cases where a property becomes derived at a higher level of UML. Another is that at LM Class::general is not derived but it is at L1. For such cases importers of a 'lower' level need to apply the derivatino semantic- in the former case to set packagedElement/ownedMember and in the latter to create a Generalization element. Based on your request, I will change the use of ownedType to ownedMember in the SBVR Metamodel XML. This XML change requires no change to the SBVR specification. 2. When a class has a name in a package and also an alias in the same package, then there are two ways to refer to the one class in the package. Both are perfectly valid. Both names are in the namespace for the one class. [Pete Rivett] OK I see what you're trying to achieve now, though looking at the spec that's not strictly speaking the description of alias - quoting from formal 5/7/5 (my emphasis) "Specifies the name that should be added to the namespace of the importing Package in lieu of the name of the imported PackagableElement." For writing XML, it means that either name can be used . both mean the same thing. In a MOF repository, there is just one class, so when reading XML, finding either name puts something in the same class. When writing XML from a repository, use either name, not both.[Pete Rivett] would you expect a single file to use the same anme consistently for a single class? We use aliases for synonyms in order to keep the SBVR XMI in sync with the SBVR vocabulary. We discussed this at the end of last year. If your MOF tooling cannot handle generating an XSD for a metamodel that has element imports, then I can generate the XSD when I generate the metamodel XML.[Pete Rivett] it would make the XSD even less useful for validation - since one could not readily specify that only one of the 2 names should be used. Our tooling cannot generate such an XSD. If you can then do you need me to do anythign else? You are correct that the XMI 2.1 Specification does not talk about element imports or their aliases. It also does not talk about ownedMember, ownedType or a lot of specific things. But one would assume that XMI works for element imports as it does for owned elements.[Pete Rivett] The point is that it does not address the possibility of using 2 different XML element names for the same metamodel element. And even the MOF/Infra spec states that the alias is for use instead of the original name (see above) An attempt to change how this works now would be problematic at this late point in time.[Pete Rivett] Maybe there could be 2 separate XSD/XMI files for the different purposes based on what you hinted at with respect to imports into a 'dummy' package. 3. The rationale for using attributes in addition to associations is explained in greater detail in 13.3.2. The brief explanation you mentioned points to 13.3.2. SBVR.s metamodel needs this workaround until SMOF comes along and provides another means by which an XMI document can distinguish the open and closed cases. I discussed this workaround with you before proposing it as a way to have a more typical MOF metamodel for SBVR. Without this workaround, SBVR would need to stay with the previous RDF-like use of MOF, which some OMG folks did not like. Note that SBVR.s metamodel is aimed at supporting XMI interchange. If a repository has other means of handling open/closed, then the repository model can be transformed to take advantage of those means. But SBVR.s metamodel must support an XMI interchange capability that handles the distinction. [Pete Rivett] The correction I proposed, with the attribute linked to the association, and XSD I generated, does allow XMI interchange expression of relationships either as attributes or Association instances (links)! It presumes that we relax the current formal XMI restriction (in the spec but not our implementation) that Association instances may only be interchanged if the Association owns both of its ends - but that is a minor change/hassle compared to havign the attributes and ends completely unrelated As you explained to me months ago, if a MOF class owns an attribute that is the end of some association, then the XMI documents don.t get to use individual links of that association. So we use our workaround until SMOF gives us a better way. Best regards, Don -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, September 06, 2007 5:32 PM To: Donald.Chapin@btinternet.com Cc: Baisley, Donald E Subject: RE: SBVR XSDs Needed I've been with a customer in Germany the last 3 days with little email access (or time to read them!). I will be on a con call for about 7 hours tomorrow starting 9am EDT so will not be available. Responses in maroon. I did not make the changes I did lightly (and they did take a fair amount of time and energy). Without them I could not have used our technology to generate the schema (with the possible exception of issue 3). Pete -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: Thursday, September 06, 2007 12:25 PM To: Pete Rivett Cc: 'Baisley, Donald E' Subject: FW: SBVR XSDs Needed Importance: High Hi Pete, Do I need to arrange a telecon for you, Don and me; or can you answer Don.s questions without needing to talk with him? I.m concerned that Don may need to produce a revised XMI file that doesn.t need to be tweaked so that the XMI and XSD files are in synch and agree with SBVR Clause 13 . and time is passing. Thanks, Donald -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: 04 September 2007 20:58 To: Pete Rivett Cc: Donald.Chapin@btinternet.com Subject: RE: SBVR XSDs Needed Hi Pete, Please see comments in blue below. Don -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Sunday, September 02, 2007 5:27 PM To: Baisley, Donald E Cc: Donald.Chapin@btinternet.com Subject: RE: SBVR XSDs Needed Importance: High I've just looked at SBVR.xml as per Don's voicemail. It has the following problems: 1) ownedType is incorrectly used instead of ownedMember (ownedType is derived and hence not serialized). This was a simple edit to fix via global edit. Where in Infrastructure 2.0 or MOF 2.0 is it documented that ownedType is derived? I am looking at formal/05-07-05 and formal/06-01-01. MOF 2.0 says .Namespace::ownedMember (Note that this is abstract, so appropriate specializations must be used.).. [Pete Rivett] Figure 11.26 of formal/5-7-5. Now namespace::ownedMember is derived (hence the quote in the MOF 2.0 spec) but Package::ownedMember is not. This was a bug and package::packagedMember was introduced instead (though at UML 2.1 which does not apply to MOF 2.0). However if you look at the later UML specs you can see that ownedType has always been shown as derived. And if you look at the UML metamodel itself, it uses ownedMember. 2) elementImport is used for elements in the same package (it is only valid for elements in a differetn package). SBVR uses elementImport for aliasing (based on synonyms in the SBVR vocabulary) . one model element can have two names. The only clue I can find in the Infrastructure 2.0 or MOF 2.0 specifications about importing being from a .different. package is that the introduction to ElementImport uses the word .another. in a general statement that makes no claim to being a limitation. There is no constraint that prevents importing from the same package. I discussed this with you at the end of last year when deciding to take SBVR.s new approach to using MOF. [Pete Rivett] What I'm having a problem with is the formal meaning of such an alias. It's clearer when from a different package - the alias overrides the other name. Though the application of this is generally only for 'programming language' or maybe OCL expressions. The XMI spec says nothing about such aliases. It gets worse if the alias is in the same package: what would you expect to happen? To completely replace the original name (I think not since you want 2 names)? For example in XMI which is the current topic, when exporting would you expect the same instance to be exported twice as two XML elements with different XML element names? It was really the lack of reference to aliases in XMI and lack of ability to answer these questions that led me to delete them. If importing from that same Package is not going to be supported, then I suppose I will have to import twice to get the desired result. I can do a package import of everything into a dummy package and then do element imports from there. [Pete Rivett] Hmm still not sure what effect you're trying to achieve. It's not clear what effect you're tryign to achieve with elementImports - to take an example we have: which is followed by: which I assume is intended to renam it to behavioral business rule. However later on we have the following which, as far as the XSD and XMI interchange is concerned, puts the first word back from 'behavioral' to 'operative'. So I ignored the elementImports. [Pete Rivett] You did not respond what you were trying to achieve. 3) There are many cases where an association end is owned by a class, but the end is not properly tied up with the association. I see there is a tag, org.omg.sbvr.sameRole, very briefly mentioned (but not justified) in section 13.2.5 of the SBVR spec. MOF has no functionality for recognizing this tag; and already has functionality for linking 'attributes' to association roles so don't see why it's needed. Attributes are used for complete extensions and links are used with an open world assumption. [Pete Rivett] OK I remember the issue now - would be useful to explain this in 13.2.5 of SBVR. However I don't necessarily agree with the resolution in terms of a MOF implementation. I guess I missed this when balloted - what Issue number was it? MOF does not need to handle this at this time. SMOF will hopefully support open/closed without the need for the work-around. The XSD generation can ignore these .sameRole. tags. The XSD must keep them separate, as in the metamodel. For example: Should be tied up in MOF with the Association element: However the association does not reference the end owned by the class, nor vice versa. What I think you should have is the following, changes in olive: I wrote XSL to fix up this based on the sbvr tags. Without that, no MOF repository is going to be able to maintain the attribute and the association in synch. No MOF repository should be expected to keep these in synch until SMOF comes along with a solution. [Pete Rivett] Not keeping them in synch seems crazy and wrong - and not what a repository should be about. For now, software that uses a MOF repository for SBVR can use the tags to know what is going on.[Pete Rivett] Which is what I did by doing the substitution/deletion. No MOF repository can be expected to know about the tags. 4) There is an xmiName tag applied to a few elementImports which is pointless since the names of the imports themselves are never made use of. For example: Since I was filtering out the elementImports I wrote some more XSL to remove these. These need to stay, along with the element imports. [Pete Rivett] What use would you expect the name for an import element (as opposed to the alias it introduces) to have. As naming it seems pointless (except possible for management purposes) then renaming it seems more so. Attached is the fixed CMOF metamodel and the XSD. Also the XSL file I used to make the fixes. I lost track of the URI you agreed to use so you may want to adjust that in the header. This UR (and the ns prefix) should also be recorded in the metamodel as XMI Tags. Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Hello House, 135 Somerford Road, Christchurch, BH23 3PY, UK Tel: +44 (0)1202 491243 Fax: +44 (0)1202 491241 http://www.adaptive.com -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: Friday, August 24, 2007 2:25 AM To: Pete Rivett Cc: Donald.Chapin@btinternet.com Subject: SBVR XSDs Needed Hi Pete, Can you please create XSDs for each of the attached files (which I just sent to the SBVR-FTF mailing list)? Each file gives a package that is already .merged.. Please send the files to the SBVR-FTF mailing list. Also, please let me know if you find errors in the files. Gene Mutschler was able to load them with his CMOF tool. Thanks, Don From: "Barkmeyer, Edward J" To: Pete Rivett CC: "sbvr-rtf@omg.org" Date: Sat, 21 Jan 2012 20:25:20 -0500 Subject: RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Topic: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: AQJKt/vhqpiJyZT42GQlejSR+2KGNgF2++2cAN/1QHsBlUxGXJT1jAkAgATCjDCAAhkPgw== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US I would like to add a different insight into this problem (and confuse everyone). I think SBVR Clause 13 confuses two ideas with respect to MOF. A MOF metamodel is a model of a language, or perhaps a family of languages, that depicts the language concepts as MOF classes and associations. The elements of a MOF metamodel have their MOF semantics as "model elements", but they have their target language semantics as "metamodel elements". MOF distinguishes levels of models: A model of the language is a "metamodel" at the M2 level. Every M2 metamodel has only MOF semantics. A model made in the language, such as an SBVR Vocabulary, is an M1 model. Its MOF representation is a population of the M2 schema for the language. From a MOF point of view, every actual statement in the language is just an M1 instance of some class in the M2 metamodel. But the semantics of the statement is then the semantics of the language element that is represented by that class. For example, the BPMN concept "Task" in the BPMN metamodel (M2) is an instance of the MOF concept "class". The MOF model element can have attributes and generalizations, participate in associations and own association ends. It cannot 'be part of a process' or 'have an expansion'. An instance of the BPMN concept "Task" in a BPMN model is a BPMN language element (M1). It can be part of a process and have an expansion. The instance of Task has the properties of a Task in the BPMN language. In a similar way, the SBVR metamodel is a MOF model of SBVR at the M2 level. It is made up of MOF classes and associations, etc., and they have the MOF semantics for association ends and generalizations, etc. The elements of the SBVR metamodel, as elements of a MOF model, do not have the SBVR semantics. MOF model elements do not have synonyms, and MOF assumes that the model is a closed world in every regard -- that the model is exactly what it contains and nothing more. As an element of the SBVR metamodel, for example, 'state of affairs' is not a noun concept, it is a MOF class that specializes the MOF class 'thing'. OTOH, an SBVR Vocabulary, such as Date/Time is a MOF M1 model. It is a population of the SBVR metamodel. The Date/Time Vocabulary does not have any instance of MOF 'class'; it has instances of 'noun concept' and 'verb concept', etc. Those model elements have synonyms and embody the Open World Assumption. As written, SBVR Clause 13 is the directions for turning the formulation of the SBVR Vocabularies that are clauses 8,9,11 and 12 into a MOF metamodel for SBVR. Why write these rules? Why not just write down the MOF metamodel that is derived from those clauses? Don't tell us how to make the MOF metamodel of the SBVR concepts. Do it and write it down! And yes, since MOF doesn't have several of the SBVR concepts and features, the M2 SBVR metamodel will not be as rich as the SBVR Vocabularies, but it will provide MOF classes and associations for ALL of the SBVR concepts, all of the concepts needed to capture M1 Business vocabularies with all the richness of the SBVR concept set. The Business vocabularies will ONLY instantiate SBVR concepts. It seems that the authors thought that someone would also want to turn an arbitrary SBVR Vocabulary, other than the Vocabularies in the SBVR specification, into a MOF metamodel as well. WHATEVER FOR? Why would anyone want to turn a business vocabulary into a MOF model? There was no RFP requirement for anything the like, and I can think of no SBVR usage scenario that would want to do that. Further, if someone did want to turn his business vocabulary into a MOF metamodel, wouldn't he want to use the MOF concepts closest to the semantics of his vocabulary elements? All we want to do with our business vocabularies is populate the SBVR MOF model with an M1 population that is the business concepts as instances of SBVR concepts. Date/Time, for example, is an SBVR vocabulary, and a UML model, and a CLIF ontology, and (hopefully) an OWL ontology. NONE of those is a MOF metamodel. There is no Date/Time MOF metamodel. Date/Time has no use whatsoever for the mapping guidance in Clause 13. It is formally represented as a /population/ of the SBVR MOF metamodel, and it has a corresponding XML representation using the schemas in Clause 15. Now, the SBVR Vocabularies defined in clauses 8, 11 and 12 are ALSO intended to be used as SBVR business vocabularies that can be adopted by other business vocabularies. This is where the confusion arose. Those vocabularies are thus also intended to be M1 /populations/ of the SBVR metamodel, and instances of the SBVR concepts. That is, they are, to be represented, like the as XML documents that are instances of the XML schemas in Clause 15. As populations of the SBVR metamodel, the vocabulary elements have the SBVR semantics. They are noun concepts and verb concepts and roles and have synonymous forms, and they have the open world assumption. So, clause 13 need not specify HOW the MOF metamodel of SBVR is derived; that is just design rationale. What it needs to specify is the result -- the formal MOF elements that represent the SBVR concepts in clauses 8-12, and nothing more. The only thing this model will be used for is the capture and serialization of business vocabularies as instances of the SBVR metamodel. In effect, it defines only the XMI/XML tags. The SBVR Vocabularies in clauses 8-12 are then specified as M1 populations of that model, largely as described in Clause 15 and Annex C, with all the richness and semantics of the SBVR concepts they instantiate. These two ideas need to be sorted out. Once we do that, all the arguments about the rationale for the misuse of MOF disappear. The MOF metamodel of SBVR must be a valid MOF model; it need not try to carry more semantics than the representations of the SBVR concepts with suitable MOF elements. The MOF elements are just expressions in the MOF language that represent the SBVR concepts. MOF 'class' will never have SBVR 'noun concept' semantics, but the MOF metaclass 'noun concept' (an instance of MOF 'class') will have exactly the SBVR 'noun concept' semantics. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Office: +1 301-975-3528 Gaithersburg, MD 20899-8263 Mobile: +1 240-672-5800 ________________________________________ From: "Donald Chapin" To: Subject: {SBVR 1.1 RTF] -- issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Thu, 26 Jan 2012 22:48:30 -0000 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczcfJ/lOC87eriXRo2sRoHX4K+/ZQ== X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4F21D842.0076, actions=TAG X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2012.1.26.215714:17:9.975, ip=81.149.51.65, rules=__TO_MALFORMED_2, __TO_NO_NAME, __FRAUD_SUBJ_A, __PHISH_SPEAR_SUBJECT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, DOC_ATTACHED, __ANY_URI, LINK_TO_IMAGE, __FRAUD_BODY_WEBMAIL, __FRAUD_CONTACT_NUM, ECARD_KNOWN_DOMAINS, __CP_URI_IN_BODY, __C230066_P5, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __IMGSPAM_BODY, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_50_70, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, FORGED_MUA_OUTLOOK, IMGSPAM_BODY X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0208.4F21D843.011A,ss=1,re=0.000,vtr=str,vl=0,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Attached is an updated SBVR 1.1 RTF resolution to Issue 16913 as agreed by Pete Rivett and Don Baisley in a telephone conversation yesterday. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 09 January 2012 21:39 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Subject: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Thu, 15 Dec 2011 16:50:43 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: Acy7jLlYRtB6JAE9TPq9DhbQaHkB0Q== From: "Pete Rivett" To: , Cc: , Section 13.2.5 is based on a misunderstanding and misuse of MOF: a) the phrase .In each case where an attribute and an association end represent the same role, the SBVR Metamodel includes a tag that tags both the attribute and the association end. . is in ignorance of the fact that in MOF2 and UML 2 that .attributes. and .association ends. are both represented as instances of Property: and in such a case there would be a single instance of Property linked to the Class using the attribute meta-property and from the Association by the memberEnd (or ownedEnd) property: eliminating the need to link two separate elements. b) attempting to use MOF Tags to link two properties. In fact MOF Tags are .Simple string name-value pairs.. This is an urgent issue since it affects the production of the SBVR 1.1 artifacts: there is in fact no need for the tags that have caused some of the difficulties producing the machine-readable files: even the file I sent today for the metamodel, which uses the Tag value property does not match this section of the spec which states that value is the empty string. Pete Best regards, -Juergen Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org Issue 16913 - ''org.omg.sbvr.sameRole' Use of MOF Tag (2012-01-26).doc From: "Donald Chapin" To: Subject: [SBVR 1.1 RTF] -- RE: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Fri, 27 Jan 2012 10:57:51 -0000 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Aczc4oNSiOp+478PSfqUK80BV0zfvw== X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4F228333.006F, actions=tag X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2012.1.27.101516:17:9.975, ip=81.149.51.65, rules=__TO_MALFORMED_2, __TO_NO_NAME, __FRAUD_SUBJ_A, __PHISH_SPEAR_SUBJECT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, DOC_ATTACHED, __ANY_URI, LINK_TO_IMAGE, __FRAUD_BODY_WEBMAIL, __FRAUD_CONTACT_NUM, ECARD_KNOWN_DOMAINS, __CP_URI_IN_BODY, __C230066_P5, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __IMGSPAM_BODY, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_50_70, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, FORGED_MUA_OUTLOOK, IMGSPAM_BODY X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020C.4F228335.00EC,ss=1,re=0.000,vtr=str,vl=0,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Attached is an updated resolution of Issue 16913 for the SBVR 1.1 RTF that contains some wording fixes that I just received from Don Baisley. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 09 January 2012 21:39 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 16913 -- Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Subject: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Date: Thu, 15 Dec 2011 16:50:43 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Urgent issue on SBVR 1.1 RTF (NOT SBVR 1.2) Thread-Index: Acy7jLlYRtB6JAE9TPq9DhbQaHkB0Q== From: "Pete Rivett" To: , Cc: , Section 13.2.5 is based on a misunderstanding and misuse of MOF: a) the phrase .In each case where an attribute and an association end represent the same role, the SBVR Metamodel includes a tag that tags both the attribute and the association end. . is in ignorance of the fact that in MOF2 and UML 2 that .attributes. and .association ends. are both represented as instances of Property: and in such a case there would be a single instance of Property linked to the Class using the attribute meta-property and from the Association by the memberEnd (or ownedEnd) property: eliminating the need to link two separate elements. b) attempting to use MOF Tags to link two properties. In fact MOF Tags are .Simple string name-value pairs.. This is an urgent issue since it affects the production of the SBVR 1.1 artifacts: there is in fact no need for the tags that have caused some of the difficulties producing the machine-readable files: even the file I sent today for the metamodel, which uses the Tag value property does not match this section of the spec which states that value is the empty string. Pete Best regards, -Juergen Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org Issue 16913 - ''org.omg.sbvr.sameRole' Use of MOF Tag (2012-01-27).doc