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

["Stan Hendryx" <stan@xxxxxxxxxxxxxxxx>]

Thanks for this, Dave. Please see my comments below.

Regards,

Stan


1. Why do we need five plugins? Why not just one plugin that will support
any of the compliance points? The user just picks the conceptual schema to
use for a given fact model being created, by instantiating the appropriate
fact of "fact model is based on conceptual schema" in their fact model. We
have five distinguished conceptual schemas, one for each of the compliance
points. These are related by package merges, as shown in Fig. 2.1.  Is there
a problem with EMF using package merge if the packages are all in the same
plugin? 

2. There are several use cases where a given fact model is transformed into
another fact model based on a different one of the SBVR conceptual schemas.
How best to support this with our architecture?

3. In SBVR-MRV, "Package", "PackagableElement", and "Element" seem
unnecessary. These terms are not part of the MRV, except "element" is used
(but not defined) in SBVR as a fact type role that ranges over "thing": "set
has element", meaning "thing is in set". SBVR tools operate on fact models,
which is the root package we are dealing with.

These are in MRV:
    fact model --> Package
    fact --> PackageableElement (fact model includes fact)
    thing --> Element (everything is implicitly a thing)

There is a finite list of other "packages," too, in MRV and the other
vocabularies: set, namespace, vocabulary, rulebook, ... 

Let's use SBVR concepts and not introduce new ones into the metamodel,
except as extensions of SBVR concepts, and then only if really needed.

4. SBVR-MRV.uml says "fact model is based on [0..*] conceptual schemas".
Multiplicity should be [1], not [0..*]. The definition of "fact model" is
"combination of a conceptual schema and ...". 

5. The association names should be SBVR fact type forms.

##