[
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 Ed,
find my answers inline.
Am 07.08.2009 um 18:24 schrieb Ed Willink:
Hi Jan
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.
I think we agree. This was rather my opinion when I tried to
understand EMF Index before starting to formulate an EMF Registry
proposal. Invited Sven amongst others to be a mentor. Sven felt that
there was an overlap, so I pursued communication with the EMF Index
project.
If you prefer, I will resurrect attempts to start an EMF Registry
project.
Yes, I'd recommend that.
However since locating models (EMF Registry) and exploiting them
(EMF Index) is so complementary, users might appreciate it if we
could combine the two functionalities in the one project. EMF Index
will surely benefit from a more flexible approach to defining model
location resolution.
For the EMF Index, there is no problem locating models as models are
merely identified by their resource URI. We have an API for traversing
resources given their URIs and a store API to feed the data into the
index. The resource URIs are provided from the outside, e.g. from a
project builder.
In the index, the resource URI is the primary key of a model, as the
fragment URI is for EObjects, etc. These keys should be absolute,
context-free and unique. This is an important consequence of EMFs
RESTful persistence architecture.
Your problem is a different one: Your models do not define their short
names themselves. They can be referred to in different ways from
different contexts, and, even worse, the same name could point to a
different model in a different context. As this might be exactly the
reason for the design of the registry, it spoils the idea of context-
freeness and uniqueness.
In addition, the two staged name<->model mapping does not seem to be
an EMF concept. It looks like originating from the mapping of the QVTD
spec to an EMF implementation. So it might be better kept within the
projects that need this functionality.
If nothing else, the name EMF Index appears to cover both
functionalities.
I'd disagree here. IMHO, the term index does not suggest that it
offers additional, contextual information on the indexed artifacts.
Rather than that it allows to find things easier. It's an optimization
thing, not a storage for decoration data.
I suspect that if each project were to evolve independently the
current clear functionlity distinction might blur, so a single
project could be better at avoiding duplicate inconsistent GUIs and
persistence.
For above reasons, I don't expect more overlaps in the future. Where
do you see GUI overlap?
With best regards
Jan
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
