Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » EMF Facet proposal terminology clash
|
| Re: EMF Facet proposal terminology clash [message #622504 is a reply to message #622503] |
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 #622507 is a reply to message #622503] |
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 #622516 is a reply to message #622503] |
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 #622517 is a reply to message #622516] |
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
|
|
|
Goto Forum:
Current Time: Thu Apr 25 16:44:50 GMT 2024
Powered by FUDForum. Page generated in 0.03656 seconds |
] 
Search
Help
Register
Login
Home
