[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] MDT-OCL 2.0.0 OCL compliance levels
|
Hi Ed,
I think 2.0/2.2 compliance (is that 2.2 or 2.1? the last version was 2.0
and the draft tells "2.1", so where has this "2.2" come from?) will be
answered on the other thread "Compatibility Support".
I wanted to state here that I cannot aggree with dropping the ecore
binding of OCL. As a user, I use Eclipse with a minimal set of plugins
and UML2 is obviously an unneeded dependency. Why should I be forced to
install UML when I clearly don't need it? Installing EcoreTools,
Acceleo, GMF, ... from p2 only installs the ecore binding. I admit I
don't have a clear view of the reasons that lead to the appearance of
those two bindings, but I do know the ecore binding is sufficiantly used
to be maintained; especially when it allows for a cleaner installation.
Laurent Goubet
Obeo
Ed Willink a écrit :
Hi
I've now scanned the OCL spec changebars and updated
http://wiki.eclipse.org/MDT/OCL/OCL_2.0_API_Changes significantly.
It is clear that MDT-OCL 1.3.0 anticipated a number of changes and so
no further change is necessary for some changes. However if we are to
offer an accurate OCL 2.0 compliance mode we will have to revisit the
implementation of what is perhaps the only sensible solution and
provide something that is pedantically correct but useless and stupid.
It is also clear that some of the proposed OCL 2.2 changes introduce
some contradictory behaviours e.g "null = null" and still leave many
issues unspecified e.g. UnlimitedNatural operations.
I therefore propose the following selectable built-in compliance
levels and philosophical aspirations. Alternative compliances should
be available via extensibility.
Default compliance
---------------------------
The implementation is as close as sensible to the latest OCL
specification. Every intentional deviation is documented and
associated with a submitted OMG issue that has a reasonable prospect
of adoption one day. Probable OCL specifications revisions may be
implemented. Compatibility for earlier OCL specifications may be
provided.
Strict 2.2 compliance
----------------------------
The implementation is as close as possible to the OCL 2.2
specification. Every intentional deviation is documented and
associated with a resolution from a later OMG specification or a
submitted OMG issue that has a reasonable prospect of adoption one
day. Use of deviations will produce warning/error messages that can be
suppressed.
Traditional 2.0 compliance
------------------------------------
The implementation is a compromise between preserving MDT-OCL 1.3.0
behaviour and adherence to the spirit of the OCL 2.0 specification.
Every intentional deviation is documented. Obvious errors such as
https://bugs.eclipse.org/bugs/show_bug.cgi?id=260403 will be fixed.
Controversial changes will be avoided, but may be enabled by voluntary
configuration.
Traditional 2.2 compliance
------------------------------------
A similar compromise behaviour preserving default compliance between
the final OCL 2.2 MDT-OCL version and OCL 2.2 for use once OCL moves
on from 2.2. Until then, Traditional 2.2 compliance is identical to
Default Compliance.
----------------------
The above are for the UML2 binding only.
Deprecated Ecore binding
-----------------------------------
Further to https://bugs.eclipse.org/bugs/show_bug.cgi?id=283052 I
don't think that we can get sufficiently close to an OCL specification
with the Ecore binding. I think that the UML2 project is now
sufficiently mature that we should encourage all users to migrate to
the UML2 binding. The Ecore binding should be passively maintained but
deprecated in MDT OCL 2.0.0. The Ecore binding should be withdrawn in
MDT OCL 3.0.0 at which point all the generics can be eliminated.
(Discussion on Bugzilla 283052 please.)
Regards
Ed Willink
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
