[
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,
let me try to summarize:
* To resolve meta-models in QVT, you need to map userDefined names to
nominal URIs and nominal URIs to precise URIs that actually allow the
loading of meta-models (EMOF and Ecore).
* As the EPackage.Registry is not made for models residing in the
workspace, you need an intermediary layer treating registered meta-
models and the ones residing in the workspace the same way.
So how could that refer to the EMF Index
1) Use the index to access the mapping data, as the mapping is defined
in an EMF model.
I see no benefit here, as you already have mapping models and you
know where to find them. So why not load them directly?
2) Skip the mapping model and use the index do the nominal URI (I
suppose that's the nsURI in the case of Ecore) to precise URI mapping.
That could be achieved by registering a ResourceIndexer for .ecore
files. A query for an EPackage by its nsURI will return a descriptor
that is a handle to that EPackage. The index builder will
automatically synchronize on changes of the ecore models. Some issues
remain:
- You'd also have to put the information from the
EPackage.Registry in the index to have a uniform API for registered
and workspace residing models. We have just discussed that this is
likely a bad idea.
- We haven't tried EMF Index with non-Ecore based models yet.
- The name to nominal name mapping is still to be solved. In the
case of Ecore models you could take the EPackage name as the user name
(as we currently do in Xpand), loosing the flexibility to change it
without touching the meta-model.
So maybe there is a small misunderstanding about the nature of the EMF
Index. The index is not intended to store any information that cannot
be derived from the models themselves. That's why the API does not
define where or how the index data is persisted. The upcoming GUI will
focus on queries rather than manipulating data in the index. The main
purpose of the EMF Index is to locate model elements fulfilling a
given set of criteria without loading resources.
So to be honest, I currently see very little overlap between your meta-
model registry and EMF Index, but it's likely I missed something.
Best regards
Jan
Am 07.08.2009 um 10:23 schrieb Ed Willink:
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
_______________________________________________
emfindex-dev mailing list
emfindex-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emfindex-dev
--
Dr. Jan Köhnlein
Senior Software Architekt
Telefon: +49 (0) 431 / 5606-337
Mobile: +49 (0) 151 / 17396687
Telefax: +49 (0) 431 / 5606-339
http://www.itemis.de
jan.koehnlein@xxxxxxxxx
itemis AG
Niederlassung Kiel
Schauenburgerstr. 116
24118 Kiel
http://www.itemis.de/
Rechtlicher Hinweis:
Registergericht: Amtsgericht Dortmund HRB 20621
Sitz der Gesellschaft: Lünen
Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vorsitzender), Stephan
Grollmann, Michael Neuhaus
