Dave, et al,
I live in the area and am available
anytime except 9-6 Tuesday, when I’m in the date-time submitters team
meeting. How about meeting of an evening? I looks like there are conflicts
during the day.
Stan
From:
mdt-sbvr.dev-bounces@xxxxxxxxxxx [mailto:mdt-sbvr.dev-bounces@xxxxxxxxxxx] On Behalf Of Dave Carlson
Sent: Tuesday, December 02, 2008
8:46 AM
To: 'SBVR
developer list'
Subject: RE: [mdt-sbvr.dev]
Thoughts about two approaches to modeling theMeaning & Representation (MRV)
part of SBVR
My apologies for not responsing to this
thread sooner. Some urgent personal matters required me to take off a
week or so, and I am still digging out...
I will be attending the OMG meeting in Santa Clara, CA
next week, arriving late Sunday and leaving Friday afternoon. Mark and
Stan, will you be there? Kenn? Can we plan a meeting to dicuss
these design alternatives? I am unavailable Tuesday afternoon and all day
Wednesday next week; I must attend the Open Health Tools board meeting that is
co-located with OMG (see www.openhealthtools.org).
If anyone has an interest in business modeling for healthcare (BPMN and SBVR),
I would also like to discuss that.
Regarding Mark's comment below, my
greatest concern about using the EMF extension approach is (1) prevents, or
complicates, use of many other EMF frameworks for validation, search,
editor generation, edit transactions, etc., and (2) more difficult learning
curve that will prevent other tool developers and product vendors from using
this metamodel implementation.
I believe that it is essential for us to
summarize several use cases for end-user tooling that will be implemented on
top of this SBVR tooling metamodel. How do these decisions help or hinder
creation of "structured english" editors and publishing tools?
Search and repository tools? Transformation to/from UML, OCL, or other
design models? Transformation to/from OWL and ODM? Transformation
to/from the SBVR exchange metamodel and serialization format? Other
tooling use cases?
The principle downside I see with the EMF extension approach is the risk that
future changes in EMF could break the MRV implementation. This risk arises from
the fact that the implementation depends upon some aspects of the EMF design.
On the other hand, the EMF design is pretty open, so it would be hard to change
it in significant ways without breaking lots of other code.
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research
phone: (914) 945-1038 or IBM tieline 862-1038
internet: mlinehan@xxxxxxxxxx
|