Issue 12165: URGENT SBVR.xsd issue (sbvr-rtf)
Source: Chronolytics (Mr. David Carlson, nobody)
Nature: Revision
Severity: Critical
Summary: The final XMI Schema for SBVR serialization is not correct for Associations, as required by the XMI 2.1.1 specification. An implementation that produces a valid XMI serialization will be judged as invalid, according to the SBVR.xsd. This is a critical bug. I have created an SBVR implementation using Eclipse EMF, based on the final SBVR cmof model. An example model serialization from EMF is attached, as test.sbvr. In it, each model element includes an xmi:id attribute. However, the SBVR.xsd does not allow this id on types derived from cmof Association. >From XMI v2.1.1, p. 49, the AssnAtts must include all XMIFixedAttribs 7. AssociationDef ::= "<xsd:element name='"' 7a:AssnElmtName '"'>" "<xsd:complexType> <xsd:choice minOccurs='0' maxOccurs='unbounded'>" 7b:AssnContents "</xsd:choice>" 7d:AssnAtts "</xsd:complexType> </xsd:element>" 7a. AssnElmtName ::= 1c:Namespace //Name of association// 7b. AssnContents ::= 7c:AssnEndDef 7c:AssnEndDef 4c:Extension 7c. AssnEndDef ::= "<xsd:element" "name='" //Name of association end// "'>" "<xsd:complexType>" 1g:XMIFixedAttribs "</xsd:complexType>" "</xsd:element>" 7d. AssnAtts ::= 1g:XMIFixedAttribs And, from p. 44, the XMIFixedAttribs 1g. XMIFixedAttribs ::= ( "<xsd:attribute ref='xmi:id'" "use='optional'>" | "<attribute name='" //Id attrib name// "'" "type='xsd:ID' use='optional'") "<xsd:attributeGroup ref='xmi:ObjectAttribs'/>" 

Resolution: Add the following two lines into the xs:complexType of the SBVR XML schemas for each association of the SBVR metamodel.
    <xs:attribute ref="xmi:id"/>
    <xs:attributeGroup ref="xmi:ObjectAttribs"/>


Revised Text: 
Actions taken:
January 9, 2008: received issue
July 22, 2013: closed issue
Discussion: 

End of Annotations:=====



m: webmaster@omg.org
Date: 09 Jan 2008 12:52:55 -0500
To: <issues@omg.org>
Subject: Issue/Bug Report



--------------------------------------------------------------------------------

Name: Dave Carlson
Company: David Carlson & Associates, Inc.
mailFrom: dcarlson@xmlmodeling.com
Notification: Yes
Specification: SBVR.xsd
Section: 13
FormalNumber: 08-01-06
Version: 1.0
RevisionDate: 08-01-06
Page: 179
Nature: Revision
Severity: Critical
HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Description
The final XMI Schema for SBVR serialization is not correct for Associations, as required by the XMI 2.1.1 specification. An implementation that produces a valid XMI serialization will be judged as invalid, according to the SBVR.xsd. This is a critical bug. I have created an SBVR implementation using Eclipse EMF, based on the final SBVR cmof model. An example model serialization from EMF is attached, as test.sbvr. In it, each model element includes an xmi:id attribute. However, the SBVR.xsd does not allow this id on types derived from cmof Association. >From XMI v2.1.1, p. 49, the AssnAtts must include all XMIFixedAttribs 7. AssociationDef ::= "<xsd:element name='"' 7a:AssnElmtName '"'>" "<xsd:complexType> <xsd:choice minOccurs='0' maxOccurs='unbounded'>" 7b:AssnContents "</xsd:choice>" 7d:AssnAtts "</xsd:complexType> </xsd:element>" 7a. AssnElmtName ::= 1c:Namespace //Name of association// 7b. AssnContents ::= 7c:AssnEndDef 7c:AssnEndDef 4c:Extension 7c. AssnEndDef ::= "<xsd:element" "name='" //Name of association end// "'>" "<xsd:complexType>" 1g:XMIFixedAttribs "</xsd:complexType>" "</xsd:element>" 7d. AssnAtts ::= 1g:XMIFixedAttribs And, from p. 44, the XMIFixedAttribs 1g. XMIFixedAttribs ::= ( "<xsd:attribute ref='xmi:id'" "use='optional'>" | "<attribute name='" //Id attrib name// "'" "type='xsd:ID' use='optional'") "<xsd:attributeGroup ref='xmi:ObjectAttribs'/>" 


From: "Dave Carlson" <dcarlson@xmlmodeling.com>
To: <sbvr-rtf@omg.org>
Cc: <Donald.Baisley@unisys.com>, <dcarlson@xmlmodeling.com>
Subject: Incorrect XMI Schema for associations
Date: Wed, 9 Jan 2008 08:32:45 -0700
X-Mailer: Microsoft Outlook, Build 10.0.6822
Thread-Index: AchS1OG0+7t6UGtNQui0dKZP8qhhkQ==


The final XMI Schema for SBVR serialization is not correct for Associations,
as required by the XMI 2.1.1 specification.  An implementation that produces
a valid XMI serialization will be judged as invalid, according to the
SBVR.xsd.  This is a critical bug.


