Home » Modeling » EMF » Are Change.ecore, UML.ecore and bpmn.ecore valid?
|
| Re: Are Change.ecore, UML.ecore and bpmn.ecore valid? [message #845609 is a reply to message #841475] |
Sun, 15 April 2012 08:07   |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Ed,
Comments below.
On 11/04/2012 1:06 PM, Ed Willink wrote:
> Hi Ed
>
> You may recall that I prompted a revision of Ecore.ecore to avoid
> mixed model references, and a further revision to avoid a mixed
> reference that crept in with eInvoke.
Yes.
>
> A user on the OCL group has had trouble with bpmn.ecore, which I
> didn't have a copy of, but found that I could reproduce the problem
> with Change.ecore. On further examination I found a problem with
> UML.ecore too:
>
> <eClassifiers xsi:type="ecore:EClass" name="Element" abstract="true"
> eSuperTypes="platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#//EModelElement">
For referencing an EClass it's very important to use the real serialize
development time version because that has all the settings used to
generate the real code.
> <eOperations name="not_own_self" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EBoolean">
For data types it's okay to use the generated model instance because
there aren't GenModel settings that affect how it's used.
>
> There seems to be a widespread default behaviour that EDataTypes come
> from http://www.eclipse.org/emf/2002/Ecore
Yes, that's allowed.
> whereas EClasses come from
> platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore.
Yes, that's necessary.
> These are not necessarily the same Resource and so an opportunity for
> meta-model schizophrenia arises.
You make this sound like a medical condition which is unfortunate...
> Using the Sample Ecore Editor and examining the user resource conforms
> that some references terminate in the Java model while other use a
> loaded model.
There really are different artifacts.
> Is this just confusing and unhelpful or something much nastier?
There haven't exactly been a flood of complaints about it...
>
> It would seem that a reasonable well formedness rule for Ecore could be.
So you're suggesting we make new rules that make existing models invalid?
>
> allRootResources = all Resources containing any element transitively
> referenced by the user model
> allEPackages = all EPackage transitively contained by allRootResources
> allNsURIs = the List of all EPackage.nsURI in allEPackages
> allNsURIs contains no duplicates (perhaps ignoring blank nsURIs).
This sounds like a rule that makes things Ecore models invalid depending
on context but the problem isn't with the Ecore files it's a contextual
thing.
>
> NB references to meta-elements are ignored allowing Ecore to be
> consistently defined using 'another' Ecore as its meta-class.
Ignored by whom?
>
> The above WFR would give a validation for failure for UML.ecore, which
> once fixed would reduce the opportunities for schizophrenia.
Forcing all models that use built-in data types to change, which is
pretty much all models period, sounds like a non-starter suggestion for me.
>
> Regards
>
> Ed Willink
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Are Change.ecore, UML.ecore and bpmn.ecore valid? [message #845668 is a reply to message #845609] |
Sun, 15 April 2012 09:30 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
Thanks; that conforms my observations. Clearly with almost intentional
dual model use a single model WFR is troublesome.
There certainly isn't a flood of complaints in the edit Ecore + genmodel
world, since this is a closed environment which until recently (? Juno
M3) didn't have a standalone option.
There is a steady stream of bewildered users in the model transformation
world, which is often standalone. Users variously encounter a total
failure to use a model at all through difficulties of getting manual
model registrations right and misguided tool-specific attempts to make
platform: relative access (from Eclipse model editing tools) work as if
it were file: relative (for naive standalone usage). If users get the
models loaded they sometimes manage to load two meta-models; one
accessed by the 'program' transformation/OCL rules and another
instantiated by the model. With distinct models, simple tests such is b
an instanceof B may fail, because b is an instance of B but a different B.
In the genmodel world it does not seem to matter that EDataTypes and
EClasses are instantiated from different EPackage instances with the
same nsURI; in the tx world it does.
I've been toying with writing a blog on how URIs work, but have held
back because I don't understand the misguided tool-specifics.
My ProjectMap contribution in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=361063 might establish a
level playing field so that standalone is the same as Eclipse-running,
which might then allow tools to work with EMF URIs rather than fight
them. Until then I think users just need to be patient and lucky unless
they've got a good example to copy. With GIT fragmenting non-trivial
workspaces, many of the old treat-platform:-as-a-file: approaches fail
badly.
(For OCL I'm taking the view that multiple packages with the same
non-blank nsURI are to be merged.)
Regards
Ed Willink
On 15/04/2012 09:07, Ed Merks wrote:
> Ed,
>
> Comments below.
>
> On 11/04/2012 1:06 PM, Ed Willink wrote:
>> Hi Ed
>>
>> You may recall that I prompted a revision of Ecore.ecore to avoid
>> mixed model references, and a further revision to avoid a mixed
>> reference that crept in with eInvoke.
> Yes.
>>
>> A user on the OCL group has had trouble with bpmn.ecore, which I
>> didn't have a copy of, but found that I could reproduce the problem
>> with Change.ecore. On further examination I found a problem with
>> UML.ecore too:
>>
>> <eClassifiers xsi:type="ecore:EClass" name="Element" abstract="true"
>> eSuperTypes="platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#//EModelElement">
> For referencing an EClass it's very important to use the real
> serialize development time version because that has all the settings
> used to generate the real code.
>> <eOperations name="not_own_self" eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EBoolean">
> For data types it's okay to use the generated model instance because
> there aren't GenModel settings that affect how it's used.
>>
>> There seems to be a widespread default behaviour that EDataTypes come
>> from http://www.eclipse.org/emf/2002/Ecore
> Yes, that's allowed.
>> whereas EClasses come from
>> platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore.
> Yes, that's necessary.
>> These are not necessarily the same Resource and so an opportunity for
>> meta-model schizophrenia arises.
> You make this sound like a medical condition which is unfortunate...
>> Using the Sample Ecore Editor and examining the user resource
>> conforms that some references terminate in the Java model while other
>> use a loaded model.
> There really are different artifacts.
>> Is this just confusing and unhelpful or something much nastier?
> There haven't exactly been a flood of complaints about it...
>>
>> It would seem that a reasonable well formedness rule for Ecore could be.
> So you're suggesting we make new rules that make existing models invalid?
>>
>> allRootResources = all Resources containing any element transitively
>> referenced by the user model
>> allEPackages = all EPackage transitively contained by allRootResources
>> allNsURIs = the List of all EPackage.nsURI in allEPackages
>> allNsURIs contains no duplicates (perhaps ignoring blank nsURIs).
> This sounds like a rule that makes things Ecore models invalid
> depending on context but the problem isn't with the Ecore files it's a
> contextual thing.
>>
>> NB references to meta-elements are ignored allowing Ecore to be
>> consistently defined using 'another' Ecore as its meta-class.
> Ignored by whom?
>>
>> The above WFR would give a validation for failure for UML.ecore,
>> which once fixed would reduce the opportunities for schizophrenia.
> Forcing all models that use built-in data types to change, which is
> pretty much all models period, sounds like a non-starter suggestion
> for me.
>>
>> Regards
>>
>> Ed Willink
>>
>>
|
|
|
| Re: Are Change.ecore, UML.ecore and bpmn.ecore valid? [message #845696 is a reply to message #845668] |
Sun, 15 April 2012 10:10 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Ed,
Comments below.
On 15/04/2012 11:30 AM, Ed Willink wrote:
> Hi
>
> Thanks; that conforms my observations. Clearly with almost intentional
> dual model use a single model WFR is troublesome.
Yes.
>
> There certainly isn't a flood of complaints in the edit Ecore +
> genmodel world, since this is a closed environment which until
> recently (? Juno M3) didn't have a standalone option.
>
> There is a steady stream of bewildered users in the model
> transformation world, which is often standalone. Users variously
> encounter a total failure to use a model at all through difficulties
> of getting manual model registrations right and misguided
> tool-specific attempts to make platform: relative access (from Eclipse
> model editing tools) work as if it were file: relative (for naive
> standalone usage). If users get the models loaded they sometimes
> manage to load two meta-models; one accessed by the 'program'
> transformation/OCL rules and another instantiated by the model. With
> distinct models, simple tests such is b an instanceof B may fail,
> because b is an instance of B but a different B.
Yes, mixing the development artifacts with the generated models that
exist at runtime is a significant point of confusion.
>
> In the genmodel world it does not seem to matter that EDataTypes and
> EClasses are instantiated from different EPackage instances with the
> same nsURI; in the tx world it does.
Yes, but keep in mind that all the generated packages properly refer to
the generated packages they need, so there is no issue with respect to
those...
>
> I've been toying with writing a blog on how URIs work, but have held
> back because I don't understand the misguided tool-specifics.
Misguided?
>
> My ProjectMap contribution in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=361063 might establish a
> level playing field so that standalone is the same as Eclipse-running,
> which might then allow tools to work with EMF URIs rather than fight
> them. Until then I think users just need to be patient and lucky
> unless they've got a good example to copy. With GIT fragmenting
> non-trivial workspaces, many of the old treat-platform:-as-a-file:
> approaches fail badly.
Yes, you'd need to establish a mapping from the logical workspace URIs
to the physical location of each project.
>
> (For OCL I'm taking the view that multiple packages with the same
> non-blank nsURI are to be merged.)
>
> Regards
>
> Ed Willink
>
> On 15/04/2012 09:07, Ed Merks wrote:
>> Ed,
>>
>> Comments below.
>>
>> On 11/04/2012 1:06 PM, Ed Willink wrote:
>>> Hi Ed
>>>
>>> You may recall that I prompted a revision of Ecore.ecore to avoid
>>> mixed model references, and a further revision to avoid a mixed
>>> reference that crept in with eInvoke.
>> Yes.
>>>
>>> A user on the OCL group has had trouble with bpmn.ecore, which I
>>> didn't have a copy of, but found that I could reproduce the problem
>>> with Change.ecore. On further examination I found a problem with
>>> UML.ecore too:
>>>
>>> <eClassifiers xsi:type="ecore:EClass" name="Element" abstract="true"
>>> eSuperTypes="platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#//EModelElement">
>> For referencing an EClass it's very important to use the real
>> serialize development time version because that has all the settings
>> used to generate the real code.
>>> <eOperations name="not_own_self" eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2002/Ecore#//EBoolean">
>> For data types it's okay to use the generated model instance because
>> there aren't GenModel settings that affect how it's used.
>>>
>>> There seems to be a widespread default behaviour that EDataTypes
>>> come from http://www.eclipse.org/emf/2002/Ecore
>> Yes, that's allowed.
>>> whereas EClasses come from
>>> platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore.
>> Yes, that's necessary.
>>> These are not necessarily the same Resource and so an opportunity
>>> for meta-model schizophrenia arises.
>> You make this sound like a medical condition which is unfortunate...
>>> Using the Sample Ecore Editor and examining the user resource
>>> conforms that some references terminate in the Java model while
>>> other use a loaded model.
>> There really are different artifacts.
>>> Is this just confusing and unhelpful or something much nastier?
>> There haven't exactly been a flood of complaints about it...
>>>
>>> It would seem that a reasonable well formedness rule for Ecore could
>>> be.
>> So you're suggesting we make new rules that make existing models
>> invalid?
>>>
>>> allRootResources = all Resources containing any element transitively
>>> referenced by the user model
>>> allEPackages = all EPackage transitively contained by allRootResources
>>> allNsURIs = the List of all EPackage.nsURI in allEPackages
>>> allNsURIs contains no duplicates (perhaps ignoring blank nsURIs).
>> This sounds like a rule that makes things Ecore models invalid
>> depending on context but the problem isn't with the Ecore files it's
>> a contextual thing.
>>>
>>> NB references to meta-elements are ignored allowing Ecore to be
>>> consistently defined using 'another' Ecore as its meta-class.
>> Ignored by whom?
>>>
>>> The above WFR would give a validation for failure for UML.ecore,
>>> which once fixed would reduce the opportunities for schizophrenia.
>> Forcing all models that use built-in data types to change, which is
>> pretty much all models period, sounds like a non-starter suggestion
>> for me.
>>>
>>> Regards
>>>
>>> Ed Willink
>>>
>>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Are Change.ecore, UML.ecore and bpmn.ecore valid? [message #846712 is a reply to message #845668] |
Mon, 16 April 2012 08:08 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On 15.04.12 11.30, Ed Willink wrote:
>
> There is a steady stream of bewildered users in the model transformation
> world, which is often standalone. Users variously encounter a total
> failure to use a model at all through difficulties of getting manual
> model registrations right and misguided tool-specific attempts to make
> platform: relative access (from Eclipse model editing tools) work as if
> it were file: relative (for naive standalone usage). If users get the
> models loaded they sometimes manage to load two meta-models; one
> accessed by the 'program' transformation/OCL rules and another
> instantiated by the model. With distinct models, simple tests such is b
> an instanceof B may fail, because b is an instance of B but a different B.
I often encounter this problem, last week I had to write a method to use
instead of EClassifier.isInstance that used equal on the EClass name,
due to MMS (meta-model schizophrenia).
The main problem, which I think you are addressing, is that modellers
and tool developers manage these problems in different ways, so some
combinations work and others don't. Each developers solves his/her own
problem using incompatible solutions.
For a long time I thought that I had to consistently use
http://...Ecore, but to pick up the right genmodel settings I sometimes
have to use the plugin variant.
I see this all the time when using Xtext. I have models that depend on
ecore/genmodel and xbase/xtype and it's impossible to satisfy the
requirements of 1) the EMF generator, 2) the Xtext editor and 3) the MWE
launcher. I've experimented with all combinations of URIs, import and
register XXX and none work for all tools.
This is the single biggest problem when using EMF and Xtext in my class
on model-based development. I have to carefully prepare the various
plugin projects with models, xtext and mwe2 files, so they can safely
import them into their workspaces, since there are so many ways to ruin
them.
Hallvard
|
|
| |
| Re: Are Change.ecore, UML.ecore and bpmn.ecore valid? [message #846716 is a reply to message #846712] |
Mon, 16 April 2012 10:00 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
On 16/04/2012 10:08 AM, Hallvard Trætteberg wrote:
> On 15.04.12 11.30, Ed Willink wrote:
>>
>> There is a steady stream of bewildered users in the model transformation
>> world, which is often standalone. Users variously encounter a total
>> failure to use a model at all through difficulties of getting manual
>> model registrations right and misguided tool-specific attempts to make
>> platform: relative access (from Eclipse model editing tools) work as if
>> it were file: relative (for naive standalone usage). If users get the
>> models loaded they sometimes manage to load two meta-models; one
>> accessed by the 'program' transformation/OCL rules and another
>> instantiated by the model. With distinct models, simple tests such is b
>> an instanceof B may fail, because b is an instance of B but a
>> different B.
>
> I often encounter this problem, last week I had to write a method to
> use instead of EClassifier.isInstance that used equal on the EClass
> name, due to MMS (meta-model schizophrenia).
Note that the implementation of EClass.isInstance is quite different
depending on whether model is generated or dynamic, i.e., on whether
there is an instanceClass available... If isInstance is returning
false, you really won't be able to use the instances interchangeably...
>
> The main problem, which I think you are addressing, is that modellers
> and tool developers manage these problems in different ways, so some
> combinations work and others don't. Each developers solves his/her own
> problem using incompatible solutions.
Well, fortunately we're talking about tool developers, and not about
each end user. And now, you're not just talking about consistently
using only one model, but also having a consistent mapping from a
logical URI space, e.g., platform:/resource/project to a physical URI
space, e.g., file:/c:/path/project...
>
> For a long time I thought that I had to consistently use
> http://...Ecore, but to pick up the right genmodel settings I
> sometimes have to use the plugin variant.
Yes, to use EClasses of any model like Ecore, you really need the
platform:/plugin/org.eclipse.emf.ecore/model/Ecore.genmodel
>
> I see this all the time when using Xtext. I have models that depend on
> ecore/genmodel and xbase/xtype and it's impossible to satisfy the
> requirements of 1) the EMF generator, 2) the Xtext editor and 3) the
> MWE launcher.
Yes, and sometimes when you start the workspace or do a clean build, it
has errors that magically go away during a later build. We need to
track down the underlying causes of that. Maybe next week when I visit
them...
> I've experimented with all combinations of URIs, import and register
> XXX and none work for all tools.
Hmmm. Certainly I have it working for Xcore...
>
> This is the single biggest problem when using EMF and Xtext in my
> class on model-based development. I have to carefully prepare the
> various plugin projects with models, xtext and mwe2 files, so they can
> safely import them into their workspaces, since there are so many ways
> to ruin them.
Yes, there seem to be more ways to do it wrong than the magical way to
do it right.
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 05:02:42 GMT 2024
Powered by FUDForum. Page generated in 0.04494 seconds |
] 
Search
Help
Register
Login
Home
