[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [gmt-dev] GMT Framework Proposal
|
Hi All
>Do you think that it is appropriate to label your document "GMT Framework
>Proposal"
Yes. A proposal is for discussion. We have made disappointing progress
within the team,
it is time for some other opinions. If enough people like my proposal, it is
simple
enough to go ahead single handed and probably have it useful by the New
Year.
When there is a consistent and flexible alternative with the capability to
accommodate the meta-model anarchy that will exist for the next five years,
I'll be happy to consider it.
> without first talking to the GMT project leaders?
We talked at OOPSLA to no avail and ... off-list.
> > > Secondly you totally ignore the workflow component that you saw at
> OOPSLA,
> > > which forms the backbone of the GMT platform.
Apologies. I could have made the proposal thicker. I could have stated more
explicitly that the Fuutje plug-in(s) would incorporate our current
achievements.
> > > For GMT we
> are taking a
> > > standards-based approach to workflow that is consistent with
> > > http://www.wfmc.org.
We have agreed that WFMC provides one interesting definition of workflow.
However
there is certainly no agreement that what I perceive to be a rather business
oriented
specification be imposed on the software community. My proposal accommodates
WfMC for those who like it and UML2 activity diagrams for those who like
those and ....
With regard to WfMC in particular we have the problem that data types (meta
models)
are very poorly represented.
> > I saw the workflow component at OOPSLA. While I consider
> > it useful, it is - I think - a second step. Firstly, we need to get
> > some transfromations (or at least code generations) working.
> > Once we have 20 different transformation languages and
> > activities, we can add the workflow aspect to combine them.
Absolutely. Let's get some easier stuff working in a framework that can
expand.
Whether workflow is or is not a glorified transformation may be a matter of
belief.
If it is a meta-level transformation, then support is easy. If not, then we
add support.
> .... Besides Ed, we've got several other
> parties who would
> like to contribute preliminary QVT implementations to GMT.
> This will only
> work if we first focus on a platform that allows all these
> transformation
> components to interoperate.
Indeed, and one is not interested till we support EMF while another requires
that
we take their code as is. My proposal accommodates this very easily.
> This approach will allow GMT to scale quickly in terms of
> contributers and
> available functionality. Of course the first version of the workflow
> component doesn't have to have all the bells and whistles, so
> we're starting
> small. Further down the track we may then can provide the
> option to replace
> the minimal, GMT specific workflow component with a more advanced WFMC
> compliant open source or commercial workflow component.
>
Herein lies the dilemma. On the one hand a WFMC short term, that at least at
OOPSLA was a long way away from making any use of Eclipse, and which can be
replaced,
against an open Eclipse plug-in framework into which anything can be
accommodated
from the outset.
But actually there's is no dilemma at all. My proposal has the flexibility
to
support the WFMC direction, and other directions too.
Regards
Ed Willink
------------------------------------------------------------------------
E.D.Willink, Email: mailto:EdWillink@xxxxxxx
Thales Research and Technology (UK) Ltd, Tel: +44 118 923 8278 (direct)
Worton Drive, or +44 118 986 8601 (ext 8278)
Worton Grange Business Park, Fax: +44 118 923 8399
Reading, RG2 0SB
ENGLAND http://www.computing.surrey.ac.uk/personal/pg/E.Willink
------------------------------------------------------------------------
(formerly Racal Research and Thomson-CSF)