I have created an SBVR implementation using Eclipse EMF, based on the final
SBVR cmof model.  An example model serialization from EMF is attached, as
test.sbvr.  In it, each model element includes an xmi:id attribute.
However, the SBVR.xsd does not allow this id on types derived from cmof
Association.


>From XMI v2.1.1, p. 49, the AssnAtts must include all XMIFixedAttribs


7. AssociationDef ::= "<xsd:element name='"' 7a:AssnElmtName '"'>"
"<xsd:complexType>
<xsd:choice minOccurs='0' maxOccurs='unbounded'>"
7b:AssnContents
"</xsd:choice>"
7d:AssnAtts
"</xsd:complexType>
</xsd:element>"
7a. AssnElmtName ::= 1c:Namespace //Name of association//
7b. AssnContents ::= 7c:AssnEndDef
7c:AssnEndDef
4c:Extension
7c. AssnEndDef ::= "<xsd:element"
"name='" //Name of association end// "'>"
"<xsd:complexType>"
1g:XMIFixedAttribs
"</xsd:complexType>"
"</xsd:element>"
7d. AssnAtts ::= 1g:XMIFixedAttribs


And, from p. 44, the XMIFixedAttribs


1g. XMIFixedAttribs ::= ( "<xsd:attribute ref='xmi:id'"
"use='optional'>" |
"<attribute name='" //Id attrib name// "'"
"type='xsd:ID' use='optional'")
"<xsd:attributeGroup ref='xmi:ObjectAttribs'/>"



 test.sbvr 

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=btinternet.com;
  h=Received:X-YMail-OSG:Reply-To:From:To:References:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:X-MimeOLE:In-Reply-To:Thread-Index;
  b=YJpKDsOdOJDdfz0V2IUmWle9xdFYBUVkwFrmh0K2JEq1g69Z14eWuifItGzudGCZor5UfkjKBFTTNuoS/EcCi8FCYqvxUz2Xs+H1v2uk+s8kVYCeO/1M+RixOlsm/HlGRIX2JdJO6TKeya8zFPW8HGSl310hnzLKOskAIPseOKQ=  ;
X-YMail-OSG: FxkVawUVM1lgtNzNOWbLzhUkrZAa_V7jGVZiea0aMGvKqrAqrnO6KFgMj3N7dw8TI1xx1rNanA--
Reply-To: <Donald.Chapin@btinternet.com>
From: "Donald Chapin" <Donald.Chapin@btinternet.com>
To: "'Juergen Boldt'" <juergen@omg.org>
Subject: RE: Incorrect XMI Schema for associations
Date: Wed, 9 Jan 2008 16:51:22 -0000
Organization: Business Semantics Ltd
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AchS2/+f4cPo2CjnTlmrAdOnrRNdVwAA0Giw


Juergen,

 

I.ll call Don Baisley as soon as he gets in.  The final file has not been published.  I guess he used the ones from September.

 

I.ll let you know what Don says.

 

Donald

 


--------------------------------------------------------------------------------

From: Juergen Boldt [mailto:juergen@omg.org] 
Sent: 09 January 2008 16:24
To: Donald.Chapin@btinternet.com
Subject: Fwd: Incorrect XMI Schema for associations

 

huh?

-Juergen





From: "Dave Carlson" <dcarlson@xmlmodeling.com>
To: <sbvr-rtf@omg.org>
Cc: <Donald.Baisley@unisys.com>, <dcarlson@xmlmodeling.com>
Subject: Incorrect XMI Schema for associations
Date: Wed, 9 Jan 2008 08:32:45 -0700
X-Mailer: Microsoft Outlook, Build 10.0.6822
Thread-Index: AchS1OG0+7t6UGtNQui0dKZP8qhhkQ==

The final XMI Schema for SBVR serialization is not correct for Associations,
as required by the XMI 2.1.1 specification.  An implementation that produces
a valid XMI serialization will be judged as invalid, according to the
SBVR.xsd.  This is a critical bug.

I have created an SBVR implementation using Eclipse EMF, based on the final
SBVR cmof model.  An example model serialization from EMF is attached, as
test.sbvr.  In it, each model element includes an xmi:id attribute.
However, the SBVR.xsd does not allow this id on types derived from cmof
Association.

>From XMI v2.1.1, p. 49, the AssnAtts must include all XMIFixedAttribs

7. AssociationDef ::= "<xsd:element name='"' 7a:AssnElmtName '"'>"
"<xsd:complexType>
<xsd:choice minOccurs='0' maxOccurs='unbounded'>"
7b:AssnContents
"</xsd:choice>"
7d:AssnAtts
"</xsd:complexType>
</xsd:element>"
7a. AssnElmtName ::= 1c:Namespace //Name of association//
7b. AssnContents ::= 7c:AssnEndDef
7c:AssnEndDef
4c:Extension
7c. AssnEndDef ::= "<xsd:element"
"name='" //Name of association end// "'>"
"<xsd:complexType>"
1g:XMIFixedAttribs
"</xsd:complexType>"
"</xsd:element>"
7d. AssnAtts ::= 1g:XMIFixedAttribs

