[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [m2m-dev] Need sub-lists
|
Hello,
In fact, ATL has ever its own mailing list:
https://dev.eclipse.org/mailman/listinfo/m2m-atl-dev
So, +1 for separated lists for QVTO and QVTR.
Best regards,
William
Ed Willink a écrit :
Hi All
We clearly have a serious problem with this list, as evidenced by the
attached correspondence.
We are all respecting the limited interest of various subscribers to
the detailed correspondence of individual projects and as a result
almost all technical discussions are happening off-list.
We need per-component sub-lists. I find it perverse that my very limited
participation GMT/UMLX sub-sub-project has its own list and newsgroup,
yet ATL and QVT and ... must share the same list/group.
Regards
Ed Willink
------------------------------------------------------------------------
Sujet:
Re: QVTo dependency on QVTr metamodel plugins
Expéditeur:
Ed Willink <ed@xxxxxxxxxxxxx>
Date:
Mon, 26 Jan 2009 09:09:54 +0000
Destinataire:
Adolfo Sanchez Barbudo <adolfosbh@xxxxxxxxxxxxxxxx>
Destinataire:
Adolfo Sanchez Barbudo <adolfosbh@xxxxxxxxxxxxxxxx>
Copie à:
Radek Dvorak <Radek.Dvorak@xxxxxxxxxxx>, Quentin Glineur
<quentin.glineur@xxxxxxx>
Hi Adolfo,
I would also consider the name space URIs of the metamodels (in
addition to the plugin versions) ;)
I'm not keep on this, since both 0.7.0 and 0.7.1 are aiming to be as
sensibly compliant with QVT 1.0 as possible.
Two different URIs would imply different structure and semantics. Note
that Ecore.ecore is still http://www.eclipse.org/emf/2002/Ecore even
though there were no generics in 2002!
If both 0.7.0 and 0.7.1 are available the platform should choose 0.7.1.
--------------------
All:
In the same way that Ecore adds utility operations such as
eAllClassifiers, it may be appropriate to add these to QVT as well.
Perhaps the main constraint on my doing this has been spelling.
For Ecore it was easy, everything with an e/E is not EMOF.
MDT-OCL and QVT use direct OMG spelling, so anything we add
could be a compatibility hindrance for QVT 1.1/2.0. I provided
a few such as
QVTBase::Transformation.getFunction(String name)
QVTBase::Transformation.getModelParameter(String name)
But since their availability is very patchy in M2M/QVT and not that
coherent in Ecore (where is EPackage.getSubPackage(name)? I tend
not to use them, preferring EcoreUtils.getNamedElement(list, name);
If you have an obviously useful and obviously safe set of suggestions
we might as well make them available.
----------------------
Radek:
In the last month or two I have been adding QVTBase, QVTTemplate,
QVTCore and QVTRelational validation. This is work in progress.
It shouldn't have much effect on QVTo since you don't use Patterns and
Predicates where most of my specification difficulties arise.
Regards
Ed Willink
------------------------------------------------------------------------
_______________________________________________
m2m-dev mailing list
m2m-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2m-dev
begin:vcard
fn:William Piers
n:Piers;William
org:Obeo
adr:2 rue Robert Schumann;;lot 24;NANTES;;44408;France
email;internet:william.piers@xxxxxxx
title:MDA Consultant
tel;work:+33 (0)2 51 13 51 82
tel;cell:+33 (0)6 20 31 75 98
url:http://www.obeo.fr
version:2.1
end:vcard