Issue 17017: SBVR makes use of ElementImports to give additional aliases to some elements in the same package (sbvr-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Revision Severity: Critical Summary: SBVR makes use of ElementImports to give additional 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 my understanding with the UML team that “another” does mean literally that (confirmed by OCL elsewhere in the spec) and it cannot be interpreted to mean “the same package”. Even were the ElementImport to be permitted, it would not have the intended meaning which I believe is to add additional synonyms to elements. In contrast the alias in an ElementImport “Specifies the name that should be added to the namespace of the importing Package *in lieu of* the name of the imported PackagableElement.” This issue is urgent since it affects the production of correct normative artifacts for SBVR 1.1. Resolution: Revised Text: Actions taken: January 20, 2012: received issue Discussion: End of Annotations:===== ubject: Urgent issue on SBVR 1.1 RTF From: "Pete Rivett" To: , Cc: , SBVR makes use of ElementImports to give additional 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 my understanding with the UML team that .another. does mean literally that (confirmed by OCL elsewhere in the spec) and it cannot be interpreted to mean .the same package.. Even were the ElementImport to be permitted, it would not have the intended meaning which I believe is to add additional synonyms to elements. In contrast the alias in an ElementImport .Specifies the name that should be added to the namespace of the importing Package *in lieu of* the name of the imported PackagableElement.. This issue is urgent since it affects the production of correct normative artifacts for SBVR 1.1. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp Date: Mon, 30 Jan 2012 17:21:28 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Donald Chapin CC: sbvr-rtf Subject: Re: [SBVR 1.1 RTF] -- VOTE - SPECIAL Ballot 9 - Issue Disposition - DEADLINE Monday, February 6, 2012 ( 1 WEEK) -- Special SBVR 1.1 RTF Ballot X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: q0UMLXom015819 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1328566895.99122@a8XspZ9iypHWifzIltLVDg X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov I do not vote in RTF 1.1. I do think this is a good solution. Problem: The Revised Text of 17017 makes no mention of clause 13.2.2. In clause 13.2.2, the first paragraph contains the sentence: "The signifier of each synonym of the designation is an alias for the class." Nothing is said in 13.2.2 about how to encode the "alias", but the diagram in 13.2.2 shows an "element import". The revised text does not, but should, delete this drawing element as well. Further, under the Rationale subhead in 13.2.2, the first sentence reads: "Use of aliasing, though not common in MOF-based metamodels, keeps a strong alignment of the SBVR Metamodel with the SBVR vocabulary." Presumably, that will no longer be the case if the element imports are deleted. I suggest it should rather read: "In general, MOF does not provide a mechanism for declaring synonyms. Therefore, the Synonym elements of the SBVR vocabularies do not have counterparts in the SBVR MOF metamodel. They are, however, captured in SBVR vocabularies that are instances of the SBVR MOF metamodel." I respectfully suggest that you may want to revise the Revised text for 17017 to include changes to 13.2.2 before balloting it. -Ed Donald Chapin wrote: To SBVR *_1.1_* RTF Voting Members ­ Two Issues have arisen about the content of the SBVR Clause 15.1 Metamodel file. This is a special SBVR *_1.1_* RTF ballot is needed to complete the generation of the SBVR Clause 15.2 XSD file. 88solutions Manfred Koethe Adaptive Pete Rivett Business Rule Solutions LLC Ronald Ross Business Semantics Ltd Donald Chapin Deere & Company Duane Clarkson e-Business Management Sect. Davide Storelli Fujitsu Ltd Hiroshi Miyazaki Hewlett-Packard Company Jishnu Mukerji Inferware John Hall International Business Machines Mark Linehan KDM Analytics Nick Mansourov KnowGravity Inc Markus Schacher MEGA International Antoine Lonjon PNA Group Sjir Nijssen Rule ML Initiative John Hall Thematix Partners LLC Elisa Kendall TIBCO Paul Vincent Please vote by reply to SBVR-RTF@omg.org for each of the following recommended SBVR *_1.1_* RTF Issue Dispositions by MONDAY, February 6, 2012 (1 WEEK) -------------------------------------------------------------------- The Issue Dispositions for the Issues listed below are in the attached file, and on the server at (ftp://ftp.omg.org/pub/sbvr-rtf/FilesForVoting/SBVRIssueDispositions-Ballot9.doc) -------------------------------------------------------------------- _.RESOLVED. ISSUES_ Disposition: RESOLVED for Issue 16913 "'org.omg.sbvr.sameRole' Use of .MOF Tag." ____ Yes ____ No ____ Abstain Disposition: RESOLVED for Issue 17017 "elementImports Cannot be from the Same Package" ____ Yes ____ No ____ Abstain Many Thanks, Donald -- 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 From: "Donald Chapin" To: Subject: [SBVR 1.1 RTF] -- RE: issue 17017 -- SBVR RTF issue Date: Thu, 26 Jan 2012 22:53:02 -0000 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczcfUHIpBxB2vpaTqKzAiM/SGUZow== X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4F21D952.0094, actions=TAG X-Junkmail-Premium-Raw: score=15/50, refid=2.7.2:2012.1.26.215714:17:15.447, ip=81.149.51.65, rules=__TO_MALFORMED_2, __TO_NO_NAME, __SUBJ_ALPHA_END, __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, FRAUD_DOC_NAME_FROM, DOC_ATTACHED, __ANY_URI, LINK_TO_IMAGE, __FRAUD_CONTACT_NUM, __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, FORGED_MUA_OUTLOOK, IMGSPAM_BODY X-Junkmail-Status: score=15/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4F21D954.0035,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 the SBVR 1.1 RTF resolution to Issue 17017 as agreed by Pete Rivett and Don Baisley in a telephone conversation yesterday. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 20 January 2012 16:37 To: issues@omg.org; sbvr-rtf@omg.org; uml-spec-simplification@omg.org Subject: issue 17017 -- SBVR RTF issue Importance: High Subject: Urgent issue on SBVR 1.1 RTF Date: Fri, 20 Jan 2012 08:11:13 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Urgent issue on SBVR 1.1 RTF Thread-Index: AczXjh4fLSEM6MibSQiDE9ChB3DFEA== From: "Pete Rivett" To: , Cc: , SBVR makes use of ElementImports to give additional 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 my understanding with the UML team that .another. does mean literally that (confirmed by OCL elsewhere in the spec) and it cannot be interpreted to mean .the same package.. Even were the ElementImport to be permitted, it would not have the intended meaning which I believe is to add additional synonyms to elements. In contrast the alias in an ElementImport .Specifies the name that should be added to the namespace of the importing Package *in lieu of* the name of the imported PackagableElement.. This issue is urgent since it affects the production of correct normative artifacts for SBVR 1.1. -- Pete Rivett (pete.rivett@adaptive.com ) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp 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 17017 - elementImports Cannot be from the Same Package (2012-01-26).doc