And, from p. 44, the XMIFixedAttribs

1g. XMIFixedAttribs ::= ( "<xsd:attribute ref='xmi:id'"
"use='optional'>" |
"<attribute name='" //Id attrib name// "'"
"type='xsd:ID' use='optional'")
"<xsd:attributeGroup ref='xmi:ObjectAttribs'/>"


From: "Baisley, Donald E" <Donald.Baisley@unisys.com>
To: "donald.chapin@btinternet.com" <donald.chapin@btinternet.com>
Cc: Pete Rivett <pete.rivett@adaptive.com>, Juergen Boldt <juergen@omg.org>
Date: Wed, 9 Jan 2008 11:00:13 -0600
Subject: FW: Incorrect XMI Schema for associations
Thread-Topic: Incorrect XMI Schema for associations
Thread-Index: AchS1OG0+7t6UGtNQui0dKZP8qhhkQACnrgA
Accept-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
X-OriginalArrivalTime: 09 Jan 2008 17:00:15.0868 (UTC) FILETIME=[1B44EBC0:01C852E1]


Hi Donald,


The XMI XSD pattern for associations, as Dave points out, is supposed to allow for xmi:id on links.  Dave Carlson's test case found the problem.  I can send an updated XSD by tomorrow if you want to post a correct XSD.  It is a simple XMI-related editing fix that has nothing to do with the SBVR content.


Please let me know.


Thanks,
Don




-----Original Message-----
From: Dave Carlson [mailto:dcarlson@xmlmodeling.com]
Sent: Wednesday, January 09, 2008 7:33 AM
To: sbvr-rtf@omg.org
Cc: Baisley, Donald E; dcarlson@xmlmodeling.com
Subject: Incorrect XMI Schema for associations


The final XMI Schema for SBVR serialization is not correct for Associations,
as required by the XMI 2.1.1 specification.  An implementation that produces
a valid XMI serialization will be judged as invalid, according to the
SBVR.xsd.  This is a critical bug.


I have created an SBVR implementation using Eclipse EMF, based on the final
SBVR cmof model.  An example model serialization from EMF is attached, as
test.sbvr.  In it, each model element includes an xmi:id attribute.
However, the SBVR.xsd does not allow this id on types derived from cmof
Association.


>From XMI v2.1.1, p. 49, the AssnAtts must include all XMIFixedAttribs


7. AssociationDef ::= "<xsd:element name='"' 7a:AssnElmtName '"'>"
"<xsd:complexType>
<xsd:choice minOccurs='0' maxOccurs='unbounded'>"
7b:AssnContents
"</xsd:choice>"
7d:AssnAtts
"</xsd:complexType>
</xsd:element>"
7a. AssnElmtName ::= 1c:Namespace //Name of association//
7b. AssnContents ::= 7c:AssnEndDef
7c:AssnEndDef
4c:Extension
7c. AssnEndDef ::= "<xsd:element"
"name='" //Name of association end// "'>"
"<xsd:complexType>"
1g:XMIFixedAttribs
"</xsd:complexType>"
"</xsd:element>"
7d. AssnAtts ::= 1g:XMIFixedAttribs


And, from p. 44, the XMIFixedAttribs


1g. XMIFixedAttribs ::= ( "<xsd:attribute ref='xmi:id'"
"use='optional'>" |
"<attribute name='" //Id attrib name// "'"
"type='xsd:ID' use='optional'")
"<xsd:attributeGroup ref='xmi:ObjectAttribs'/>"



 test1.sbvr 

Date: Wed, 09 Jan 2008 12:24:50 -0500
From: Ed Barkmeyer <edbark@nist.gov>
Reply-To: edbark@nist.gov
Organization: NIST
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
To: Dave Carlson <dcarlson@xmlmodeling.com>
Cc: sbvr-rtf@omg.org
Subject: Re: Incorrect XMI Schema for associations
X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: 
X-MailScanner-From: edbark@nist.gov
X-Spam-Status: No


Dave Carlson wrote:
The final XMI Schema for SBVR serialization is not correct for Associations,
as required by the XMI 2.1.1 specification.  An implementation that produces
a valid XMI serialization will be judged as invalid, according to the
SBVR.xsd.  This is a critical bug. ...


For the record, I agree with Dave's assessment.  Automated MOF tooling will generate the xmi:id unless the tooling provides a way to suppress it.  The xmi:id on Associations should be permitted in conforming SBVR files.  (In fact, it may be needed in capturing an instance of "fact type specializes fact type" as an instance of "concept specializes concept".)


Is this fix so critical that the SBVR specification needs to be modified before June?  It clearly makes conformance to SBVR v1.0 difficult or impossible for some implementors.  Will it suffice that implementors are aware that it will be corrected in SBVR v1.1?  Or do we need to create v1.0.1?


-Ed


-- 
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                FAX: +1 301-975-4694


