Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » Incorrect OCL error messages on correct OCL
| Incorrect OCL error messages on correct OCL [message #19286] |
Tue, 31 January 2006 20:27  |
Eclipse User |
|
|
|
Originally posted by: jos.warmer.klasse.nl
Hi all,
I have gone through the tutorial from GMF. Doing that I did find some
errors in the OCL constraints, e.g.
self <> oppositeEnd
oppositeEnd <> self
are considered correct. At the same time the follwoing are considered
incorect:
self.oppositeEnd <> self
self <> self.oppositeEnd
ERROR in (variableExpCS): (Variable cannot appear in the middle of a
navigation expression: (oppositeEnd))
oppositeEnd is nothing than a shorthand for self.oppositeEnd, therefore
all of the above should be correct.
Looks like a bug in the OCL parser/analyzer.
Jos Warmer
|
|
|
| Re: Incorrect OCL error messages on correct OCL [message #19333 is a reply to message #19286] |
Tue, 31 January 2006 11:38  |
 Richard Gronback
Messages: 605
Registered: July 2009 |
Senior Member |
|
|
Hi Jos,
Thanks, I will correct the tutorial.
I think Ed might have chased you out of the GMF newsgroup prematurely, as
the use of OCL in our tutorial, and in GMF generally, is definitely something
we'd like to discuss. Radek and I have replied to your post yesterday and
can pick it up there, while general questions about EMF OCL are more appropriate
here.
Thanks,
Rich
> Hi all,
>
> I have gone through the tutorial from GMF. Doing that I did find some
> errors in the OCL constraints, e.g.
>
> self <> oppositeEnd
> oppositeEnd <> self
> are considered correct. At the same time the follwoing are considered
> incorect:
>
> self.oppositeEnd <> self
> self <> self.oppositeEnd
> ERROR in (variableExpCS): (Variable cannot appear in the middle
> of a
> navigation expression: (oppositeEnd))
> oppositeEnd is nothing than a shorthand for self.oppositeEnd,
> therefore all of the above should be correct.
>
> Looks like a bug in the OCL parser/analyzer.
>
> Jos Warmer
>
|
|
| |
| Re: Incorrect OCL error messages on correct OCL [message #19426 is a reply to message #19333] |
Tue, 31 January 2006 14:50 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Rich,
Sorry. I didn't mean to chase anyone away. I'll try to be a little
less helpful in cases where I don't know all the context...
Richard Gronback wrote:
> Hi Jos,
>
> Thanks, I will correct the tutorial.
>
> I think Ed might have chased you out of the GMF newsgroup prematurely,
> as the use of OCL in our tutorial, and in GMF generally, is definitely
> something we'd like to discuss. Radek and I have replied to your post
> yesterday and can pick it up there, while general questions about EMF
> OCL are more appropriate here.
>
> Thanks,
> Rich
>
>> Hi all,
>>
>> I have gone through the tutorial from GMF. Doing that I did find some
>> errors in the OCL constraints, e.g.
>>
>> self <> oppositeEnd
>> oppositeEnd <> self
>> are considered correct. At the same time the follwoing are considered
>> incorect:
>>
>> self.oppositeEnd <> self
>> self <> self.oppositeEnd
>> ERROR in (variableExpCS): (Variable cannot appear in the middle
>> of a
>> navigation expression: (oppositeEnd))
>> oppositeEnd is nothing than a shorthand for self.oppositeEnd,
>> therefore all of the above should be correct.
>>
>> Looks like a bug in the OCL parser/analyzer.
>>
>> Jos Warmer
>>
>
>
|
|
|
| Re: Incorrect OCL error messages on correct OCL [message #19472 is a reply to message #19426] |
Tue, 31 January 2006 15:04 |
Richard Gronback
Messages: 605
Registered: July 2009 |
Senior Member |
|
|
Not a problem! :)
> Rich,
>
> Sorry. I didn't mean to chase anyone away. I'll try to be a little
> less helpful in cases where I don't know all the context...
>
> Richard Gronback wrote:
>
>> Hi Jos,
>>
>> Thanks, I will correct the tutorial.
>>
>> I think Ed might have chased you out of the GMF newsgroup
>> prematurely, as the use of OCL in our tutorial, and in GMF generally,
>> is definitely something we'd like to discuss. Radek and I have
>> replied to your post yesterday and can pick it up there, while
>> general questions about EMF OCL are more appropriate here.
>>
>> Thanks,
>> Rich
>>> Hi all,
>>>
>>> I have gone through the tutorial from GMF. Doing that I did find
>>> some errors in the OCL constraints, e.g.
>>>
>>> self <> oppositeEnd
>>> oppositeEnd <> self
>>> are considered correct. At the same time the follwoing are
>>> considered
>>> incorect:
>>> self.oppositeEnd <> self
>>> self <> self.oppositeEnd
>>> ERROR in (variableExpCS): (Variable cannot appear in the middle
>>> of a
>>> navigation expression: (oppositeEnd))
>>> oppositeEnd is nothing than a shorthand for self.oppositeEnd,
>>> therefore all of the above should be correct.
>>> Looks like a bug in the OCL parser/analyzer.
>>>
>>> Jos Warmer
>>>
|
|
|
| Re: Incorrect OCL error messages on correct OCL [message #19562 is a reply to message #19379] |
Wed, 01 February 2006 03:58 |
| Eclipse User |
|
|
|
Originally posted by: jos.warmer.klasse.nl
Radek,
You might be right, but I cannot tell from the context that I have.
OCL is written in the context of a model (this can also be a meta-model
of course). If you can give me a pointer to the model that the OCL in
the GMF tutorial is referring to, I can figure out what is going on and
whether you are right or not.
It seems to me that the OCL in the constraint probably refers to the
(meta)model of the graph definition, the mapping definition and/or the
ecore model definition.
Regards, Jos
Radek Dvorak wrote:
> Hi Jos,
>
> The 'oppositeEnd' in the GMF tutorial is a variable added to the Environment
> by the containing gmf-editor plugin.
> The reason is to allow access to both source and target ends which
> participate in a link creation.
> Here 'self' references the source end and 'oppositeEnd' points to the target
> end node.
>
> My understanding of the spec is that if there is a defined variable
> 'oppositeEnd' in the current scope it is resolved as VariableExp.
> If not, 'self' would be checked for corresponding AttributeCallExp,
> NavigationCallExp.
>
> According to this, the reported ERROR seems to me OK.
> Or have I missed something ?
>
> Regards,
> /Radek
>
>
> "Jos Warmer" <jos.warmer@klasse.nl> wrote in message
> news:drn71o$9qf$1@utils.eclipse.org...
>> Hi all,
>>
>> I have gone through the tutorial from GMF. Doing that I did find some
>> errors in the OCL constraints, e.g.
>>
>> self <> oppositeEnd
>> oppositeEnd <> self
>>
>> are considered correct. At the same time the follwoing are considered
>> incorect:
>>
>> self.oppositeEnd <> self
>> self <> self.oppositeEnd
>>
>> ERROR in (variableExpCS): (Variable cannot appear in the middle of a
>> navigation expression: (oppositeEnd))
>>
>> oppositeEnd is nothing than a shorthand for self.oppositeEnd, therefore
>> all of the above should be correct.
>>
>> Looks like a bug in the OCL parser/analyzer.
>>
>> Jos Warmer
>
>
|
|
|
| Re: Incorrect OCL error messages on correct OCL [message #19652 is a reply to message #19562] |
Wed, 01 February 2006 11:57 |
Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Hi Jos,
The forementioned expression is defined in the context of 'mindmap::Topic'
classifier (/org.eclipse.gmf.examples.mindmap/model/mindmap.ecore).
The constraint is manifested as restriction to a link source end (context)
and the source end here is 'Topic' as the link is realized by 'subtopics'
reference owned
by 'Topic'. The target end in this case is 'Topic' as well.
This is all a contract introduced by gmf mapping and in addition, the
resulting Environment is extended with addition of 'oppositeEnd' variable.
It references the opposite end of the link and has correspoding type
depending on wheter referenced from source or target end context.
There is no model property 'oppositeEnd' in 'Topic' classifier.
This variable was introduced to be able to check all link creation
participants before the link creation is finished and model updated.
I propose that any further gmf specific details we continue in gmf news
group.
Regards,
/Radek
"Jos Warmer" <jos.warmer@klasse.nl> wrote in message
news:dro1fs$2tr$1@utils.eclipse.org...
> Radek,
>
> You might be right, but I cannot tell from the context that I have.
>
> OCL is written in the context of a model (this can also be a meta-model of
> course). If you can give me a pointer to the model that the OCL in the GMF
> tutorial is referring to, I can figure out what is going on and whether
> you are right or not.
>
> It seems to me that the OCL in the constraint probably refers to the
> (meta)model of the graph definition, the mapping definition and/or the
> ecore model definition.
>
> Regards, Jos
>
> Radek Dvorak wrote:
>> Hi Jos,
>>
>> The 'oppositeEnd' in the GMF tutorial is a variable added to the
>> Environment by the containing gmf-editor plugin.
>> The reason is to allow access to both source and target ends which
>> participate in a link creation.
>> Here 'self' references the source end and 'oppositeEnd' points to the
>> target end node.
>>
>> My understanding of the spec is that if there is a defined variable
>> 'oppositeEnd' in the current scope it is resolved as VariableExp.
>> If not, 'self' would be checked for corresponding AttributeCallExp,
>> NavigationCallExp.
>>
>> According to this, the reported ERROR seems to me OK.
>> Or have I missed something ?
>>
>> Regards,
>> /Radek
>>
>>
>> "Jos Warmer" <jos.warmer@klasse.nl> wrote in message
>> news:drn71o$9qf$1@utils.eclipse.org...
>>> Hi all,
>>>
>>> I have gone through the tutorial from GMF. Doing that I did find some
>>> errors in the OCL constraints, e.g.
>>>
>>> self <> oppositeEnd
>>> oppositeEnd <> self
>>>
>>> are considered correct. At the same time the follwoing are considered
>>> incorect:
>>>
>>> self.oppositeEnd <> self
>>> self <> self.oppositeEnd
>>>
>>> ERROR in (variableExpCS): (Variable cannot appear in the middle of a
>>> navigation expression: (oppositeEnd))
>>>
>>> oppositeEnd is nothing than a shorthand for self.oppositeEnd, therefore
>>> all of the above should be correct.
>>>
>>> Looks like a bug in the OCL parser/analyzer.
>>>
>>> Jos Warmer
>>
|
|
|
| Re: Incorrect OCL error messages on correct OCL [message #565064 is a reply to message #19286] |
Tue, 31 January 2006 11:38 |
Richard Gronback
Messages: 605
Registered: July 2009 |
Senior Member |
|
|
Hi Jos,
Thanks, I will correct the tutorial.
I think Ed might have chased you out of the GMF newsgroup prematurely, as
the use of OCL in our tutorial, and in GMF generally, is definitely something
we'd like to discuss. Radek and I have replied to your post yesterday and
can pick it up there, while general questions about EMF OCL are more appropriate
here.
Thanks,
Rich
> Hi all,
>
> I have gone through the tutorial from GMF. Doing that I did find some
> errors in the OCL constraints, e.g.
>
> self <> oppositeEnd
> oppositeEnd <> self
> are considered correct. At the same time the follwoing are considered
> incorect:
>
> self.oppositeEnd <> self
> self <> self.oppositeEnd
> ERROR in (variableExpCS): (Variable cannot appear in the middle
> of a
> navigation expression: (oppositeEnd))
> oppositeEnd is nothing than a shorthand for self.oppositeEnd,
> therefore all of the above should be correct.
>
> Looks like a bug in the OCL parser/analyzer.
>
> Jos Warmer
>
|
|
| |
| Re: Incorrect OCL error messages on correct OCL [message #565131 is a reply to message #19333] |
Tue, 31 January 2006 14:50 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Rich,
Sorry. I didn't mean to chase anyone away. I'll try to be a little
less helpful in cases where I don't know all the context...
Richard Gronback wrote:
> Hi Jos,
>
> Thanks, I will correct the tutorial.
>
> I think Ed might have chased you out of the GMF newsgroup prematurely,
> as the use of OCL in our tutorial, and in GMF generally, is definitely
> something we'd like to discuss. Radek and I have replied to your post
> yesterday and can pick it up there, while general questions about EMF
> OCL are more appropriate here.
>
> Thanks,
> Rich
>
>> Hi all,
>>
>> I have gone through the tutorial from GMF. Doing that I did find some
>> errors in the OCL constraints, e.g.
>>
>> self <> oppositeEnd
>> oppositeEnd <> self
>> are considered correct. At the same time the follwoing are considered
>> incorect:
>>
>> self.oppositeEnd <> self
>> self <> self.oppositeEnd
>> ERROR in (variableExpCS): (Variable cannot appear in the middle
>> of a
>> navigation expression: (oppositeEnd))
>> oppositeEnd is nothing than a shorthand for self.oppositeEnd,
>> therefore all of the above should be correct.
>>
>> Looks like a bug in the OCL parser/analyzer.
>>
>> Jos Warmer
>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Incorrect OCL error messages on correct OCL [message #565144 is a reply to message #19426] |
Tue, 31 January 2006 15:04 |
Richard Gronback
Messages: 605
Registered: July 2009 |
Senior Member |
|
|
Not a problem! :)
> Rich,
>
> Sorry. I didn't mean to chase anyone away. I'll try to be a little
> less helpful in cases where I don't know all the context...
>
> Richard Gronback wrote:
>
>> Hi Jos,
>>
>> Thanks, I will correct the tutorial.
>>
>> I think Ed might have chased you out of the GMF newsgroup
>> prematurely, as the use of OCL in our tutorial, and in GMF generally,
>> is definitely something we'd like to discuss. Radek and I have
>> replied to your post yesterday and can pick it up there, while
>> general questions about EMF OCL are more appropriate here.
>>
>> Thanks,
>> Rich
>>> Hi all,
>>>
>>> I have gone through the tutorial from GMF. Doing that I did find
>>> some errors in the OCL constraints, e.g.
>>>
>>> self <> oppositeEnd
>>> oppositeEnd <> self
>>> are considered correct. At the same time the follwoing are
>>> considered
>>> incorect:
>>> self.oppositeEnd <> self
>>> self <> self.oppositeEnd
>>> ERROR in (variableExpCS): (Variable cannot appear in the middle
>>> of a
>>> navigation expression: (oppositeEnd))
>>> oppositeEnd is nothing than a shorthand for self.oppositeEnd,
>>> therefore all of the above should be correct.
>>> Looks like a bug in the OCL parser/analyzer.
>>>
>>> Jos Warmer
>>>
|
|
|
| Re: Incorrect OCL error messages on correct OCL [message #565196 is a reply to message #19379] |
Wed, 01 February 2006 03:58 |
Jos Warmer
Messages: 66
Registered: July 2009 |
Member |
|
|
Radek,
You might be right, but I cannot tell from the context that I have.
OCL is written in the context of a model (this can also be a meta-model
of course). If you can give me a pointer to the model that the OCL in
the GMF tutorial is referring to, I can figure out what is going on and
whether you are right or not.
It seems to me that the OCL in the constraint probably refers to the
(meta)model of the graph definition, the mapping definition and/or the
ecore model definition.
Regards, Jos
Radek Dvorak wrote:
> Hi Jos,
>
> The 'oppositeEnd' in the GMF tutorial is a variable added to the Environment
> by the containing gmf-editor plugin.
> The reason is to allow access to both source and target ends which
> participate in a link creation.
> Here 'self' references the source end and 'oppositeEnd' points to the target
> end node.
>
> My understanding of the spec is that if there is a defined variable
> 'oppositeEnd' in the current scope it is resolved as VariableExp.
> If not, 'self' would be checked for corresponding AttributeCallExp,
> NavigationCallExp.
>
> According to this, the reported ERROR seems to me OK.
> Or have I missed something ?
>
> Regards,
> /Radek
>
>
> "Jos Warmer" <jos.warmer@klasse.nl> wrote in message
> news:drn71o$9qf$1@utils.eclipse.org...
>> Hi all,
>>
>> I have gone through the tutorial from GMF. Doing that I did find some
>> errors in the OCL constraints, e.g.
>>
>> self <> oppositeEnd
>> oppositeEnd <> self
>>
>> are considered correct. At the same time the follwoing are considered
>> incorect:
>>
>> self.oppositeEnd <> self
>> self <> self.oppositeEnd
>>
>> ERROR in (variableExpCS): (Variable cannot appear in the middle of a
>> navigation expression: (oppositeEnd))
>>
>> oppositeEnd is nothing than a shorthand for self.oppositeEnd, therefore
>> all of the above should be correct.
>>
>> Looks like a bug in the OCL parser/analyzer.
>>
>> Jos Warmer
>
>
|
|
|
| Re: Incorrect OCL error messages on correct OCL [message #565245 is a reply to message #19562] |
Wed, 01 February 2006 11:57 |
Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Hi Jos,
The forementioned expression is defined in the context of 'mindmap::Topic'
classifier (/org.eclipse.gmf.examples.mindmap/model/mindmap.ecore).
The constraint is manifested as restriction to a link source end (context)
and the source end here is 'Topic' as the link is realized by 'subtopics'
reference owned
by 'Topic'. The target end in this case is 'Topic' as well.
This is all a contract introduced by gmf mapping and in addition, the
resulting Environment is extended with addition of 'oppositeEnd' variable.
It references the opposite end of the link and has correspoding type
depending on wheter referenced from source or target end context.
There is no model property 'oppositeEnd' in 'Topic' classifier.
This variable was introduced to be able to check all link creation
participants before the link creation is finished and model updated.
I propose that any further gmf specific details we continue in gmf news
group.
Regards,
/Radek
"Jos Warmer" <jos.warmer@klasse.nl> wrote in message
news:dro1fs$2tr$1@utils.eclipse.org...
> Radek,
>
> You might be right, but I cannot tell from the context that I have.
>
> OCL is written in the context of a model (this can also be a meta-model of
> course). If you can give me a pointer to the model that the OCL in the GMF
> tutorial is referring to, I can figure out what is going on and whether
> you are right or not.
>
> It seems to me that the OCL in the constraint probably refers to the
> (meta)model of the graph definition, the mapping definition and/or the
> ecore model definition.
>
> Regards, Jos
>
> Radek Dvorak wrote:
>> Hi Jos,
>>
>> The 'oppositeEnd' in the GMF tutorial is a variable added to the
>> Environment by the containing gmf-editor plugin.
>> The reason is to allow access to both source and target ends which
>> participate in a link creation.
>> Here 'self' references the source end and 'oppositeEnd' points to the
>> target end node.
>>
>> My understanding of the spec is that if there is a defined variable
>> 'oppositeEnd' in the current scope it is resolved as VariableExp.
>> If not, 'self' would be checked for corresponding AttributeCallExp,
>> NavigationCallExp.
>>
>> According to this, the reported ERROR seems to me OK.
>> Or have I missed something ?
>>
>> Regards,
>> /Radek
>>
>>
>> "Jos Warmer" <jos.warmer@klasse.nl> wrote in message
>> news:drn71o$9qf$1@utils.eclipse.org...
>>> Hi all,
>>>
>>> I have gone through the tutorial from GMF. Doing that I did find some
>>> errors in the OCL constraints, e.g.
>>>
>>> self <> oppositeEnd
>>> oppositeEnd <> self
>>>
>>> are considered correct. At the same time the follwoing are considered
>>> incorect:
>>>
>>> self.oppositeEnd <> self
>>> self <> self.oppositeEnd
>>>
>>> ERROR in (variableExpCS): (Variable cannot appear in the middle of a
>>> navigation expression: (oppositeEnd))
>>>
>>> oppositeEnd is nothing than a shorthand for self.oppositeEnd, therefore
>>> all of the above should be correct.
>>>
>>> Looks like a bug in the OCL parser/analyzer.
>>>
>>> Jos Warmer
>>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 16:27:11 GMT 2024
Powered by FUDForum. Page generated in 0.04318 seconds |
] 
Search
Help
Register
Login
Home
