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

["Dave Carlson" <dcarlson@xxxxxxxxxxxxxxx>]

Stan,

Tha o.e.sbvr.xmi plugin is intended to represent only the SBVR CMOF model as
delivered by the specification.  And that model is only used to
serialize/deserialize the "SBVR exchange document" as described in section
2.

I do not expect any other SBVR project plugins to have a dependency on
o.r.sbvr.xmi, unless they are transforming the SBVR Tools metamodel to/from
the SBVR exchange document format.  Tools will be built against the SBVR
Tools metamodel, not the exchange document metamodel.  So, as per our
discussion last week, it is this SBVR Tools metamodel that is our first
priority, while simultaneously considering how it is transformed to/from the
SBVR exchange document metamodel (to be saved/loaded as XMI).

Dave

> As for the plugin architecture, there should be one plugin 
> for org.eclipse.sbvr.xmi, that loads a file of any compliance 
> point and saves compliant XMI of whatever compliance point is 
> specified for a save, and other plugins, dependent on 
> org.eclipse.sbvr.xmi, for tools that create or consume fact 
> models from org.eclipse.sbvr.xmi. I would hope every SBVR 
> tool would use the first plugin; that would be a major win to 
> assure interoperability of SBVR tools. An abundance of 
> interoperable SBVR tools that create, modify, browse, 
> transform, or otherwise process the org.eclipse.sbvr.xmi fact 
> models could evolve. The API for org.eclipse.sbvr.xmi should 
> consider the needs of these main kinds of applications for 
> fact model access. Getting org.eclipse.sbvr.xmi done well and 
> soon is my main personal goal in supporting this project. 
> Once it is in place, tools can follow, ours included.