"The opinions expressed above do not reflect consensus of NIST,
 and have not been reviewed by any Government authority."

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=btinternet.com;
  h=Received:X-YMail-OSG:Reply-To:From:To:Cc:References:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:X-MimeOLE:In-Reply-To:Thread-Index;
  b=SM15jc2m+QsOnSacjqUtkO/+U6oSCB2TJRbkMufByx6A04KkrXU5wrGbDw0Q+d9zd+k65lWRklE1YgyMEX4ynierondWDYJQxF+/OP/y5h7ky0lXxhidRyE9gQbcFN8DMWr+sobHaEsqJVZgjlnahF0hfxI+lul8gjYqoGnoQTw=  ;
X-YMail-OSG: A7aOytUVM1npFTbQ7NJXXPN9fGn4UvMivkVuRwhAVRa4yfqU0F.LUZshw58Rgoq_8cS.4g3aMZTPjH0pbuUSvdxcwLw92YlxjPZIwXhAiYyzVZkT
Reply-To: <Donald.Chapin@btinternet.com>
From: "Donald Chapin" <Donald.Chapin@btinternet.com>
To: "'Juergen Boldt'" <juergen@omg.org>
Cc: "'svetlana Orlova'" <svetlana@omg.org>,
        "'Baisley, Donald E'" <Donald.Baisley@unisys.com>,
        "Cheryl Estep" <ckestep@earthlink.net>
Subject: RE: Incorrect XMI Schema for associations
Date: Wed, 9 Jan 2008 17:27:20 -0000
Organization: Business Semantics Ltd
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AchS4Kx7mPRPIc12RkqYY/tgyChS6wAA6jIQ


Juergen,

 

Andrew Watson has decided to treat the Issue below as an Urgent Issue.  We will put it to vote to the SBVR RTF next week and publish the revised *.XSD files as soon as the vote passes.

 

Don, go ahead and fix the file as soon as possible so I can attach it to the Vote email.

 

Juergen, we will publish SBVR 1.0 with the files that you already have (the ones I send this week).  Can this be done today?

 

Many Thanks,

 

Donald

 

 


--------------------------------------------------------------------------------

From: Juergen Boldt [mailto:juergen@omg.org] 
Sent: 09 January 2008 16:57
To: Donald.Chapin@btinternet.com
Cc: svetlana Orlova
Subject: RE: Incorrect XMI Schema for associations

 

ok...waiting then 

-Juergen


At 11:51 AM 1/9/2008, Donald Chapin wrote:



Juergen,
 
Il call Don Baisley as soon as he gets in.  The final file has not been published.  I guess he used the ones from September.
 
Il let you know what Don says.
 
Donald
 


--------------------------------------------------------------------------------

From: Juergen Boldt [ mailto:juergen@omg.org] 
Sent: 09 January 2008 16:24
To: Donald.Chapin@btinternet.com
Subject: Fwd: Incorrect XMI Schema for associations
 
huh?

-Juergen



From: "Dave Carlson" <dcarlson@xmlmodeling.com>
To: <sbvr-rtf@omg.org>
Cc: <Donald.Baisley@unisys.com>, <dcarlson@xmlmodeling.com>
Subject: Incorrect XMI Schema for associations
Date: Wed, 9 Jan 2008 08:32:45 -0700
X-Mailer: Microsoft Outlook, Build 10.0.6822
Thread-Index: AchS1OG0+7t6UGtNQui0dKZP8qhhkQ==

The final XMI Schema for SBVR serialization is not correct for Associations,
as required by the XMI 2.1.1 specification.  An implementation that produces
a valid XMI serialization will be judged as invalid, according to the
SBVR.xsd.  This is a critical bug.

I have created an SBVR implementation using Eclipse EMF, based on the final
SBVR cmof model.  An example model serialization from EMF is attached, as
test.sbvr.  In it, each model element includes an xmi:id attribute.
However, the SBVR.xsd does not allow this id on types derived from cmof
Association.

>From XMI v2.1.1, p. 49, the AssnAtts must include all XMIFixedAttribs

7. AssociationDef ::= "<xsd:element name='"' 7a:AssnElmtName '"'>"
"<xsd:complexType>
<xsd:choice minOccurs='0' maxOccurs='unbounded'>"
7b:AssnContents
"</xsd:choice>"
7d:AssnAtts
"</xsd:complexType>
</xsd:element>"
7a. AssnElmtName ::= 1c:Namespace //Name of association//
7b. AssnContents ::= 7c:AssnEndDef
7c:AssnEndDef
4c:Extension
7c. AssnEndDef ::= "<xsd:element"
"name='" //Name of association end// "'>"
"<xsd:complexType>"
1g:XMIFixedAttribs
"</xsd:complexType>"
"</xsd:element>"
7d. AssnAtts ::= 1g:XMIFixedAttribs

And, from p. 44, the XMIFixedAttribs

1g. XMIFixedAttribs ::= ( "<xsd:attribute ref='xmi:id'"
"use='optional'>" |
"<attribute name='" //Id attrib name// "'"
"type='xsd:ID' use='optional'")
"<xsd:attributeGroup ref='xmi:ObjectAttribs'/>"



Juergen Boldt
Director, Member Services
Object Management Group
140 Kendrick St
Building A Suite 300
Needham, MA 02494
USA

tel: +1 781 444 0404 x 132
fax: +1 781 444 0320
email: juergen@omg.org
www.omg.org




