Hi All,
I agree that OMG web page is a little bit confusing. It's also
confusing that when we were expecting to approve the OCL 2.1 version
specification, in the last minute the version number was changed to OCL
2.2. How knows, if they have decided to change the name again, although
I would bet that the final specification will be released with the 2.2
version number, specially when the OCL 2.3 RTF has been established in
the web page. In any case, I think that the 2.1 or 2.2 version number
is irrelevant at this moment.
I remember that most of the voters did their work (I could only add my
efforts against the second ballot). However, I can't certainly say if
they really read and/or understood the corrections. I can only speak
about myself, and I must say that all the second ballot issues were
supervised (which it doesn't mean that all the issues got the
correct/best resolution ;P).
About MDT-OCL 3.0.0. Sorry, I read about it, but I haven't said
anything. I think we must find an answer to the following questions:
Why MDT-OCL 1.3.0 has a plugin versioned as 2.0.0 (UML one). Is this
intentional, or just a Christian's mistake ?. Should have all the
plugins been versioned as 2.0.0. I guess that if we have an answer to
this question, we must get the clue of which version number must be
given to the MDT-OCL project in the Helios release:
If it's intentional/valid/correct: MDT-OCL 2.0.0 would have
org.eclipse.ocl and org.eclipse.ocl.ecore 2.0.0 plugins and
org.eclipse.ocl.uml 3.0.0 plugin.
If it's just a mistake: MDT-OCL 3.0.0 would have all their plugins in
the 3.0.0 version.
The last possibility is: In spite of being intentional/valid/correct,
we may want to have all the plugins in the 3.0.0 version. From my point
of view it's a little bit strange stepping from MDT-OCL 1.3.0 to
MDT-OCL 3.0.0. In any case, I think that we must be lighted by Kenn or
another PMC. I don't honestly know if there is any policy/guideline
relating to this issue.
Cheers,
Adolfo.
Ed Willink escribió:
Hi
This gets more confusing.
OMG->Members->Work In Progress now identifies the OCL 2.3 RTF. A
few days ago this was OCL 2.2 RTF.
The voting list deadline is passed, the public comment deadline is 10
April 2010.
OMG->Members->Issues leads to
http://www.omg.org/issues/ocl2-rtf.open.html
the
"Issues for OCL 2.2 Revision Task Force mailing list" from which the
2.1 resolutions have been pruned.
OMG->Specifications->UML...->OCL->Revision:Contact gets to
http://www.omg.org/techprocess/meetings/schedule/OCL_2_RTF.html
that identifies the OCL 2.1 RTF with a Beta 2 specification
just awaiting a Fax vote by 28th August. This resolves about 33% of the
issues. Neither 09-05-01
nor 09-05-02 provides a changebar free copy of the specification.
So I think that we will be implementing the OCL 2.1 in so far as
possible given the number of outstanding
issues. OCL 2.1 seems to be the next version, possibly released in
September.
No 2.2.
The next next OCL possibly in 2010 will be 2.3.
There is no point discussing issues resolved in 2.1. They are ballotted
and approved regardless
of how few people voted and even fewer understood their meaning.
I shall therefore probably raise new issues for null/invalid to avoid
confusion with resolved issues.
It would appear that the low level of member participation encourages
submissions that are formatted
as resolutions. This should increase our confidence in raising issues
that have a reasonable
prospect of adoption.
NB. Issue 13944: [OCL-2.1 RTF] Transitive closure operator (ocl2-rtf),
which I think everyone
can agree on. We could do it. Oops, reading on. Christian has already
implemented it and
provided a ProblemOption.CLOSURE_ITERATOR mechanism for switching it on
and off
by configuring the environment. This is similar to my extensibility
suggestions.
Adolfo: Have you had time to consider the discussion leading to MDT-OCL
3.0.0?
Regards
Ed Willink
_______________________________________________
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 |
|