Laurent,
comments in-line:
Laurent Goubet escribió:
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".
The "2.2" version number was changed in the last minute, in order to
align the version number of the UML standard (UML 2.2). So there is not
OCL 2.1 specification.
Please, respond to the other thread. A fourth point of view would be
appreciated to light on this critical decision.
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.
There are two (even it could be more bindings) because you can define
one or several languages (OCL, Essential OCL ) using different
languages in the higher modeling layer (UML, MOF, Essential MOF).
Taking Ecore as our EMOF implementation, you can:
- Use tools based on this implementation (EcoreTools, GMF...)
- Define new languages which use EMOF language in its higher modeling
layer, such as Ecore-binding OCL (As I understand, Essential OCL).
- Acceleo (OMG's M2T standard), QVT, etc use and/or extends Essential
OCL.
So, I suppose that all these tools don't need an UML-binding OCL
implementation. However, we also need UML to support complete OCL as
its mainly defined in the specification.
I agree that Ecore binding might not be dropped. I think Essential OCL
was defined to work with the simpler EMOF.
P.S: I'm sorry for not properly answering this discussion. I'm in a
hurry to finish a report for my phD on Monday.
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
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
--
|
Adolfo
Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231 / +34 617 718268 |
|