From: "Donald Chapin" <Donald.Chapin@BusinessSemantics.com>
To: <edbark@nist.gov>, "'Dave Carlson'" <dcarlson@xmlmodeling.com>
Cc: <sbvr-rtf@omg.org>
Subject: RE: Incorrect XMI Schema for associations
Date: Wed, 9 Jan 2008 17:30:07 -0000
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AchS5KHDBpbToVyWSPe0AbAzFZhRPwAAFF9A
X-Junkmail-Status: score=10/50, host=c2bthomr02.btconnect.com
X-Junkmail-SD-Raw: score=unknown,
        refid=str=0001.0A0B0204.47850560.02BB,ss=1,fgs=0,
        ip=0.0.0.0,
        so=2006-12-09 10:45:40,
        dmn=5.4.3/2007-11-16




All --


Andrew Watson has decided to treat this as an Urgent Issue.  


Since it doesn't change the SBVR specification document, we will not need a
new SBVR version number, just a new OMG server directory folder with the
20070901 date changed to something like 20080115.


Donald



> -----Original Message-----
> From: Ed Barkmeyer [mailto:edbark@nist.gov]
> Sent: 09 January 2008 17:25
> To: Dave Carlson
> Cc: sbvr-rtf@omg.org
> Subject: Re: Incorrect XMI Schema for associations
> 
> Dave Carlson wrote:
> > The final XMI Schema for SBVR serialization is not correct for
> Associations,
> > as required by the XMI 2.1.1 specification.  An implementation that
> produces
> > a valid XMI serialization will be judged as invalid, according to the
> > SBVR.xsd.  This is a critical bug. ...
> 
> For the record, I agree with Dave's assessment.  Automated MOF tooling
> will generate the xmi:id unless the tooling provides a way to suppress
> it.  The xmi:id on Associations should be permitted in conforming SBVR
> files.  (In fact, it may be needed in capturing an instance of "fact
> type specializes fact type" as an instance of "concept specializes
> concept".)
> 
> Is this fix so critical that the SBVR specification needs to be modified
> before June?  It clearly makes conformance to SBVR v1.0 difficult or
> impossible for some implementors.  Will it suffice that implementors are
> aware that it will be corrected in SBVR v1.1?  Or do we need to create
> v1.0.1?
> 
> -Ed
> 
> --
> 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                FAX: +1 301-975-4694
> 
> "The opinions expressed above do not reflect consensus of NIST,
>   and have not been reviewed by any Government authority."



Date: Wed, 9 Jan 2008 17:37:17 +0000
To: "Dave Carlson" <dcarlson@xmlmodeling.com>
From: Andrew Watson <andrew@omg.org>
Subject: Re: Incorrect XMI Schema for associations
Cc: <sbvr-rtf@omg.org>, <Donald.Baisley@unisys.com>


Dave,


You wrote:


> The final XMI Schema for SBVR serialization is not correct for Associations,
> as required by the XMI 2.1.1 specification.  An implementation that produces
> a valid XMI serialization will be judged as invalid, according to the
> SBVR.xsd.  This is a critical bug.


Thanks very much for flagging this. I've just had a chat to Donald Chapin,
and we've agreed that we'll resolve it via OMG's "Urgent Issue" process.


To do this, we need to have it submitted as an issue. Could I ask you to go
to this web page and fill in the issue submission form:


  http://www.omg.org/technology/agreement.htm


Apart from anything else, this keeps our lawyers happy, as they are assured
that we have your permission to use any changes that you propose.


We will then need a precise set of changes that need to be made to the
Schema to fix the problem. Once we have that, I can officially flag the
issue as urgent, and the SBVR Revision Task Force can quickly vote on a
resolution (which may just be to accept the suggested default resolution).


                            Regards,


                                 Andrew
 Andrew Watson                              Tel:     +44 7710 469624
 Vice President & Technical Director,       Email:   andrew@omg.org
 Object Management Group                    http://www.omg.org/~andrew 



From: "Dave Carlson" <dcarlson@xmlmodeling.com>
To: <sbvr-rtf@omg.org>
Cc: <edbark@nist.gov>
Subject: RE: Incorrect XMI Schema for associations
Date: Wed, 9 Jan 2008 10:37:46 -0700
X-Mailer: Microsoft Outlook, Build 10.0.6822
Thread-Index: AchS5I/hVIlQoQk8S02DVYB0RE7gwQAAP22g
X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m09HbNsw026165


Ed,
>From my perspective, this only affects compliance when attempting to
validate an instance against the SBVR.xsd.  In my EMF-based implementation,
I don't have any need for using the schema -- the model serialization should
produce valid XMI based on the cmof.  My implementation should be in
conformance with the metamodel.  It will be *other* implementations that
rely on the schema that will reject otherwise conformant XMI documents.


Dave


> 
> Is this fix so critical that the SBVR specification needs to 
> be modified 
> before June?  It clearly makes conformance to SBVR v1.0 difficult or 
> impossible for some implementors.  Will it suffice that 
> implementors are 
> aware that it will be corrected in SBVR v1.1?  Or do we need 
> to create 
> v1.0.1?
> 



From: "Dave Carlson" <dcarlson@xmlmodeling.com>
To: "'Andrew Watson'" <andrew@omg.org>
Cc: <sbvr-rtf@omg.org>, <Donald.Baisley@unisys.com>
Subject: RE: Incorrect XMI Schema for associations
Date: Wed, 9 Jan 2008 10:54:54 -0700
X-Mailer: Microsoft Outlook, Build 10.0.6822
Thread-Index: AchS5j7Ss4gT5zm9SUCpg7RqyTlQQgAAlJJA


Thanks, Andrew.  I just submitted the issue.


> Thanks very much for flagging this. I've just had a chat to 
> Donald Chapin, and we've agreed that we'll resolve it via 
> OMG's "Urgent Issue" process.
> 
> To do this, we need to have it submitted as an issue. Could I 
> ask you to go to this web page and fill in the issue submission form:
> 
>   http://www.omg.org/technology/agreement.htm
> 
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 09 Jan 2008 13:33:31 -0500
To: issues@omg.org, sbvr-rtf@omg.org
From: Juergen Boldt <juergen@omg.org>
Subject: URGENT issue 12165 -- SBVR RTF issues




From: webmaster@omg.org
Date: 09 Jan 2008 12:52:55 -0500
To: <issues@omg.org>
Subject: Issue/Bug Report


--------------------------------------------------------------------------------

Name: Dave Carlson 
Company: David Carlson & Associates, Inc. 
mailFrom: dcarlson@xmlmodeling.com 
Notification: Yes 
Specification: SBVR.xsd 
Section: 13 
FormalNumber: 08-01-06 
Version: 1.0 
RevisionDate: 08-01-06 
Page: 179 
Nature: Revision 
Severity: Critical 
HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) 


