Re: HA: [mdt-ocl.dev] MDT 2.0.0 vs OMG 2.0 / 2.2?

[ed@xxxxxxxxxxxxxxxxxx]

Hi Adolfo

You're right. It's not easy. Code decisions can be handled by alternate
behavioiural objects/methods. The meta-models are harder.

The UML2 project gives us some clues. It supports UML 2.1 and 3.0.

The model directory contains uml.ecore (3.0) and uml_21.ecore (2.1).
The Jasva classes are from the 3.0 model only.

The important point is that the Ecore model is an Eclipse implementation
that matches the OMG/EMOF specs as closely as possible. It is not precise.
Use of EReference makes the model instantly non-identical from a pedantic
semantic viewpoint and totally incompatible from a meta-model spelling
viewpoint.

We therefore maintain the Ecore OCL 2.2 model as a slight superset
(include the obsolete classes) so that all the model classes still have
Java classes, but exclude the spurious classes programatically. Certain
reflective actions will be inaccurate, such as what are my superclasses,
but they were in accurate anyway because they had OCL class names twice
and higher level classes with E prefixes.

So for instance the TypeTypeImpl constructor when configured for OCL 2.2
must throw a ClassNotFoundException, but work normally for OCL 2.0.

   Regards

      Ed Willink

> Hi Team,
>
> Honestly, this is easier to say than to do. If you want to support both
> specifications I hope you have already thought a wonderful design to
> support them. I ask you the same question I asked Laurent. Have you
> thought about if we are going to keep 2 different meta-models (OCL 2.0
> compliant and 2.2 compliant). Are we going to keep an OCL 2.2
> non-compliant metamodel, just to support the old-fashioned 2.0
> specification). If the new specification would imply just adding new
> features, there wouldn't be any problem, but this is not the case. We
> must seize the opportunity of stepping on a new major release to
>
> 1. Fix the current implementation problems which could imply API
> breakages.
> 2. Include API breakages which comes from the new specification changes,
> specially abstract and concrete syntax changes.
> 3. Include new features added the by the new specification.
>
> If we are not going to completely adopt the new OCL 2.2 specification,
> I'm sincerely doubting about the need of MDT-OCL 2.0.0 for Helios
> release. Just go on MDT 1.4.0 and let's add the new features which
> doesn't make us break API. However, as a pure MDT-OCL committer I don't
> share this point of view.
>
> About the extending languages like QVT (I guess it must be the main
> reason of your "fears").
> 1. I don't think that QVT Declarative, as same as MOF Model2Text
> (Acceleo), mustn't be worried about a new OCL language. Its abstract
> syntax doesn't extend OCL concepts.
> 2. I provide you some information about Mariano's wishes about QVT spec:
>
>
> ">>> About OCL 2.3 RTF. I guess that you will prioritize the QVT 1.1 RTF
> ? I guess that
>>>> we (Victor and me)'ll help you in this one before tackling OCL 2.3
> issues.
>>>> What do you think ?
>
> Yes, QVT 1.1 should be ready by end of October in order to be presented
> to the AB at the end of
> the year. So we have some hard work in QVT for the coming months.
> -Mariano".
>
> In any case, If you still want to support the old specification in
> Helios release, I would like to see ideas or start a discussion about
> how are we going to do it.
>
> Cheers,
> Adolfo.
>
> Alexander Igdalov escribi¨®:
>> Hi all,
>>
>> Clients that wish to work with the implementation of the OCL 2.0
>> standard will not be able to use MDT OCL 1.3.x in Helios+ releases. This
>> is because OCL 1.3 branch is for Galileo maintenance only and it would
>> be probably impossible to install 1.3 in Helios (for instance because of
>> incompatibility with the future versions of dependencies, e.g. EMF).
>> Therefore, we need to support both standards in MDT OCL 2.0.0. But I
>> think we should mainly focus on OCL 2.2 support. Since then IMO new
>> features should be added to the part of code which supports the latest
>> standard (or the shared part of code). The part of code responsible for
>> OCL 2.0 should be kept for backward compatibility. Thus IMO the latter
>> is to be updated only in case of very annoying bugs and issues like
>> compatibility with the latest EMF changes, etc.
>>
>> Cheers,
>> - Alex.
>> ________________________________________
>> §°§ä: mdt-ocl.dev-bounces@xxxxxxxxxxx [mdt-ocl.dev-bounces@xxxxxxxxxxx]
>> §à§ä §Ú§Þ§Ö§ß§Ú Laurent Goubet [laurent.goubet@xxxxxxx]
>> §°§ä§á§â§Ñ§Ó§Ý§Ö§ß§à: 1 §Ú§ð§Ý§ñ 2009 §Ô. 16:24
>> §¬§à§Þ§å: MDT OCL mailing list
>> §´§Ö§Þ§Ñ: Re: [mdt-ocl.dev] MDT 2.0.0 vs OMG 2.0 / 2.2?
>>
>> Hi,
>>
>> I'd also rather see us focus our efforts on supporting OCL 2.2 as best
>> as can be instead of splitting the dev between the adoption of this new
>> spec and the disambiguation/support of things that have changed since
>> OCL 2.0.
>>
>> The list of changes (as in "break") between the two versions might be
>> limited enough for us to maintain both version at small cost ... but if
>> this list becomes too large it will rapidly become an ordeal to make
>> changes towards the adoption of 2.2.
>>
>> Laurent
>>
>> Adolfo S¨¢nchez-Barbudo Herrera a ¨¦crit :
>>
>>> Relating the following bug https://bugs.eclipse.org/259031 recently
>>> replied by Ed.
>>>
>>> I'm confused. Are we going to support both specification versions in
>>> MDT-OCL 2.0.0?. I believe that it could be a chaos if we try tackle
>>> that challenge.
>>>
>>> I think that must clearly specify what are we going to do, and update
>>> the wiki with our ideas. We are 4 thinking heads who must align our
>>> thoughts in the same way...
>>>
>>> >From my point of view, we must bury OMG OCL 2.0 specification and
>>> change the implementation to adopt the new OCL 2.2 one. Keeping two
>>> implementations to support both specifications doesn't seem to be
>>> reasonable, in my opinion. If a client would like to use an OMG OCL
>>> 2.0 compliant implementation instead of the new one, he just have to
>>> use MDT OCL 1.3. What do you think?
>>>
>>> Cheers,
>>> Adolfo.
>>> --
>>>
>>>       *Adolfo S¨¢nchez-Barbudo Herrera*
>>> adolfosbh(at)opencanarias(dot)com
>>> <mailto:adolfosbh%28at%29opencanarias%28dot%29com>
>>> C/El¨ªas Ramos Gonz¨¢lez, 4, ofc. 304
>>> 38001 SANTA CRUZ DE TENERIFE
>>> Tel.: +34 922 240231 / +34 617 718268
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
> <mailto:adolfosbh%28at%29opencanarias%28dot%29com>
> C/El¨ªas Ramos Gonz¨¢lez, 4, ofc. 304
> 38001 SANTA CRUZ DE TENERIFE
> Tel.: +34 922 240231 / +34 617 718268
>
> _______________________________________________
> mdt-ocl.dev mailing list
> mdt-ocl.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
>