5 Comments

1. 

   jordi on February 10, 2011 at 4:32 am

   I’m NOT sure about “usable”, “coherent description”, “consolidated” terms mean FOR your reader. IN principle, the provided issues web page lists the solved issues, SOME discussions about the issue, how the issue IS disposed (resolved, DEFERRED, duplicate, closed NO change ) AND what has been changed IN the document (revised text).

   The RTF also manages a doc TO be used by us during the voting period. I think that it’s not publicly available but It mostly contains the same information which is later copy-pasted in the public issues web page.

   The issues web page probably need much more editorial improvements (I don’t really know how this IS managed), nevertheless, it contains ALL the information which implementors must know.

   On the one hand, the same metamodel has been used AND modified during MDT/OCL evolution (AT least since I’ve been dealing with it, since 4 years ago), at the same time it tries to follow some Eclipse API evolution policies.

   However, Ed has developed a new experimental metamodel based on the pivot metamodel idea (which I think you already know) which is actually available in our last Eclipse Indigo’s M5 milestone which we published LAST week.

   Reply
2. 

   jordi on February 10, 2011 at 4:33 am

   Some reply comments from Ed Willink and Adolfo-Sánchez Barbudo. Given their excellent work in the MDT-OCL component I thought they could have some input on this issue.

   Reply
3. 

   jordi on February 10, 2011 at 4:39 am

   Read the RTF report. If you care about effectively trivial changes, then you care about the details. Most obviously Collection conforms to OclAny, the String/OrderedSet library grew a bit and a number of typos were corrected or moved.

   Neither OCL 2.0 nor OCL 2.2 is implementable. Fortunately the ‘intent’ is ‘obvious’ and implementations are useful. Perhaps OCL 2.2 introduced as many problems as it cured. OCL 2.3 perhaps cures 10% of the unimplementable problems. OCL 2.4 might cure all, well ok 90% of the fundamental problems.

   Until it’s implementable, compatibility IS NOT a big issue.
   OCL 2.4 may migrate the bulk OF the semantics TO a Standard Library Model FOR which each version AND derived LANGUAGE can have model-defined differences.OCL 2.4 may also align WITH UML AND so may define its models AS a transformation/merge FROM UML.

   Eclipse OCL may THEN provide alternate variants, OR a superset WITH configured subset validation; we’ll see.

   Reply
4. 

   Andreas on February 10, 2011 at 12:33 pm

   Hello Jordi,

   thanks for your time and energy.

   I saw two problems with the issues page:

   • It seems not to cover all the changes. For example, I could not found issues covering the new OCL standard library methods.
   • I was not sure, in which version a given issue was detected. In the official 2.0 spec? In some interim version that was never published?

   Regarding implementability:
   Since Oclarity is just a static checker and not a interpreter/evaluator that is not so important to me.
   Further, I would not mind if – in an interpreter/evaluator – I would have to restrict some functionality because it cannot be implemented reasonably. I just would like to make that a conscious decision and document it appropriately.

   I think I have three choices now:

   1. Just implement the new library methods, because that is what users of Oclarity are actually interested in. However, this creates a mix between the two versions, making the expressions potentially non portable.
   2. Go the hard way and try to use some pdf diff tool and manually track all the changes.
   3. Do nothing and wait until more users ask for OCL 2.2 support and then reconsider.

   I think the most reasonable choice would be 3.

   Regards,
   Andreas

   Reply
5. 

   jordi on February 10, 2011 at 2:49 pm

   I definitely think that OPTION 3 IS the best one

   Reply