Description


The final XMI Schema for SBVR serialization is not correct for Associations, as required by the XMI 2.1.1 specification. An implementation that produces a valid XMI serialization will be judged as invalid, according to the SBVR.xsd. This is a critical bug. I have created an SBVR implementation using Eclipse EMF, based on the final SBVR cmof model. An example model serialization from EMF is attached, as test.sbvr. In it, each model element includes an xmi:id attribute. However, the SBVR.xsd does not allow this id on types derived from cmof Association. >From XMI v2.1.1, p. 49, the AssnAtts must include all XMIFixedAttribs 7. AssociationDef ::= "<xsd:element name='"' 7a:AssnElmtName '"'>" "<xsd:complexType> <xsd:choice minOccurs='0' maxOccurs='unbounded'>" 7b:AssnContents "</xsd:choice>" 7d:AssnAtts "</xsd:complexType> </xsd:element>" 7a. AssnElmtName ::= 1c:Namespace //Name of association// 7b. AssnContents ::= 7c:AssnEndDef 7c:AssnEndDef 4c:Extension 7c. AssnEndDef ::= "<xsd:element" "name='" //Name of association end// "'>" "<xsd:complexType>" 1g:XMIFixedAttribs "</xsd:complexType>" "</xsd:element>" 7d. AssnAtts ::= 1g:XMIFixedAttribs And, from p. 44, the XMIFixedAttribs 1g. XMIFixedAttribs ::= ( "<xsd:attribute ref='xmi:id'" "use='optional'>" | "<attribute name='" //Id attrib name// "'" "type='xsd:ID' use='optional'") "<xsd:attributeGroup ref='xmi:ObjectAttribs'/>" 



Juergen Boldt
Director, Member Services
Object Management Group
140 Kendrick St
Building A Suite 300
Needham, MA 02494
USA

tel: +1 781 444 0404 x 132
fax: +1 781 444 0320
email: juergen@omg.org
www.omg.org
From: "Baisley, Donald E" <Donald.Baisley@unisys.com>
To: "donald.chapin@btinternet.com" <donald.chapin@btinternet.com>
Cc: Juergen Boldt <juergen@omg.org>, "sbvr-rtf@omg.org" <sbvr-rtf@omg.org>,
        Dave Carlson <dcarlson@xmlmodeling.com>,
        Pete Rivett <pete.rivett@adaptive.com>
Date: Thu, 10 Jan 2008 18:17:07 -0600
Subject: RE: URGENT issue 12165 -- SBVR RTF issues
Thread-Topic: URGENT issue 12165 -- SBVR RTF issues
Thread-Index: AchS7nu3L2wgCj6eT0OND+HSH+IPGwA93WAw
Accept-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
X-OriginalArrivalTime: 11 Jan 2008 00:17:10.0309 (UTC) FILETIME=[4EB4ED50:01C853E7]


Hi Donald,

 

Attached are updated XML schemas for SBVR.  They allow xmi:id to be specified for links in the same way as for objects, as indicated in the XMI 2.1.1 specification.

 

I have validated Dave.s test case and some other examples using what is attached.

 

Best Regards,

Don

 

 


--------------------------------------------------------------------------------

From: Juergen Boldt [mailto:juergen@omg.org] 
Sent: Wednesday, January 09, 2008 10:34 AM
To: issues@omg.org; sbvr-rtf@omg.org
Subject: URGENT issue 12165 -- SBVR RTF issues

 





