[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[mdt-ocl.dev] MDT-OCL 2.0.0 OCL compliance levels
|
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