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

["Stan Hendryx" <stan@xxxxxxxxxxxxxxxx>]

Dave Carlson wrote:

> 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.

> 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. 
* Should be able to determine the compliance point of a file that is read.
* Should be able to normalize a fact model to use only SBVR preferred terms
and eliminate duplicate text and integers.
* Should be able to map xmi:ids in exchange documents to things in the fact
model, and make this mapping available to tools.
* Should be able to convert a fact model to a different compliance point,
and serialize the result as a different fact model.
* Should be extensible such that it can serialize/deserialize instances of
other concepts that are extensions of SBVR concepts. (We might consider
adding this capability in a later release, and just provide hooks for this
feature in the first release).
* Should have a robust interface for tools that enables tools to build,
query, and load or save fact models in various convenient ways, particularly
allowing tools to make use of the SBVR reference schemes to identify things.
The load/save format would be SBVR exchange document format initially, but
support for other formats might be added in future releases.
 
> 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.  

Our tools should all support the SBVR exchange document format.

> Tools will be built 
> against the SBVR
> Tools metamodel, not the exchange document metamodel.  

Do you envision a general-purpose SBVR Tools metamodel, "the SBVR Tools
metamodel"? I think tool metamodels will be different, depending on the
intended function, use, and sophistication of the tool. Most of the tools
will depend on the MRV tool and its 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).

I agree we need a tool to exercise the o.e.sbvr.xmi. In my view, the first
tool, built along with o.e.sbvrf.xmi, should be very simple, just supporting
MRV. The initial tools should focus on functionality, not user interfaces.
The first tool should be able to create a fact model of a conceptual schema
like SBVR from a .csv file that contains namespace URIs, designations, fact
type forms, statements, and definitions, which are used by MRV reference
schemes to identify things in the fact model, and save the fact model in
SBVR exchange document format. Any spreadsheet program that can create a csv
can be the UI. This first tool should be able to read the saved file and
produce an identical (in some sense TBD) csv, round-trip. Then we can then
add VDBV capability, and save terminological dictionaries, notes, examples,
and references, add communities and templating. Then VDBR, adding elements
of guidance and rulebooks. We can add more spohisticated LFSV tools later,
e.g. a tool that parses rule statements and definitions and produces
semantic formulations. The LFSV tool could be added after the MRV tool, or
in parallel with VBDV and VDBR. Similarly with transformation tools.
However, a robust MRV tool, working with o.e.sbvr.xmi, is the foundation,
which is reused by the other tools. 

Stan