RE: [mdt-sbvr.dev] Draft of UML model for tooling metamodel

["Dave Carlson" <dcarlson@xxxxxxxxxxxxxxx>]

Stan,
I am on the road week at an HL7 meeting and have limited time to respond,
but quick replies below.

> > Tha o.e.sbvr.xmi plugin is intended to represent only the
> > SBVR CMOF model as
> > delivered by the specification. 
>  
> Yes. I agree, although it should be extensible as described 
> section 2 to handle certain files with non-SBVR constructs.
> 

This should be supported by default using EMF, where unknown XML tags can be
retained and accessed via EMF APIs.

> > And that model is only used to
> > serialize/deserialize the "SBVR exchange document" as
> > described in section 2.
> 
> Serialize/deserialize, yes, but not only that: 
> * Should also be able to validate a fact model against the 
> SBVR spec at any specified compliance point. 

I don't agree here.  I think you have a misunderstanding of what I am
calling the "SBVR Tools metamodel".  It is not the implementation of a
particular editing tool, but it is our primary SBVR metamodel that supports
specification compliance and is optimized for use with EMF.  See the
discussion by Mark Linehan on 23 April, with this conclusion:  "My net: this
project has already discovered that it can't use the SBVR CMOF model
exactly.  I go further: I think we should design a custom UML / EMF model
for SBVR that is inspired by, but does not start with, the SBVR CMOF." 

This "custom model" is what I am calling the "SBVR Tools metamodel". The
SBVR Tools metamodel must support full semantic validation of SBVR
vocabularies and rules developed by a user, for each compliance point.  The
o.e.sbvr.xmi plugin (implementing the SBVR CMOF metamodel) is only used to
load/save the SBVR exchange document files.

One possible design strategy is where the o.e.sbvr.xmi plugin is not needed
at all, and a custom EMF resource handler is used to serialize/deserialize
the SBVR Tools metamodel to/from the SBVR exchange document format.  The
SBVR Tools metamodel, by default, will save files using the .sbvr file
extension.

Look at the UML2 project for a similar idea. By default, UML models are
saved using the .uml file extension.  To save in the OMG exchange format,
simply "Save As" .xmi in the sample UML2 editor.  This invokes a custom
resource handler to modify the XML format.

If you use the preliminary .genmodel that I posted to the bugzilla and
generate the Model and Edit plugins for each, and generate the Editor plugin
for only the SBVR model, then you can use the sample editor to create a
simple SBVR vocabulary and save to the default .sbvr format.  See the
attached Test.sbvr.  This vocabulary would be saved to the SBVR exchange
document format either by using a custom EMF resource handler for .xmi file
extension, or by transforming to the o.e.sbvr.xmi SBVR CMOF metamodel and
then saving that.

Attachment: Test.sbvr
Description: Binary data