| [mdt-sbvr.dev] RE: mdt-sbvr.dev Digest, Vol 7, Issue 4 |
________________________________
Van: mdt-sbvr.dev-bounces@xxxxxxxxxxx namens mdt-sbvr.dev-request@xxxxxxxxxxx
Verzonden: do 20-11-2008 18:00
Aan: mdt-sbvr.dev@xxxxxxxxxxx
Onderwerp: mdt-sbvr.dev Digest, Vol 7, Issue 4
Send mdt-sbvr.dev mailing list submissions to
mdt-sbvr.dev@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev
or, via email, send a message with subject or body 'help' to
mdt-sbvr.dev-request@xxxxxxxxxxx
You can reach the person managing the list at
mdt-sbvr.dev-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of mdt-sbvr.dev digest..."
Today's Topics:
1. More comments/questions on the MRV implementation (Mark H Linehan)
----------------------------------------------------------------------
Message: 1
Date: Wed, 19 Nov 2008 16:58:58 -0500
From: Mark H Linehan <mlinehan@xxxxxxxxxx>
Subject: [mdt-sbvr.dev] More comments/questions on the MRV
implementation
To: mdt-sbvr.dev@xxxxxxxxxxx
Message-ID:
<OF7BC1F869.9035350E-ON85257506.004FB2EA-85257506.0078C14D@xxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
* I assume that the Role.objectTypes models the fact type "role ranges
over object type". Is that correct? It would be clearer if it were named
"Role.rangesOver" or some such. Also, the SBVR specification doesn't limit
the number of ObjectTypes that a role can range over, but I don't think it
makes sense to have a role that ranges over multiple Object Types. So I
think this should be a singleton rather than an EList association. (Should
we raise this as an issue against the SBVR spec?) [Sjir: please do.]
* I want to model a fact type "driver has name", where the role "name"
ranges over an object type "Text". I think this primitive object type
should be predefined in the MRV model, so that different implementors can
share it. Otherwise, you will get variations among implementors as to how
this is handled. Ditto for "Number" and its relatives.
* Similarly, I think the designation "has" should be predefined in the MRV
model since it will be used widely.
* I see that the internal operations (e.g. in
org.eclipse.sbvr.mrv.internal.operations) are generated, but I don't see
what they are geneated from. I don't see any reference to them in
the .ecores. Can you explain where they come from?
* FactTypeFormOperations.getPlaceholders() and .getDemonstrated() are not
implemented. These are used by corresponding methods in FactTypeFormImpl.
* What is the design criteria by which you put some methods in the "*Impl"
classes, and some in "internal operations" classes? And how do you decide
which methods go in which "internal operations" classes. For example, it
seems strange that the createRepresentation() method is in
MeaningOperations, rather than in RepresentationOperations. Or in
RepresentationImpl.
* How do you set the Placeholders for a FactTypeForm? There is no method
defined for that at all. (Maybe the Placeholders for a FactTypeForm are
supposed to be derived from the PlaceHolders that act as Designations for
the Roles of the corresponding FactType??)
* There is an opportunity in RepresentationOperations.setExpressionText to
optimize the number of Texts created by avoiding the creation of a new Text
if there already exists one with the same value. As currently implemented,
I am getting lots of duplicated Texts. For example, I see a separate Text
with the value "has" for each of the many FactTypes that demonstrate the
designation "has".
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research
phone: (914) 945-1038 or IBM tieline 862-1038
internet: mlinehan@xxxxxxxxxx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://dev.eclipse.org/mailman/private/mdt-sbvr.dev/attachments/20081119/020bdb22/attachment.html
------------------------------
_______________________________________________
mdt-sbvr.dev mailing list
mdt-sbvr.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev
End of mdt-sbvr.dev Digest, Vol 7, Issue 4
******************************************
<<winmail.dat>>