Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Dangling reference when dynamically creating EMF instances
Dangling reference when dynamically creating EMF instances [message #671296] Tue, 17 May 2011 12:02 Go to next message
Ulli Hafner is currently offline Ulli Hafner
Messages: 8
Registered: July 2009
Junior Member
Hi,

I'm trying to write a xtext grammar that uses some predefined instances
that are computed dynamically. Where is the best way to load these
instances so that these instances are available when pressing CTRL-SPACE?

My grammar is quite simple:
----------------
grammar de.faktorlogik.ips.dsl.Rules with org.eclipse.xtext.common.Terminals

generate rules "http://www.faktorlogik.de/ips/dsl/Rules"

Model:
rule=Rule;

Concept:
'concept' name=ID;

Property:
'property' name=ID;

Rule:
concept=[Concept] 'and' restriction=Restriction;

Restriction:
'(' property=[Property] 'some' concept=[Concept] ')';
----------------------

Concept and Property instances are actually not defined using the
editor, they are created dynamically. I only defined them in the grammar
in order to use them as references in the Rule definition.

My Editor should basically parse the following input:
----------------------
concept1 and (property1 some concept2)
----------------------

The elements concept1, property1, and concept2 are dynamically computed.

Currently I've extended from AbstractDeclarativeScopeProvider and
instantiate the objects dynamically from within methods

public IScope scope_Concept(Model model, EReference reference) {
return new MapBasedScope(computeAvailableConcepts());
}

public IScope scope_Property(Model model, EReference reference) {
return new MapBasedScope(computeAvailableProperties())
}

This approach works for the context assist, however I'm always getting
the following validation error:

The feature 'property' of
'de.faktorlogik.ips.dsl.rules.impl.RestrictionImpl@1fdbab5 {platform:/resource/hello.world/src/rules.flips#//@rule/@res triction}'
contains a dangling reference
'de.faktorlogik.ips.dsl.rules.impl.PropertyImpl@a484c7{#//}'
rules.flips /hello.world/src line: 1 /hello.world/src/rules.flips Xtext
Check (fast)

Am I doing something fundamentally wrong? Or where would be the best
place to instantiate those predefined instances? (Currently the scope
methods are invoked on every CTRL-SPACE, maybe a method that would be
invoked only once would be sufficient?

Thanks,

Ulli
Re: Dangling reference when dynamically creating EMF instances [message #671493 is a reply to message #671296] Wed, 18 May 2011 05:50 Go to previous messageGo to next message
Knut Wannheden is currently offline Knut Wannheden
Messages: 296
Registered: July 2009
Senior Member
Hi Ulli,

Welcome to the Xtext community!

See answers inline.

On 5/17/11 2:02 PM, Ulli Hafner wrote:
> Hi,
>
> I'm trying to write a xtext grammar that uses some predefined instances that
> are computed dynamically. Where is the best way to load these instances so
> that these instances are available when pressing CTRL-SPACE?
>
> My grammar is quite simple:
> ----------------
> grammar de.faktorlogik.ips.dsl.Rules with org.eclipse.xtext.common.Terminals
>
> generate rules "http://www.faktorlogik.de/ips/dsl/Rules"
>
> Model:
> rule=Rule;
>
> Concept:
> 'concept' name=ID;
>
> Property:
> 'property' name=ID;
>
> Rule:
> concept=[Concept] 'and' restriction=Restriction;
>
> Restriction:
> '(' property=[Property] 'some' concept=[Concept] ')';
> ----------------------
>
> Concept and Property instances are actually not defined using the editor, they
> are created dynamically. I only defined them in the grammar in order to use
> them as references in the Rule definition.
>

I would consider maintaining the Ecore model by hand as the parser rules for
Concept and Property are not used and thus rather confusing.

> My Editor should basically parse the following input:
> ----------------------
> concept1 and (property1 some concept2)
> ----------------------
>
> The elements concept1, property1, and concept2 are dynamically computed.
>
> Currently I've extended from AbstractDeclarativeScopeProvider and instantiate
> the objects dynamically from within methods
>
> public IScope scope_Concept(Model model, EReference reference) {
> return new MapBasedScope(computeAvailableConcepts());
> }
>
> public IScope scope_Property(Model model, EReference reference) {
> return new MapBasedScope(computeAvailableProperties())
> }
>
> This approach works for the context assist, however I'm always getting the
> following validation error:
>
> The feature 'property' of
> 'de.faktorlogik.ips.dsl.rules.impl.RestrictionImpl@1fdbab5 {platform:/resource/hello.world/src/rules.flips#//@rule/@res triction}'
> contains a dangling reference
> 'de.faktorlogik.ips.dsl.rules.impl.PropertyImpl@a484c7{#//}' rules.flips
> /hello.world/src line: 1 /hello.world/src/rules.flips Xtext Check (fast)
>
> Am I doing something fundamentally wrong? Or where would be the best place to
> instantiate those predefined instances? (Currently the scope methods are
> invoked on every CTRL-SPACE, maybe a method that would be invoked only once
> would be sufficient?
>

The problem is that your Concept and Property instances are not contained by
any EMF resource. And there is a standard EMF validation checking against
references to such non-contained objects.

I would consider the following approaches (in the given order) to solve the
problem:

1. Presumably the Concept and Property instances are created based on some
other external, persisted data. If possible and feasible it would make sense
to implement an IResourceServiceProvider (see also
GenericResourceServiceProvider) for this external content. That way you could
add the Concept and Property instances to the Xtext index and link against that.

2. On the fly generate an EMF Resource containing the Concepts and Properties
and add it to the ResourceSet which contains your model. You could do this
dynamically in the ScopeProvider or possibly up front in the Linker (using the
afterModelLinked() hook).

3. Add the Concept and Property instances as additional top-level objects to
the XtextResource containing your model. This however makes most sense if
these instances are derived from data in your model. (Xbase based languages
use this approach to store derived Java types.)

4. Disable the EMF validation. You can do this by binding a
@Named(CompositeEValidator.USE_EOBJECT_VALIDATOR) Boolean to "false". You
could also be more specific and bind CompositeEValidator to a custom subclass
where you override initDefaults() to add an EObjectValidator which in
validate_EveryReferenceIsContained() returns "true". But I wouldn't really
recommend this approach if you don't have very good reasons.

Hope that helps,

--knut
Re: Dangling reference when dynamically creating EMF instances [message #671623 is a reply to message #671493] Wed, 18 May 2011 14:02 Go to previous messageGo to next message
Ulli Hafner is currently offline Ulli Hafner
Messages: 8
Registered: July 2009
Junior Member
On 05/18/2011 07:50 AM, Knut Wannheden wrote:
> Hi Ulli,
>
> Welcome to the Xtext community!
>
> See answers inline.

Hi Knut :-)

Thanks for the links. The GenericResourceServiceProvider seems to be
part of xtext 2.0. Is it worth to update to this pre-release version or
can I adapt the DefaultResourceServiceProvider from the 1.0 release, too?

Ulli

>
> On 5/17/11 2:02 PM, Ulli Hafner wrote:
>> Hi,
>>
>> I'm trying to write a xtext grammar that uses some predefined
>> instances that
>> are computed dynamically. Where is the best way to load these
>> instances so
>> that these instances are available when pressing CTRL-SPACE?
>>
>> My grammar is quite simple:
>> ----------------
>> grammar de.faktorlogik.ips.dsl.Rules with
>> org.eclipse.xtext.common.Terminals
>>
>> generate rules "http://www.faktorlogik.de/ips/dsl/Rules"
>>
>> Model:
>> rule=Rule;
>>
>> Concept:
>> 'concept' name=ID;
>>
>> Property:
>> 'property' name=ID;
>>
>> Rule:
>> concept=[Concept] 'and' restriction=Restriction;
>>
>> Restriction:
>> '(' property=[Property] 'some' concept=[Concept] ')';
>> ----------------------
>>
>> Concept and Property instances are actually not defined using the
>> editor, they
>> are created dynamically. I only defined them in the grammar in order
>> to use
>> them as references in the Rule definition.
>>
>
> I would consider maintaining the Ecore model by hand as the parser rules
> for Concept and Property are not used and thus rather confusing.
>
>> My Editor should basically parse the following input:
>> ----------------------
>> concept1 and (property1 some concept2)
>> ----------------------
>>
>> The elements concept1, property1, and concept2 are dynamically computed.
>>
>> Currently I've extended from AbstractDeclarativeScopeProvider and
>> instantiate
>> the objects dynamically from within methods
>>
>> public IScope scope_Concept(Model model, EReference reference) {
>> return new MapBasedScope(computeAvailableConcepts());
>> }
>>
>> public IScope scope_Property(Model model, EReference reference) {
>> return new MapBasedScope(computeAvailableProperties())
>> }
>>
>> This approach works for the context assist, however I'm always getting
>> the
>> following validation error:
>>
>> The feature 'property' of
>> 'de.faktorlogik.ips.dsl.rules.impl.RestrictionImpl@1fdbab5 {platform:/resource/hello.world/src/rules.flips#//@rule/@res triction}'
>>
>> contains a dangling reference
>> 'de.faktorlogik.ips.dsl.rules.impl.PropertyImpl@a484c7{#//}' rules.flips
>> /hello.world/src line: 1 /hello.world/src/rules.flips Xtext Check (fast)
>>
>> Am I doing something fundamentally wrong? Or where would be the best
>> place to
>> instantiate those predefined instances? (Currently the scope methods are
>> invoked on every CTRL-SPACE, maybe a method that would be invoked only
>> once
>> would be sufficient?
>>
>
> The problem is that your Concept and Property instances are not
> contained by any EMF resource. And there is a standard EMF validation
> checking against references to such non-contained objects.
>
> I would consider the following approaches (in the given order) to solve
> the problem:
>
> 1. Presumably the Concept and Property instances are created based on
> some other external, persisted data. If possible and feasible it would
> make sense to implement an IResourceServiceProvider (see also
> GenericResourceServiceProvider) for this external content. That way you
> could add the Concept and Property instances to the Xtext index and link
> against that.
>
> 2. On the fly generate an EMF Resource containing the Concepts and
> Properties and add it to the ResourceSet which contains your model. You
> could do this dynamically in the ScopeProvider or possibly up front in
> the Linker (using the afterModelLinked() hook).
>
> 3. Add the Concept and Property instances as additional top-level
> objects to the XtextResource containing your model. This however makes
> most sense if these instances are derived from data in your model.
> (Xbase based languages use this approach to store derived Java types.)
>
> 4. Disable the EMF validation. You can do this by binding a
> @Named(CompositeEValidator.USE_EOBJECT_VALIDATOR) Boolean to "false".
> You could also be more specific and bind CompositeEValidator to a custom
> subclass where you override initDefaults() to add an EObjectValidator
> which in validate_EveryReferenceIsContained() returns "true". But I
> wouldn't really recommend this approach if you don't have very good
> reasons.
>
> Hope that helps,
>
> --knut
Re: Dangling reference when dynamically creating EMF instances [message #671640 is a reply to message #671623] Wed, 18 May 2011 14:23 Go to previous messageGo to next message
Knut Wannheden is currently offline Knut Wannheden
Messages: 296
Registered: July 2009
Senior Member
Hi Ulli,

On 5/18/11 4:02 PM, Ulli Hafner wrote:
> On 05/18/2011 07:50 AM, Knut Wannheden wrote:
>
> Thanks for the links. The GenericResourceServiceProvider seems to be part of
> xtext 2.0. Is it worth to update to this pre-release version or can I adapt
> the DefaultResourceServiceProvider from the 1.0 release, too?
>

I think it very much depends what your requirements and deadlines are. If you
are not forced to maintain an Xtext 1.0 (and Xtext 2.0) version of your
language, I would go straight to Xtext 2.0. A lot of new features and changes
have been made since Xtext 1.0 and with the final release coming up in about a
month (RC1 was just released) there is plenty of time to learn about Xtext 2.0
and start migrating.

That being said you should still be able to implement an
IResourceServiceProvider based solution for your external data in Xtext 1.0
without too much trouble. Or you could consider the other mentioned options
for now, as they all should be easier.

Cheers,

--knut
Re: Dangling reference when dynamically creating EMF instances [message #671652 is a reply to message #671296] Wed, 18 May 2011 15:09 Go to previous messageGo to next message
Alexander Nittka is currently offline Alexander Nittka
Messages: 1156
Registered: July 2009
Senior Member
Hi,

just as a side question. Do you need Concept and Property to be referrable, i.e. do you really need cross references to them? This usually makes sense if you can actually navigate to them (F3) which in your case would not be possible anyway. For simpe scenarios, I could imagine that implementing adapted code completion and validation would work just as well (Rule: concept=ID... instead of Rule: concept=[Concept]).

However, I assume that this is not enough in your case. So here is a second question. What do you mean by dynamically calculated? Really dynamically in the sense that different Concepts are used in different contexts or would it be possible that these concepts can be put into a "library", i.e. a model visible by default which is part of your plugin (analogous to the default terminals provided by Xtext or basic types always visible in Java).

Alex
Re: Dangling reference when dynamically creating EMF instances [message #671887 is a reply to message #671652] Thu, 19 May 2011 08:46 Go to previous messageGo to next message
Ulli Hafner is currently offline Ulli Hafner
Messages: 8
Registered: July 2009
Junior Member
On 05/18/2011 05:09 PM, Alexander Nittka wrote:
> Hi,
>
> just as a side question. Do you need Concept and Property to be
> referrable, i.e. do you really need cross references to them? This
> usually makes sense if you can actually navigate to them (F3) which in
> your case would not be possible anyway. For simpe scenarios, I could
> imagine that implementing adapted code completion and validation would
> work just as well (Rule: concept=ID... instead of Rule: concept=[Concept]).
>
> However, I assume that this is not enough in your case. So here is a
> second question. What do you mean by dynamically calculated? Really
> dynamically in the sense that different Concepts are used in different
> contexts or would it be possible that these concepts can be put into a
> "library", i.e. a model visible by default which is part of your plugin
> (analogous to the default terminals provided by Xtext or basic types
> always visible in Java).
>
> Alex

Hi Alex,

that is a good point :-)

Actually concepts and properties should not be referrable, I just need
them for code completion. What I'm trying to get is a parser for rules
that use a predefined set of concepts that contain some properties. The
concepts and properties are defined in an OWL model (web ontology
language) and are quite similar to classes and associations in Java.

E.g., I have a concept 'Pizza' that has a property 'topping' which
refers to another concept 'Salami' that has a property 'spiciness' that
refers to a concept 'Hot'. (These concepts are given before I'm opening
the editor, but they can change during an Eclipse session. I.e. the user
changes the OWL model, opens the xtext editor to define some rules,
closes the editor, changes the model, opens the rule editor, etc.)

What I would like to have is an editor, that can parse e.g. the
following expression:

Pizza 'and' topping 'is' Salami 'and' spiciness 'is' Hot

Context assist must be context sensitive, e.g. when the cursor is at X:
"Pizza 'and' X" then only topping should be available and not spiciness.
As well as after the user typed 'topping' then only all topping should
be available.

Seems that my xtext starting point was to complicated at all. I tried to
go forward with your approach, however I don't find a way to provide
code completion for these IDs?

E.g., now I have

Concept:
ID;

Property:
ID;

Rule:
concept=Concept 'and' property=Property;


Since Concept and Property are now just strings the code completion
using the ScopeProvider seems to be not possible. Do I need to implement
a IValueConverterService to get code completion on theses IDs?

Thanks, Ulli
Re: Dangling reference when dynamically creating EMF instances [message #671891 is a reply to message #671887] Thu, 19 May 2011 09:26 Go to previous messageGo to next message
Alexander Nittka is currently offline Alexander Nittka
Messages: 1156
Registered: July 2009
Senior Member
Hi,

still too complicated (I'd say):

Rule: concept=ID 'and' property=ID;

The proposalProvider now has a method completeRule_Concept and a method completeRule_Property. There you add your proposals (acceptor.accept(createCompletionProposal("Pizza",context)));
In the completeRule_Property, you retrieve the model element from the context and and check which concept is used, so you propose only the properties of that concept.
Similarly you adapt validation, so that only valid concepts and their properties are used. It would make sense to hold a datastructure for concepts and properties, so that you have easy access to them from wherever they are needed (code completion, validation, highlighting if you want...)

Alex


Need training, onsite consulting or any other kind of help for Xtext?
Go visit http://xtext.itemis.com or send a mail to xtext@itemis.de
Re: Dangling reference when dynamically creating EMF instances [message #672244 is a reply to message #671891] Fri, 20 May 2011 12:41 Go to previous messageGo to next message
Ulli Hafner is currently offline Ulli Hafner
Messages: 8
Registered: July 2009
Junior Member
On 05/19/2011 11:26 AM, Alexander Nittka wrote:
> Hi,
>
> still too complicated (I'd say):
>
> Rule: concept=ID 'and' property=ID;
>
> The proposalProvider now has a method completeRule_Concept and a method
> completeRule_Property. There you add your proposals
> (acceptor.accept(createCompletionProposal("Pizza",context)));
> In the completeRule_Property, you retrieve the model element from the
> context and and check which concept is used, so you propose only the
> properties of that concept.
> Similarly you adapt validation, so that only valid concepts and their
> properties are used. It would make sense to hold a datastructure for
> concepts and properties, so that you have easy access to them from
> wherever they are needed (code completion, validation, highlighting if
> you want...)
>
> Alex


Hi Alex,

thanks for your valuable input! I implemented your idea and it works
exactly like I wanted to have it:-)

Ulli
Re: Dangling reference when dynamically creating EMF instances [message #673288 is a reply to message #671887] Mon, 23 May 2011 06:29 Go to previous messageGo to next message
Knut Wannheden is currently offline Knut Wannheden
Messages: 296
Registered: July 2009
Senior Member
Hi Ulli,

On 5/19/11 10:46 AM, Ulli Hafner wrote:
> On 05/18/2011 05:09 PM, Alexander Nittka wrote:
>
> E.g., I have a concept 'Pizza' that has a property 'topping' which refers to
> another concept 'Salami' that has a property 'spiciness' that refers to a
> concept 'Hot'. (These concepts are given before I'm opening the editor, but
> they can change during an Eclipse session. I.e. the user changes the OWL
> model, opens the xtext editor to define some rules, closes the editor, changes
> the model, opens the rule editor, etc.)
>

Since the identifiers in your Xtext language conceptually represent references
to objects in your OWL model I would also define them as cross references in
the Xtext grammar. Even if you only need code completion, as you say.

The reason for declaring it as a cross reference is that you probably would
like a change to the OWL model to cause the referencing Xtext files to be
revalidated. The only reasonable way to support this is to use cross
references. The Xtext builder will then (provided that the OWL model is in the
index as I outlined in approach 1 of my first reply) automatically revalidate
any referencing Xtext files as soon as the the OWL model is modified.

> What I would like to have is an editor, that can parse e.g. the following
> expression:
>
> Pizza 'and' topping 'is' Salami 'and' spiciness 'is' Hot
>
> Context assist must be context sensitive, e.g. when the cursor is at X:
> "Pizza 'and' X" then only topping should be available and not spiciness. As
> well as after the user typed 'topping' then only all topping should be available.
>

This should work automatically if you define the scope provider accordingly
for your language.

Again, I think what Alex proposes will certainly fulfill your code completion
requirements, but to me it sounds like you should actually go through the
extra trouble to use proper cross references.

--knut
Re: Dangling reference when dynamically creating EMF instances [message #673290 is a reply to message #673288] Mon, 23 May 2011 06:46 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4115
Registered: July 2009
Senior Member
Hi
>
> Since the identifiers in your Xtext language conceptually represent
> references to objects in your OWL model I would also define them as
> cross references in the Xtext grammar. Even if you only need code
> completion, as you say.
>
You may think that you only want code completion, but if you work
with-Xtext you will find all sorts of functionality such Find
References, Name Refactoring, Go to Definition work almost
automatically. If you start to work against-Xtext you will find that
every new piece of functionality involves a new fight with largely
undocumented APIs. and that fight is in danger of requiring repeated
work with each new Xtext release.

I use Xtext for OCL for which source may be perhaps 75% references.
Using true AST model references in the Indigo release rather than CST
references in the Helios release has made many parts of the code much
cleaner. For the Xtext OCL editor, even 'built-in' operator names and
'built-in' types are references so that they can be model-defined.

If, after detailed study, you really want to reject references, then I
suspect you should reject Xtext too.

Regards

Ed Willink
Re: Dangling reference when dynamically creating EMF instances [message #673337 is a reply to message #673288] Mon, 23 May 2011 09:45 Go to previous messageGo to next message
Alexander Nittka is currently offline Alexander Nittka
Messages: 1156
Registered: July 2009
Senior Member
Hi,

I agree. What I proposed was a quick and dirty workaround. Referencing the actual owl concepts would be the best solution (but in the original post it did not look like this was intended). And if there is a simple way to import/reference the owl meta model, this should be done.

Alex
Re: Dangling reference when dynamically creating EMF instances [message #673400 is a reply to message #673290] Mon, 23 May 2011 13:51 Go to previous messageGo to next message
Ulli Hafner is currently offline Ulli Hafner
Messages: 8
Registered: July 2009
Junior Member
On 05/23/2011 08:46 AM, Ed Willink wrote:
> Hi
>>
>> Since the identifiers in your Xtext language conceptually represent
>> references to objects in your OWL model I would also define them as
>> cross references in the Xtext grammar. Even if you only need code
>> completion, as you say.
>>
> You may think that you only want code completion, but if you work
> with-Xtext you will find all sorts of functionality such Find
> References, Name Refactoring, Go to Definition work almost
> automatically. If you start to work against-Xtext you will find that
> every new piece of functionality involves a new fight with largely
> undocumented APIs. and that fight is in danger of requiring repeated
> work with each new Xtext release.

Well, I already noted that the API is not well documented (which is
quite uncommon for Eclipse projects). Most of the JavaDoc is just
denoting the authors of the API...

>
> I use Xtext for OCL for which source may be perhaps 75% references.
> Using true AST model references in the Indigo release rather than CST
> references in the Helios release has made many parts of the code much
> cleaner. For the Xtext OCL editor, even 'built-in' operator names and
> 'built-in' types are references so that they can be model-defined.
>
> If, after detailed study, you really want to reject references, then I
> suspect you should reject Xtext too.
>

I think the "quick and dirty" approach works quite well for our use case
right now. I still can switch to the more complex approach in some later
iterations.

Ulli
Re: Dangling reference when dynamically creating EMF instances [message #673401 is a reply to message #673337] Mon, 23 May 2011 13:57 Go to previous messageGo to next message
Ulli Hafner is currently offline Ulli Hafner
Messages: 8
Registered: July 2009
Junior Member
On 05/23/2011 11:45 AM, Alexander Nittka wrote:
> Hi,
>
> I agree. What I proposed was a quick and dirty workaround. Referencing
> the actual owl concepts would be the best solution (but in the original
> post it did not look like this was intended). And if there is a simple
> way to import/reference the owl meta model, this should be done.
>
> Alex

Actually I did not find a simple way to import the OWL model yet. Seems
that the learning curve to XText is quite steep. Is there a good XText
book around that also covers the API?

I'll start with your simple approach and will refine it later on...

Ulli
Re: Dangling reference when dynamically creating EMF instances [message #673405 is a reply to message #673290] Mon, 23 May 2011 13:51 Go to previous messageGo to next message
Ulli Hafner is currently offline Ulli Hafner
Messages: 8
Registered: July 2009
Junior Member
On 05/23/2011 08:46 AM, Ed Willink wrote:
> Hi
>>
>> Since the identifiers in your Xtext language conceptually represent
>> references to objects in your OWL model I would also define them as
>> cross references in the Xtext grammar. Even if you only need code
>> completion, as you say.
>>
> You may think that you only want code completion, but if you work
> with-Xtext you will find all sorts of functionality such Find
> References, Name Refactoring, Go to Definition work almost
> automatically. If you start to work against-Xtext you will find that
> every new piece of functionality involves a new fight with largely
> undocumented APIs. and that fight is in danger of requiring repeated
> work with each new Xtext release.

Well, I already noted that the API is not well documented (which is
quite uncommon for Eclipse projects). Most of the JavaDoc is just
denoting the authors of the API...

>
> I use Xtext for OCL for which source may be perhaps 75% references.
> Using true AST model references in the Indigo release rather than CST
> references in the Helios release has made many parts of the code much
> cleaner. For the Xtext OCL editor, even 'built-in' operator names and
> 'built-in' types are references so that they can be model-defined.
>
> If, after detailed study, you really want to reject references, then I
> suspect you should reject Xtext too.
>

I think the "quick and dirty" approach works quite well for our use case
right now. I still can switch to the more complex approach in some later
iterations.

Ulli
Re: Dangling reference when dynamically creating EMF instances [message #673406 is a reply to message #673337] Mon, 23 May 2011 13:57 Go to previous messageGo to next message
Ulli Hafner is currently offline Ulli Hafner
Messages: 8
Registered: July 2009
Junior Member
On 05/23/2011 11:45 AM, Alexander Nittka wrote:
> Hi,
>
> I agree. What I proposed was a quick and dirty workaround. Referencing
> the actual owl concepts would be the best solution (but in the original
> post it did not look like this was intended). And if there is a simple
> way to import/reference the owl meta model, this should be done.
>
> Alex

Actually I did not find a simple way to import the OWL model yet. Seems
that the learning curve to XText is quite steep. Is there a good XText
book around that also covers the API?

I'll start with your simple approach and will refine it later on...

Ulli
Re: Dangling reference when dynamically creating EMF instances [message #673567 is a reply to message #673401] Tue, 24 May 2011 06:18 Go to previous message
Knut Wannheden is currently offline Knut Wannheden
Messages: 296
Registered: July 2009
Senior Member
Hi Ulli,

On 5/23/11 3:57 PM, Ulli Hafner wrote:
> On 05/23/2011 11:45 AM, Alexander Nittka wrote:
>> Hi,
>>
>> I agree. What I proposed was a quick and dirty workaround. Referencing
>> the actual owl concepts would be the best solution (but in the original
>> post it did not look like this was intended). And if there is a simple
>> way to import/reference the owl meta model, this should be done.
>>
>> Alex
>
> Actually I did not find a simple way to import the OWL model yet. Seems that
> the learning curve to XText is quite steep. Is there a good XText book around
> that also covers the API?
>

From W3C you can obtain an Ecore model for OWL 2. Refer to
http://www.w3.org/2007/OWL/wiki/MOF-Based_Metamodel and
http://owl2.googlecode.com/files/owl2.ecore.

Using that you should be able to implement an IResourceServiceProvider for
OWL. The Xtext 2.0 plug-ins org.eclipse.xtext.ecore and
org.eclipse.xtext.ui.ecore should be a good starting point, as they provide
this support for Ecore files.

The learning curve is indeed quite steep. The current documentation describes
the function of the IResourceServiceProvider in the scoping section:
http://www.eclipse.org/Xtext/documentation/latest/xtext.html#scoping. Don't
hesitate to ask any unanswered questions here in the forum.

Cheers,

--knut
Previous Topic:trouble with cross references and constants
Next Topic:Extracting common grammar rule parts
Goto Forum:
  


Current Time: Fri Oct 31 19:28:13 GMT 2014

Powered by FUDForum. Page generated in 0.06495 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software