From: webmaster@omg.org
Date: 09 Jan 2008 12:52:55 -0500
To: <issues@omg.org>
Subject: Issue/Bug Report


--------------------------------------------------------------------------------

Name: Dave Carlson 
Company: David Carlson & Associates, Inc. 
mailFrom: dcarlson@xmlmodeling.com 
Notification: Yes 
Specification: SBVR.xsd 
Section: 13 
FormalNumber: 08-01-06 
Version: 1.0 
RevisionDate: 08-01-06 
Page: 179 
Nature: Revision 
Severity: Critical 
HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) 
 

Description


The final XMI Schema for SBVR serialization is not correct for Associations, as required by the XMI 2.1.1 specification. An implementation that produces a valid XMI serialization will be judged as invalid, according to the SBVR.xsd. This is a critical bug. I have created an SBVR implementation using Eclipse EMF, based on the final SBVR cmof model. An example model serialization from EMF is attached, as test.sbvr. In it, each model element includes an xmi:id attribute. However, the SBVR.xsd does not allow this id on types derived from cmof Association. >From XMI v2.1.1, p. 49, the AssnAtts must include all XMIFixedAttribs 7. AssociationDef ::= "<xsd:element name='"' 7a:AssnElmtName '"'>" "<xsd:complexType> <xsd:choice minOccurs='0' maxOccurs='unbounded'>" 7b:AssnContents "</xsd:choice>" 7d:AssnAtts "</xsd:complexType> </xsd:element>" 7a. AssnElmtName ::= 1c:Namespace //Name of association// 7b. AssnContents ::= 7c:AssnEndDef 7c:AssnEndDef 4c:Extension 7c. AssnEndDef ::= "<xsd:element" "name='" //Name of association end// "'>" "<xsd:complexType>" 1g:XMIFixedAttribs "</xsd:complexType>" "</xsd:element>" 7d. AssnAtts ::= 1g:XMIFixedAttribs And, from p. 44, the XMIFixedAttribs 1g. XMIFixedAttribs ::= ( "<xsd:attribute ref='xmi:id'" "use='optional'>" | "<attribute name='" //Id attrib name// "'" "type='xsd:ID' use='optional'") "<xsd:attributeGroup ref='xmi:ObjectAttribs'/>" 



Juergen Boldt
Director, Member Services
Object Management Group
140 Kendrick St
Building A Suite 300
Needham, MA 02494
USA

tel: +1 781 444 0404 x 132
fax: +1 781 444 0320
email: juergen@omg.org
www.omg.org






Date: Mon, 4 Aug 2008 16:55:11 +0100
To: sbvr-rtf@omg.org
From: Andrew Watson <andrew@omg.org>
Subject: Issue 12165 now declared Urgent


Dear members of the SBVR RTF,


Donald Chapin has reminded me that I was planning to declare issue 12165 as
Urgent back in February, but never did. My apologies for this oversight.


This email is the (belated) formal declaration that issue 12165 is Urgent,
in accordance with the procedure laid out in section 4.4.1.5 of the P&P
(pp/08-06-01).


The summary of this issue can be found here (sadly with hard-to-read
formatting):


  http://www.omg.org/issues/sbvr-rtf.open.html#Issue12165


This is an issue with the SBVR 1.0 specification, and will be voted on by
the SBVR RTF.


The default resolution will be to apply the attached changes to the SBVR
1.0 specification XSD files:


http://www.omg.org/spec/SBVR/20070901/MeaningAndRepresentation.xsd
http://www.omg.org/spec/SBVR/20070901/LogicalFormulationOfSemantics.xsd
http://www.omg.org/spec/SBVR/20070901/DescribingBusinessVocabularies.xsd
http://www.omg.org/spec/SBVR/20070901/DescribingBusinessRules.xsd
http://www.omg.org/spec/SBVR/20070901/SBVR.xsd


The deadline for resolving this Urgent issue is 14 days from today (i.e. by
1700 BST on Monday 18th August 2008).


This default resolution will be automatically applied if and only if the
RTF fails to resolve issue 12165 by that time. Even if the RTF decides to
apply the default resolution, I strongly recommend that it makes this
decision by a recorded vote, rather than by letting the time limit expire
and passing responsibility back to me.


                                 Thanks,


                                    Andrew



Issue 12165 Default Resolution
==============================


Insert these two lines:


 <xs:attribute ref="xmi:id"/>
 <xs:attributeGroup ref="xmi:ObjectAttribs"/>


After every line of the form:


</xs:all>


In these files:


SBVR.xsd                            (139 occurrences)
DescribingBusinessRules.xsd         (97 occurrences)
DescribingBusinessVocabularies.xsd  (88 occurrences)
LogicalFormulationOfSemantics.xsd   (84 occurrences)
MeaningAndRepresentation.xsd        (42 occurrences)


