RE: [mdt-sbvr.dev] SBVR-uml designation.gif - focus

["Stan Hendryx" <stan@xxxxxxxxxxxxxxxx>]

Hi Dave,

SBVR has five compliance points, related by package merges (see 2.2). Have
you thought about how to account for the different compliance points in the
model we are developing?

I notice you have included in the subject diagram terms from two of the base
vocabularies. "Fact symbol" is in the Vocabulary for Describing Business
Vocabularies (VDBV) while all of the other terms in your model are in the
Meaning and Representation Vocabulary (MRV), which is included in VDBV.
Technically, this would mean your model is not expressible in MRV, but
requires the VDBV compliance point. How would you set it up so that a person
wanting to use only the MRV would be guarded from using terms not in MRV?

There are some problems with the spec in regard to undefined terms.
"Vocabulary" is used in MRV (in the informal definition of "vocabulary
namespace") but is defined in VDBV, which is odd, but not fatal. "Element"
is used in MRV ("set has element") but is not in any vocabulary (more
serious). While these are matters for the RTF to resolve, how do you suggest
we deal with them in this project?

In making a robust model, we need to consider the constraints expressed by
the definitions in the spec, as well as the necessities. One challenge is
that many definitions in the spec are informal that could, and probably
should, be formalized. For example, the definition of "fact symbol" is not
formal, but could be formalized as "designation that is demonstrated by a
fact type form". Again, while this is a matter for the RTF, would you see us
attempting to interpret informal or partly formal definitions in a formal
way like this, beyond just the general concept, or should we just leave the
defined terms as primitives constrained only by the explicit SBVR fact types
and necessities? I know I said we should not add constraints not in the
spec, but I'm waffling on this point. :)

Regards,

Stan


> -----Original Message-----
> From: mdt-sbvr.dev-bounces@xxxxxxxxxxx 
> [mailto:mdt-sbvr.dev-bounces@xxxxxxxxxxx] On Behalf Of Dave Carlson
> Sent: Friday, April 11, 2008 8:54 AM
> To: 'SBVR developer list'
> Subject: [mdt-sbvr.dev] Code checked into CVS
> 
> Hello all,
> 
> I checked into CVS the first version of SBVR plugins 
> generated from CMOF
> for: model, edit, and editor.  I have begun adding background 
> and design
> documentation to the SBVR project wiki: 
> http://wiki.eclipse.org/MDT-SBVR
> 
> In particular, look at the two linked pages for metamodel issues and
> metamodel modifications.  As a starting point, I have looked 
> at a small part
> of the SBVR metamodel for concept designations (e.g. Term and Name).
> 
> The general consensus from developers I've talked to is that 
> some changes
> are required to make the SBVR metamodel more usable for tool 
> development.
> This follows an approach similar to the UML2 implementation, 
> where a .uml
> file is associated with an Eclipse UML2 URI, and there is a 
> resource handler
> that loads/saves UML models to .xmi files using the OMG 
> specification URI.  
> 
> For SBVR models, the .sbvr file extension is associated with 
> an Eclipse SBVR
> URI, and the .xmi file extension uses the OMG specification 
> URI.  I have not
> yet implemented the XMI resource load/save classes for SBVR, 
> but will work
> on that next.
> 
> Regards,
>   Dave Carlson
> 
> 
> _______________________________________________
> mdt-sbvr.dev mailing list
> mdt-sbvr.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev
> 
>