[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [emfindex-dev] Contributing the QVT Declarative Model Registry to EMF Index
- From: Sven Efftinge <sven.efftinge@xxxxxxxxx>
- Date: Fri, 7 Aug 2009 09:11:05 +0200
- Delivered-to: email@example.com
Jan (the project lead) is currently trying to collect all kinds of
requirement in order to overwork the current API and implementation a
So it seems that now is a good time to make sure that your
requirements are supported.
I've put my thoughts inlined...
Tool support for OCL or QVTc or QVTr must perform a two level model
a) name to nominal URI
b) nominal URI to precise URI
In OCL a package context specifies a package name without specifying
where that package may be located.
In QVTc or QVTr a transformation references a meta-model name again
without specifying where that meta-model may be located.
The (originally UMLX) QVT Declarative Model Registry supports a) and
b) by prioviding a per-project set of registrations that are scoped
by resources (File or IResource), allowing a user to provide
registrations with project, folder or file granularity.
Registrations are defined for a chosen Model Accessor namespace, so
that Model Name registrations map from ad hoc name such as myUML to
nominal URI such http://my.uml, and URI registrations map from
nominal URI to precise URI e.g. platform://resources/myuml/model/
There is no nominal to precise URI mapping in our current
Could you please outline the use-case, so we can discuss this feature
The Model Name accessors are completely user defined.
The URI accessors enhance the built-in EPackage.Registry resolutions
with user defined mappings for models that need not be reified as
The registry is persisted as an EMF model in .settings/
The model in the current implementation is not backed-up by EMF
I think it would be good to have plain Java interfaces as API, leaving
it to the implementation whether you want to implement the model with
EMF. Jan mentioned that he likes the idea of having an EMF model,
because maintaining crossrefs and state would be easier because of the
observer pattern (adapters) and the managed references. On the other
hand I can imagine that people might want to have a very lazy model,
that is implementing it with proxies (I don't mean EMF proxies).
The GUI supports maintenance of registrations using a Property Page.
All the GUI stuff is still missing.
The API supports locating registrations and/or loading a resolution.
This functionality seems mostly complementary to EMF Index, so it
seems desirable to revise the current Model Registry code so that it
can be contributed to EMF Index. This will avoid migrating the QVT
Declarative Model Registry to MDT OCL as would be required to
support the migration of the OCL editor.
I guess that you'll have to do some kind of migration, because there
is already API and code.
But as I said initially you should look at the current code and try to
find out what's missing in order to support your use cases.