[mdt-ocl.dev] MDT-OCL 2.0.0 OCL compliance levels

[Ed Willink <ed@xxxxxxxxxxxxx>]

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