[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [emfindex-dev] Contributing the QVT Declarative Model Registry to EMF Index
|
Hi Sven
Hi Ed,
Jan (the project lead) is currently trying to collect all kinds of
requirement in order to overwork the current API and implementation a
bit.
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
name resolution.
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/uml.ecore.
There is no nominal to precise URI mapping in our current implementation.
Could you please outline the use-case, so we can discuss this feature
further?
I am sure that half the nominal-URI to precise-URI functionality is
already because there are two use cases.
I want to resolve a nominal URI to a precise URI that is needed for
getResource to succeed.
a) The precise URI is a registered EMF model. I think Ecore can now
register the .ecore, though in the
past my enhanced Browse Workspace... deduced .ecore as siblings of
.genmodel.
b) The precise URI is my own meta-model whose existence is solely an
.ecore file in
my current workspace. EMF does not support this use of non-Java
genmodelled models, for which no plugin registration can occur.
Arguably what I require for the above is just a modeling-time user
configurable URI resolver.
The model-name:nominal-uri resolver is just a generalisation to support
multiple resolution domains that I called Model Accessors.
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
Java code.
The registry is persisted as an EMF model in
.settings/org.eclipse.qvt.declarative.modelregistry
The model in the current implementation is not backed-up by EMF
implementation.
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).
Perhaps I should leave this discussion to the team. Perhaps I can
observe that it is odd for a modelling project not to use a model for
its public data API.
How can I write a transformation that uses the registry as input or
output if there is no UML/EMOF/Ecore/... meta-model for it?
From a configuration management point of view I find it very
unsatisfactory for project-specific registrations to be persisted
anywhere other than within the project tree; i.e. somewhere in
.settings. How else do I check the registrations into CVS so that my
colleague shares them?
The GUI supports maintenance of registrations using a Property Page.
All the GUI stuff is still missing.
Perhaps my stuff may provide a bootstrap.
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.
I'm not worried whether my code is used or not. I just need the
model-name:nominal-URI and nominal-URI:precise-URI mapping to be
available in configurable form for MDT/OCL and M2M/QVT Declarative for
Helios and I hope that we can provide a neutral solution that supports
all modeling projects so that users can solve all their model
registration problems in a single place rather than in a different way
for each tool.
I looked at the code and it appeared that I could write my own Indexer
that could exploit some of the EMF Index APIs. However if it's my own
Indexer, I just trade one set of custom classes for another with an
extra dependency, so why bother? It is only if there is a standard EMF
Index Indexer that I succeed in sharing my functionality. I think EMF
Index needs to provide abstract APIs and a concrete extensible
implementation that hopefully satisfies basic model reference resolution
requirements.
So what I think is missing: [a prototype is available for a), b), c)]
a) A registry that is persisted as a model within the project
b) A registry information model that supports user defined registrations
c) A GUI to maintain that information model
d) [Refinement of the existing EMF Index API to support the refined
registry.]
NB. My current interests are solely in Resource and EPackage resolution
and loading from vague names, which is a complementary but different
problem to finer grained queries within resolved models.
Regards
Ed Willink