RE: [mdt-sbvr.dev] SBVR Metamodel

["Dave Carlson" <dcarlson@xxxxxxxxxxxxxxx>]

> I agree with almost all of what Stan said in his three notes 
> of April 24. In particular, I endorse the idea of producing 
> separate UML, EMF, and Java packages for each SBVR vocabulary.

This is problematic when using MOF packageMerge in the metamodel.  The
merged packages become one aggregate package.  Kenn may have some
suggestions on this from his experience with UML.

If packageMerge is used, then this is an errata for the SBVR RTF because the
delivered CMOF model files do not use packageMerge dependencies, but reflect
only the merged content.

But it may be possible and desirable to remove the use of "packageMerge" in
the SBVR metamodel specification and use "packageImport" instead.  Most of
the SBVR vocabulary packages only add to the other vocabularies and do not
redefine the base packages (as is done extensively in the UML metemodel
package merge).  The only exception is a small use of "subsets" in the
specification metamodel diagrams.  However, none of the "subsets"
constraints from the spec diagrams actually is reflected in the delivered
CMOF models...  Maybe these can/should be removed.

> write something separately about it.  I think we both agree 
> that such simplifications are permissible in this project if 
> and only if they maintain the intended SBVR semantics.

I think we all agree on this.  I would also add that we should agree on the
importance of XMI serialization that is compliant with the SBVR
specification.  The metamodel design may be modified to assist tool design,
but we must assure that these structures can be loaded/saved from compliant
XMI.  That's why I created a separate project plan item for XMI compliance.