(Note: These syntactic editing instructions achieve the semantic
modification proposed by Don Baisley in his email of 8th February: "Add the
following two lines into the xs:complexType of the SBVR XML schemas for
each association of the SBVR metamodel.") 

Subject: RE: Issue 12165 now declared Urgent
Date: Mon, 4 Aug 2008 12:21:58 -0500
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Issue 12165 now declared Urgent
Thread-Index: Acj2S1Mlg/SwwOMiQtClxUTICP508gAehofw
From: "Malhotra, Sumeet S" <Sumeet.Malhotra@unisys.com>
To: "Andrew Watson" <andrew@omg.org>, <sbvr-rtf@omg.org>
X-OriginalArrivalTime: 04 Aug 2008 17:22:17.0100 (UTC) FILETIME=[A4B4ECC0:01C8F656]
X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m74HQPXq031058


Unisys votes Yes to all resolutions on this issue.


Sumeet Malhotra, PhD
Global Director of Advanced Research & Industry Standards, UNISYS
CTO, W2COG
email: sumeet.malhotra@unisys.com
cell: 484-364-0048


-----Original Message-----
From: Andrew Watson [mailto:andrew@omg.org] 
Sent: Monday, August 04, 2008 11:55 AM
To: sbvr-rtf@omg.org
Subject: Issue 12165 now declared Urgent


Dear members of the SBVR RTF,


Donald Chapin has reminded me that I was planning to declare issue 12165
as
Urgent back in February, but never did. My apologies for this oversight.


This email is the (belated) formal declaration that issue 12165 is
Urgent,
in accordance with the procedure laid out in section 4.4.1.5 of the P&P
(pp/08-06-01).


The summary of this issue can be found here (sadly with hard-to-read
formatting):


  http://www.omg.org/issues/sbvr-rtf.open.html#Issue12165


This is an issue with the SBVR 1.0 specification, and will be voted on
by
the SBVR RTF.


The default resolution will be to apply the attached changes to the SBVR
1.0 specification XSD files:


http://www.omg.org/spec/SBVR/20070901/MeaningAndRepresentation.xsd
http://www.omg.org/spec/SBVR/20070901/LogicalFormulationOfSemantics.xsd
http://www.omg.org/spec/SBVR/20070901/DescribingBusinessVocabularies.xsd
http://www.omg.org/spec/SBVR/20070901/DescribingBusinessRules.xsd
http://www.omg.org/spec/SBVR/20070901/SBVR.xsd


The deadline for resolving this Urgent issue is 14 days from today (i.e.
by
1700 BST on Monday 18th August 2008).


This default resolution will be automatically applied if and only if the
RTF fails to resolve issue 12165 by that time. Even if the RTF decides
to
apply the default resolution, I strongly recommend that it makes this
decision by a recorded vote, rather than by letting the time limit
expire
and passing responsibility back to me.


                                 Thanks,


                                    Andrew



Issue 12165 Default Resolution
==============================


Insert these two lines:


 <xs:attribute ref="xmi:id"/>
 <xs:attributeGroup ref="xmi:ObjectAttribs"/>


After every line of the form:


</xs:all>


In these files:


SBVR.xsd                            (139 occurrences)
DescribingBusinessRules.xsd         (97 occurrences)
DescribingBusinessVocabularies.xsd  (88 occurrences)
LogicalFormulationOfSemantics.xsd   (84 occurrences)
MeaningAndRepresentation.xsd        (42 occurrences)


(Note: These syntactic editing instructions achieve the semantic
modification proposed by Don Baisley in his email of 8th February: "Add
the
following two lines into the xs:complexType of the SBVR XML schemas for
each association of the SBVR metamodel.") 



Date: Wed, 27 Aug 2008 15:20:10 +0100
To: sbvr-rtf@omg.org
From: Andrew Watson <andrew@omg.org>
Subject: Re: Issue 12165 now declared Urgent


Dear members of the SBVR RTF,


On 4th August, I wrote:


> This email is the (belated) formal declaration that issue 12165 is Urgent,
> in accordance with the procedure laid out in section 4.4.1.5 of the P&P
> (pp/08-06-01).


> The deadline for resolving this Urgent issue is 14 days from today (i.e. by
> 1700 BST on Monday 18th August 2008).
>
> This default resolution will be automatically applied if and only if the
> RTF fails to resolve issue 12165 by that time.


Since the FTF did not vote on a resolution of the issue before the
deadline, I have asked Linda Heaton to make the changes listed below to the
XSD files, and post a new version of SBVR (SBVR 1.0.1) which is identical
to the current version *except* that it lists the new XSD files on the
cover.


Please include this resolution of issue 12165 in the report your RTF is due
to deliver shortly.


                                 Thanks,


                                   Andrew




Issue 12165 Default Resolution
==============================


Insert these two lines:


 <xs:attribute ref="xmi:id"/>
 <xs:attributeGroup ref="xmi:ObjectAttribs"/>


After every line of the form:


</xs:all>


In these files:


SBVR.xsd                            (139 occurrences)
DescribingBusinessRules.xsd         (97 occurrences)
DescribingBusinessVocabularies.xsd  (88 occurrences)
LogicalFormulationOfSemantics.xsd   (84 occurrences)
MeaningAndRepresentation.xsd        (42 occurrences)


(Note: These syntactic editing instructions achieve the semantic
modification proposed by Don Baisley in his email of 8th February: "Add the
following two lines into the xs:complexType of the SBVR XML schemas for