Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » EMF Facet proposal terminology clash
|
| Re: EMF Facet proposal terminology clash [message #529711 is a reply to message #529702] |
Mon, 26 April 2010 21:20   |
 Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Konstantin,
Good point. In the description of the project, the term "viewpoints" is
used. Perhaps "EMF viewpoints" is candidate name? Other words that seem
relevant are "virtual" or "derived" (class).
Hallvard
On 26.04.10 21.57, Konstantin Komissarchik wrote:
> Esteemed Colleagues,
>
> I am writing today as the lead of Eclipse Faceted Project Framework
> regarding the proposed EMF Facet project. I would like to express my
> concern over the choice of terminology used to describe this technology.
> The term "facet" has been in common use for several years now in the
> Eclipse Ecosystem to refer to project facets. The full "project facet"
> term is frequently shortened to just "facet". Further, it is common to
> describe specific facets for particular technologies using "[Technology]
> Facet" format, such as Java Facet or Spring Facet. My first reaction
> when I saw this proposal go by is that someone is proposing to create a
> project facet to configure a project for EMF work, which would be great,
> but is clearly now what this is about.
>
> I am very concerned that proceeding with the proposed terminology will
> create significant confusion in the ecosystem and would urge the parties
> involved with the proposed project to come up with different terminology.
>
> Sincerely,
>
> Konstantin Komissarchik
|
|
|
| Re: EMF Facet proposal terminology clash [message #529746 is a reply to message #529702] |
Tue, 27 April 2010 05:38 |
|
Hi Konstantin,
I don't have major stakes in this issue, but when I read your note I
thought "facet" is not a very specific term. If you use it as an
identifier for something you should probably be prepared that it has
potential for ambiguity. XSD for example uses the term facet as an
element restriction for a long time now. There is precedence for other
unspecific terms in Eclipse that are heavily overloaded, like adapter,
view, project, application, repository, etc.
Just out of curiosity, what would you think could an EMF facet in the
scope of your project do?
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 26.04.2010 21:57, schrieb Konstantin Komissarchik:
> Esteemed Colleagues,
>
> I am writing today as the lead of Eclipse Faceted Project Framework
> regarding the proposed EMF Facet project. I would like to express my
> concern over the choice of terminology used to describe this
> technology. The term "facet" has been in common use for several years
> now in the Eclipse Ecosystem to refer to project facets. The full
> "project facet" term is frequently shortened to just "facet". Further,
> it is common to describe specific facets for particular technologies
> using "[Technology] Facet" format, such as Java Facet or Spring Facet.
> My first reaction when I saw this proposal go by is that someone is
> proposing to create a project facet to configure a project for EMF
> work, which would be great, but is clearly now what this is about.
>
> I am very concerned that proceeding with the proposed terminology will
> create significant confusion in the ecosystem and would urge the
> parties involved with the proposed project to come up with different
> terminology.
>
> Sincerely,
>
> Konstantin Komissarchik
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: EMF Facet proposal terminology clash [message #529815 is a reply to message #529801] |
Tue, 27 April 2010 10:54 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Fred,
I agree that the term facet is used with analogous meaning. Nice
descriptive terms do tend to be reused in the software industry.
Certainly there is room for some confusion, e.g., one might model an
Eclipse project as an EMF object and then one might even model the
Eclipse facets of that Eclipse faceted Eclipse project with EMF facets
of that modeled EMF project object.
I personally don't like the word viewpoint because then one would end up
with views that view the viewpoint. I suppose aspect is another
possible term, but then a different project lead is likely to show up.
:-P Certainly if there were a better term, we should consider it...
Cheers,
Ed
Frederic Madiot wrote:
> Hi Constantin and Hallvard,
>
> Viewpoint and Facet are very close in their meaning.
>
> We chose "Facet" because "Viewpoint" is already widely used in the
> literature, but not always with the same meaning. Often it is
> associated with graphical aspects, and it not always deal with
> extensibility (it's mainly about subseting).
>
> We knew the Eclipse Faceted Project Framework and we think the
> concepts are similar. As one is relative to the project level, and the
> other to the model level, we don't think that it might be a confusion.
> At the opposite, we believe it could strengthen the understanding of
> what is a Facet.
>
> Regards,
>
> Fred
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: EMF Facet proposal terminology clash [message #529995 is a reply to message #529702] |
Wed, 28 April 2010 01:35 |
Konstantin Komissarchik
Messages: 1077
Registered: July 2009 |
Senior Member |
|
|
> I don't have major stakes in this issue, but when I read your
> note I thought "facet" is not a very specific term. If you use it as
> an identifier for something you should probably be prepared
> that it has potential for ambiguity. XSD for example uses the
> term facet as an element restriction for a long time now.
It is next to impossible to fully eliminate ambiguity in terms unless one is determined to just make up words. Having said that, common sense dictates certain rules when it comes to evaluating any choice of terminology. The general guideline, which you will find elaborated in depth in various places, including areas like trademark law goes something like this:
1. Is the term in use already?
2. If yes to #1, does the scope of existing use overlap significantly with the scope of proposed use?
In our case, the scope of use for project facets is limited to Eclipse Ecosystem, but you cannot really limit it further as it is a very generic framework that is applicable to any tooling that does something in a project. Certainly many things EMF are done in the context of a project, so we have a non-trivial overlap of scopes.
As I mentioned in my other post, it is not inconceivable that at some point in the future someone might want to create a project facet to configure project for EMF use. Such an entity would be called "EMF Facet". Further, it is not inconceivable that someone might want to create a facet around this proposed technology. Such thing would be called... wait for it... "EMF Facet Facet".
> Just out of curiosity, what would you think could an EMF facet
> in the scope of your project do?
Faceted project framework is potentially relevant to any project doing tools development. It helps the tooling author to let the user enable various functionality within a project in a uniform manner. Typical things that project facets do is configure builders, add items to classpath and lay down files.
> We knew the Eclipse Faceted Project Framework and we
> think the concepts are similar. As one is relative to the project
> level, and the other to the model level, we don't think that it
> might be a confusion. At the opposite, we believe it could
> strengthen the understanding of what is a Facet.
I do not see how intentionally creating terminology clash is a benefit. You will not be able to use the term without qualifying it fully and existing users of the term will have to start qualifying it. Lots of tongue-twisting that can be avoided by not overloading terms.
To add a bit more background to this, the original term for project facets was project features. That terminology choice was flagged as undesirable by the community due clash with eclipse features (as in feature.xml) and we went through the process of picking a new term and refactoring all the existing code accordingly.
Regards,
- Konstantin
|
|
|
| Re: EMF Facet proposal terminology clash [message #530003 is a reply to message #529995] |
Wed, 28 April 2010 05:09 |
|
Am 28.04.2010 03:35, schrieb Konstantin Komissarchik:
>> I don't have major stakes in this issue, but when I read your note I
>> thought "facet" is not a very specific term. If you use it as an
>> identifier for something you should probably be prepared that it has
>> potential for ambiguity. XSD for example uses the term facet as an
>> element restriction for a long time now.
>
> It is next to impossible to fully eliminate ambiguity in terms unless
> one is determined to just make up words. Having said that, common
> sense dictates certain rules when it comes to evaluating any choice of
> terminology. The general guideline, which you will find elaborated in
> depth in various places, including areas like trademark law goes
> something like this:
>
> 1. Is the term in use already? 2. If yes to #1, does the scope of
> existing use overlap significantly with the scope of proposed use?
>
> In our case, the scope of use for project facets is limited to Eclipse
> Ecosystem, but you cannot really limit it further as it is a very
> generic framework that is applicable to any tooling that does
> something in a project. Certainly many things EMF are done in the
> context of a project, so we have a non-trivial overlap of scopes.
Is that true? One scope is a project and the other is a model. A model
can be stored in a project, but doesn't have to.
>
> As I mentioned in my other post, it is not inconceivable that at some
> point in the future someone might want to create a project facet to
> configure project for EMF use. Such an entity would be called "EMF
> Facet". Further, it is not inconceivable that someone might want to
> create a facet around this proposed technology. Such thing would be
> called... wait for it... "EMF Facet Facet".
>
>> Just out of curiosity, what would you think could an EMF facet in the
>> scope of your project do?
>
> Faceted project framework is potentially relevant to any project doing
> tools development. It helps the tooling author to let the user enable
> various functionality within a project in a uniform manner. Typical
> things that project facets do is configure builders, add items to
> classpath and lay down files.
Can you explain how that differs from project natures?
>
>> We knew the Eclipse Faceted Project Framework and we think the
>> concepts are similar. As one is relative to the project level, and
>> the other to the model level, we don't think that it might be a
>> confusion. At the opposite, we believe it could strengthen the
>> understanding of what is a Facet.
>
> I do not see how intentionally creating terminology clash is a
> benefit. You will not be able to use the term without qualifying it fully
I think terms like nature or facet are so generic that they have to be
fully qualified with their scope anyway.
> and existing users of the term will have to start qualifying it. Lots
> of tongue-twisting that can be avoided by not overloading terms.
>
> To add a bit more background to this, the original term for project
> facets was project features. That terminology choice was flagged as
> undesirable by the community due clash with eclipse features (as in
> feature.xml) and we went through the process of picking a new term and
> refactoring all the existing code accordingly.
Choosing "feature" (as in feature.xml) was a poor choice in the first
place. "Composite Bundle" would have been better. But that's certainly a
different issue.
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> Regards,
>
> - Konstantin
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: EMF Facet proposal terminology clash [message #530313 is a reply to message #530182] |
Thu, 29 April 2010 10:17 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
There are all kinds of overloaded terms such as feature, property,
resource, and so on. Our industry is rife with such things. When you
use nice generic but description words it's inevitable that they will be
reused in this way. Should we have used a different word for an EMF
resource as opposed to a workspace resource? They're similar but not
identical. Perhaps it's confusing that both Ecore and Java have
classes, again they're similar but not identical. Of course within a
given context, such descriptive words will appear unqualified.
When we talk about facets while talking about XML Schema, we'll
understand them to be aspects that constrain a simple type definition.
When we talk about facets of a project's nature, we'll understand this
to be aspects of that projects nature. And when we talk about facets of
a modeled object, we'll understand them to be additional aspects
associated with that object. The term facet is used in somewhat an
analogous fashion in each case thought, they're really not so similar as
with resource and class. I don't see this is a significant source of
confusion to the communities at large...
Konstantin Komissarchik wrote:
>> Is that true? One scope is a project and the other is a model. A
>> model can be stored in a project, but doesn't have to.
>
> Just because models can be stored outside of project does not imply
> that there is no scope overlap. Many things EMF deal with project,
> ergo there is significant scope overlap.
>
>> I think terms like nature or facet are so generic that they have to
>> be fully qualified with their scope anyway.
>
> Indeed they are generic as they are English words, but within their
> scopes they are fairly unambiguous. If you say "nature" in Eclipse
> context, everyone knows what you are talking about. There is no need
> to qualify unless you talking to someone outside Eclipse context. Same
> thing regarding facets, excepts facets are a bit less known right now
> than natures.
> There is no need for a new technology to intentionally overload terms
> already in use. There are plenty of words in the English language.
>
> See this blog post about EMF Facet project...
>
> http://fmadiot.blogspot.com/2010/04/emf-facet-new-project-fo r-model.html
>
> Count how many times "facet" is used unqualified in that post. The
> post is even tagged with "facet". Does the community really benefit
> from this?
>
> - Konstantin
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | | | |
| Re: EMF Facet proposal terminology clash [message #530806 is a reply to message #530777] |
Sat, 01 May 2010 07:58 |
|
Hi Konstantin,
As far as I understand it only the leads of the proposed project can
make a final decision on this issue. All the others that added to the
discussion only expressed their personal opinions or arguments. I for my
part don't really see my arguments being made invalid. I think there
must be a balance between name/scope confusion/ambiguity on the one side
and nice and descriptive naming of a project on the other side. In this
particular case I, personally, don't see that a lot of people would
really suffer from a potential ambiguity of the term facet. And if there
is a handful of such people they can easily resolve the conflict by
properly scoping the term. Hence asking the EMF Facet team to choose a
suboptimal name for their project is not justified. As I said, it's just
my opinion and certainly not an objective truth.
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 30.04.2010 21:39, schrieb Konstantin Komissarchik:
> Ed,
>
> You are the one who is choosing to take offense, making it personal
> and shutting down the discussion. I did not call you dishonest. I
> called into question intellectual honesty of statements that were made
> to justify your position. I then proceeded to backup that claim. You
> chose to take offense instead of refuting any points that I made.
>
> I am frustrated and I am sorry that you are offended by that, but what
> I am seeing is indifference in this community to damage that is about
> to be done to work of others.
> The rest of EMF community,
>
> Ed seems to not be interested in continuing this discussion and
> resolving this issue. Other voices have been silent for a while now on
> this thread. Should I consider Ed's word final on this issue and take
> my arguments elsewhere or is there anyone else that is still
> interested in digging deeper into this issue resolving the problem on
> this thread.
>
> - Konstantin
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: EMF Facet proposal terminology clash [message #530828 is a reply to message #530777] |
Sat, 01 May 2010 11:44 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Hi,
I'd like to reflect on the topic of naming projects. I recently met this
problem myself, when trying to find the "best" name for Javascript
integration with EMF. I've always been referring to it as EMF
Javascript, but when proposing it as a standalone Eclipse project, I
thought I should rethink the name. And since EMF Javascript could be
interpreted as an EMF model of Javascript, rather than Javascript used
for defining behavior for EMF, I renamed it to Javascript for EMF,
shortened JS4EMF.
How is this relevant for this discussion? Well, the point is
understanding how different groups of people may interpret the name and
how that affects the success of the project and the community as a
whole. Konstantin has explained how the name "EMF Facet" may be
interpreted by someone interested in/concerned about Eclipse project
facets. EMF people have argued that Facet is a good name for what the
project provides and that other terms may be too narrow or misleading.
Although I did suggest that we should look for a different term, I
accept that "facet" as best.
One possibility is qualifying the project name to avoid confusion, e.g.
use "EMF model facet" to distinguish it from "EMF project facet". For an
EMF'er adding "model" to the name sounds strange, e.g. EMF Compare is
obviously model comparison, so you don't need to call it EMF model
compare. It's as of an "EMF" prefix adds a "model" qualifier to the name.
Is it reasonable to assume that non-EMF'er also first think of an EMF
project as being about modeling? I think so. In addition, the "facet"
term has a natural interpretation in the context of models and there is
little general awareness of the "project facet" concept (like it or
not). On the other hand, I would guess "EMF nature" would be interpreted
as referring to project natures, since the awareness of project natures
is fairly high. Nevertheless, I think the risk of confusion is low, as
seen from EMF's side.
What's unclear to me is what harm confusion will do to the Eclipse
community as a whole. If I generalize from myself (which always is easy,
but dangerous), I'd say that my low awareness of project facets (and
fairly high awareness of project natures) indicates that the harm is
low. However, it may harm the awareness of the project facet concept,
which may be why Konstantin seems frustrated.
My conclusion: 1) Use the name EMF facet. 2) Reserve the name Project
facet for EMF for, you guessed it, a project facet for EMF.
Hallvard
|
|
|
| Re: EMF Facet proposal terminology clash [message #530854 is a reply to message #530777] |
Sat, 01 May 2010 21:45 |
Frederic Madiot
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
Konstantin,
As the submitter of the project, my objective was not to cause such a controversy 
Finding the right name is important for a component and a project. We think Facet is the right one, and it took time to select this name.
The first name we have imagined during the specification phase was Derived Metamodel Extension. When we started to code, we found the name too long, and DME was not clear, that's why we renamed the concept to Role (see : MoDisco presentation at ESE2009 ( http://www.eclipse.org/gmt/modisco/doc/MoDisco-ESE2009-Sympo sium/demo.htm). Because the mechanism was difficult to explain with this name, again we changed the name (see http://www.eclipse.org/forums/index.php?t=msg&th=161130& amp; amp;start=0&) which costed us a lot of refactoring. To find this new name, we hesitated with lots of other names (viewpoint, face, prism, scope, nature, aspect, avatar, extension, ...). Now, with Facet, we have noticed that the component is much easier to understand. Also, there are already other projects using this component (the Papyrus project for example). For these two reasons we won't change the name again.
And honestly, we don't believe that the Facet term could cause confusion in the Eclipse community at large and harm your project:
- the scope is different (Model vs Project).
- the concept is similar (extend and customize an existing artifact).
And if someone creates a Project Facet for EMF projects, a name such as EMFProjectFacet will not be ambiguous.
Best regards,
Fred
[Updated on: Sun, 02 May 2010 19:42] Report message to a moderator |
|
| |
| Re: EMF Facet proposal terminology clash [message #622511 is a reply to message #529801] |
Tue, 27 April 2010 10:54 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Fred,
I agree that the term facet is used with analogous meaning. Nice
descriptive terms do tend to be reused in the software industry.
Certainly there is room for some confusion, e.g., one might model an
Eclipse project as an EMF object and then one might even model the
Eclipse facets of that Eclipse faceted Eclipse project with EMF facets
of that modeled EMF project object.
I personally don't like the word viewpoint because then one would end up
with views that view the viewpoint. I suppose aspect is another
possible term, but then a different project lead is likely to show up.
:-P Certainly if there were a better term, we should consider it...
Cheers,
Ed
Frederic Madiot wrote:
> Hi Constantin and Hallvard,
>
> Viewpoint and Facet are very close in their meaning.
>
> We chose "Facet" because "Viewpoint" is already widely used in the
> literature, but not always with the same meaning. Often it is
> associated with graphical aspects, and it not always deal with
> extensibility (it's mainly about subseting).
>
> We knew the Eclipse Faceted Project Framework and we think the
> concepts are similar. As one is relative to the project level, and the
> other to the model level, we don't think that it might be a confusion.
> At the opposite, we believe it could strengthen the understanding of
> what is a Facet.
>
> Regards,
>
> Fred
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
| Re: EMF Facet proposal terminology clash [message #622521 is a reply to message #622519] |
Thu, 29 April 2010 10:17 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
There are all kinds of overloaded terms such as feature, property,
resource, and so on. Our industry is rife with such things. When you
use nice generic but description words it's inevitable that they will be
reused in this way. Should we have used a different word for an EMF
resource as opposed to a workspace resource? They're similar but not
identical. Perhaps it's confusing that both Ecore and Java have
classes, again they're similar but not identical. Of course within a
given context, such descriptive words will appear unqualified.
When we talk about facets while talking about XML Schema, we'll
understand them to be aspects that constrain a simple type definition.
When we talk about facets of a project's nature, we'll understand this
to be aspects of that projects nature. And when we talk about facets of
a modeled object, we'll understand them to be additional aspects
associated with that object. The term facet is used in somewhat an
analogous fashion in each case thought, they're really not so similar as
with resource and class. I don't see this is a significant source of
confusion to the communities at large...
Konstantin Komissarchik wrote:
>> Is that true? One scope is a project and the other is a model. A
>> model can be stored in a project, but doesn't have to.
>
> Just because models can be stored outside of project does not imply
> that there is no scope overlap. Many things EMF deal with project,
> ergo there is significant scope overlap.
>
>> I think terms like nature or facet are so generic that they have to
>> be fully qualified with their scope anyway.
>
> Indeed they are generic as they are English words, but within their
> scopes they are fairly unambiguous. If you say "nature" in Eclipse
> context, everyone knows what you are talking about. There is no need
> to qualify unless you talking to someone outside Eclipse context. Same
> thing regarding facets, excepts facets are a bit less known right now
> than natures.
> There is no need for a new technology to intentionally overload terms
> already in use. There are plenty of words in the English language.
>
> See this blog post about EMF Facet project...
>
> http://fmadiot.blogspot.com/2010/04/emf-facet-new-project-fo r-model.html
>
> Count how many times "facet" is used unqualified in that post. The
> post is even tagged with "facet". Does the community really benefit
> from this?
>
> - Konstantin
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | | | |
| Re: EMF Facet proposal terminology clash [message #622539 is a reply to message #530777] |
Sat, 01 May 2010 07:58 |
|
Hi Konstantin,
As far as I understand it only the leads of the proposed project can
make a final decision on this issue. All the others that added to the
discussion only expressed their personal opinions or arguments. I for my
part don't really see my arguments being made invalid. I think there
must be a balance between name/scope confusion/ambiguity on the one side
and nice and descriptive naming of a project on the other side. In this
particular case I, personally, don't see that a lot of people would
really suffer from a potential ambiguity of the term facet. And if there
is a handful of such people they can easily resolve the conflict by
properly scoping the term. Hence asking the EMF Facet team to choose a
suboptimal name for their project is not justified. As I said, it's just
my opinion and certainly not an objective truth.
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 30.04.2010 21:39, schrieb Konstantin Komissarchik:
> Ed,
>
> You are the one who is choosing to take offense, making it personal
> and shutting down the discussion. I did not call you dishonest. I
> called into question intellectual honesty of statements that were made
> to justify your position. I then proceeded to backup that claim. You
> chose to take offense instead of refuting any points that I made.
>
> I am frustrated and I am sorry that you are offended by that, but what
> I am seeing is indifference in this community to damage that is about
> to be done to work of others.
> The rest of EMF community,
>
> Ed seems to not be interested in continuing this discussion and
> resolving this issue. Other voices have been silent for a while now on
> this thread. Should I consider Ed's word final on this issue and take
> my arguments elsewhere or is there anyone else that is still
> interested in digging deeper into this issue resolving the problem on
> this thread.
>
> - Konstantin
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: EMF Facet proposal terminology clash [message #622540 is a reply to message #530777] |
Sat, 01 May 2010 11:44 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Hi,
I'd like to reflect on the topic of naming projects. I recently met this
problem myself, when trying to find the "best" name for Javascript
integration with EMF. I've always been referring to it as EMF
Javascript, but when proposing it as a standalone Eclipse project, I
thought I should rethink the name. And since EMF Javascript could be
interpreted as an EMF model of Javascript, rather than Javascript used
for defining behavior for EMF, I renamed it to Javascript for EMF,
shortened JS4EMF.
How is this relevant for this discussion? Well, the point is
understanding how different groups of people may interpret the name and
how that affects the success of the project and the community as a
whole. Konstantin has explained how the name "EMF Facet" may be
interpreted by someone interested in/concerned about Eclipse project
facets. EMF people have argued that Facet is a good name for what the
project provides and that other terms may be too narrow or misleading.
Although I did suggest that we should look for a different term, I
accept that "facet" as best.
One possibility is qualifying the project name to avoid confusion, e.g.
use "EMF model facet" to distinguish it from "EMF project facet". For an
EMF'er adding "model" to the name sounds strange, e.g. EMF Compare is
obviously model comparison, so you don't need to call it EMF model
compare. It's as of an "EMF" prefix adds a "model" qualifier to the name.
Is it reasonable to assume that non-EMF'er also first think of an EMF
project as being about modeling? I think so. In addition, the "facet"
term has a natural interpretation in the context of models and there is
little general awareness of the "project facet" concept (like it or
not). On the other hand, I would guess "EMF nature" would be interpreted
as referring to project natures, since the awareness of project natures
is fairly high. Nevertheless, I think the risk of confusion is low, as
seen from EMF's side.
What's unclear to me is what harm confusion will do to the Eclipse
community as a whole. If I generalize from myself (which always is easy,
but dangerous), I'd say that my low awareness of project facets (and
fairly high awareness of project natures) indicates that the harm is
low. However, it may harm the awareness of the project facet concept,
which may be why Konstantin seems frustrated.
My conclusion: 1) Use the name EMF facet. 2) Reserve the name Project
facet for EMF for, you guessed it, a project facet for EMF.
Hallvard
|
|
|
| Re: EMF Facet proposal terminology clash [message #622541 is a reply to message #530777] |
Sat, 01 May 2010 21:45 |
Frederic Madiot
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
Konstantin,
As the submitter of the project, my objective was not to cause such a controversy :(
Finding the right name is important for a component and a project. We think Facet is the right one, and it took time to select this name.
The first name we have imagined during the specification phase was Derived Metamodel Extension. When we started to code, we found the name too long, and DME was not clear, that's why we renamed the concept to Role (see : MoDisco presentation at ESE2009 ( http://www.eclipse.org/gmt/modisco/doc/MoDisco-ESE2009-Sympo sium/demo.htm). Because the mechanism was difficult to explain with this name, again we changed the name (see http://www.eclipse.org/forums/index.php?t=msg&th=161130& amp;start=0&) which costed us a lot of refactoring. To find this new name, we hesitated with lots of other names (viewpoint, face, prism, scope, nature, aspect, avatar, extension, ...). Now, with Facet, we have noticed that the component is much easier to understand. Also, there is already other projects using this component (the Papyrus project for example). For these two reasons we won't change the name again.
And honestly, we don't believe that the Facet term could cause confusion in the Eclipse community at large and harm your project:
- the scope is different (Model vs Project).
- the concept is similar (extend and customize an existing artifact).
And if someone creates a Project Facet for EMF projects, a name such as EMFProjectFacet will not be ambiguous.
Best regards,
Fred
|
|
|
Goto Forum:
Current Time: Tue Apr 16 07:53:52 GMT 2024
Powered by FUDForum. Page generated in 0.73344 seconds |
] 
Search
Help
Register
Login
Home
