Home » Archived » M2M (model-to-model transformation) » [QVTO] Parser error using enumeration
| [QVTO] Parser error using enumeration [message #91206] |
Fri, 03 October 2008 14:01  |
Eclipse User |
|
|
|
Originally posted by: jbocanegra.uniamazonia.edu.co
Hi.
I am using a BPMN metamodel that containts a ActivityType enum. Some
elements are (Task, SubProcess, EventStartEmpty)
If i use the element called Task, it works good, but, if i use the element
called EventStartEmpty it dont work.
--This work
var VertStart:Activity :=object Activity{
name:='Start';
activityType:=ActivityType::Task
}
--This dont work
var VertStart:Activity :=object Activity{
name:='Start';
activityType:=ActivityType::EventStartEmpty
}
In an ATl example the EventStartEmpty works good.
--AtL example
VertStart : bpmn!Activity (activityType<-#EventStartEmpty)
There a way to get around this problem?
Thanks,
Jos
|
|
|
| Re: [QVTO] Parser error using enumeration [message #91221 is a reply to message #91206] |
Fri, 03 October 2008 16:39  |
 Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Hi José,
When looking at the 'ActivityType' enumeration, I can see that
there is no 'ActivityType::EventStartEmpty' enum literal but
'ActivityType::Empty Start Event' instead.
Such a name with spaces inside is actually not a well-formed name and ecore
validation reports an error in this case.
Also, it's surprising that ATL works in this case.
MDT OCL comes with a non-stdandard option to enclose multi token names in
quotes, like "...".
QVTO does not enable this as we would get collisions with "" String
literal, which should work
in QVT as well as ''.
I will take a look again at quoted names and will let you know what can be
done.
However, it's strange to me that an invalid ecore model is registered into
the global registry.
Regards,
/Radek
On Fri, 03 Oct 2008 16:01:18 +0200, Jose Bocanegra
<jbocanegra@uniamazonia.edu.co> wrote:
> Hi.
>
> I am using a BPMN metamodel that containts a ActivityType enum. Some
> elements are (Task, SubProcess, EventStartEmpty)
>
> If i use the element called Task, it works good, but, if i use the
> element
> called EventStartEmpty it dont work.
>
> --This work
>
> var VertStart:Activity :=object Activity{
> name:='Start';
> activityType:=ActivityType::Task
> }
>
> --This dont work
>
> var VertStart:Activity :=object Activity{
> name:='Start';
> activityType:=ActivityType::EventStartEmpty
> }
>
> In an ATl example the EventStartEmpty works good.
>
> --AtL example
> VertStart : bpmn!Activity (activityType<-#EventStartEmpty)
>
>
> There a way to get around this problem?
>
> Thanks,
>
> José
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: [QVTO] Parser error using enumeration [message #91236 is a reply to message #91221] |
Fri, 03 October 2008 16:42 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Radek,
Ecore's validation is intended to ensure sane code generation, so where
names are concerned, it requires well-formed Java identifiers. One can
argue that these rules should not be applied to dynamic Ecore models.
In any case, EMF does not make any attempt to validate models when they
are registered ... I don't think it should be concerned about that,
because it is mainly an issue for textual languages like OCL and QVT.
Why did the QVT spec find it necessary to provide a redundant
string-literal delimiter? To handle the problem of embedded apostrophes?
Cheers,
Christian
Radek Dvorak wrote:
> Hi José,
>
> When looking at the 'ActivityType' enumeration, I can see that
> there is no 'ActivityType::EventStartEmpty' enum literal but
> 'ActivityType::Empty Start Event' instead.
> Such a name with spaces inside is actually not a well-formed name and ecore
> validation reports an error in this case.
> Also, it's surprising that ATL works in this case.
>
> MDT OCL comes with a non-stdandard option to enclose multi token names
> in quotes, like "...".
> QVTO does not enable this as we would get collisions with "" String
> literal, which should work
> in QVT as well as ''.
>
> I will take a look again at quoted names and will let you know what can
> be done.
> However, it's strange to me that an invalid ecore model is registered
> into the global registry.
>
> Regards,
> /Radek
>
>
> On Fri, 03 Oct 2008 16:01:18 +0200, Jose Bocanegra
> <jbocanegra@uniamazonia.edu.co> wrote:
>
>> Hi.
>>
>> I am using a BPMN metamodel that containts a ActivityType enum. Some
>> elements are (Task, SubProcess, EventStartEmpty)
>>
>> If i use the element called Task, it works good, but, if i use the
>> element
>> called EventStartEmpty it dont work.
>>
>> --This work
>>
>> var VertStart:Activity :=object Activity{
>> name:='Start';
>> activityType:=ActivityType::Task
>> }
>>
>> --This dont work
>>
>> var VertStart:Activity :=object Activity{
>> name:='Start';
>> activityType:=ActivityType::EventStartEmpty
>> }
>>
>> In an ATl example the EventStartEmpty works good.
>>
>> --AtL example
>> VertStart : bpmn!Activity (activityType<-#EventStartEmpty)
>>
>>
>> There a way to get around this problem?
>>
>> Thanks,
>>
>> José
>>
>>
>
>
>
|
|
|
| Re: [QVTO] Parser error using enumeration [message #91266 is a reply to message #91221] |
Fri, 03 October 2008 17:05 |
| Eclipse User |
|
|
|
Originally posted by: jbocanegra.uniamazonia.edu.co
Hi Radek.
I have seen the BPMN metamodel in the BPMN.ecore_diagram and the
ActivityType enum elements appear without spaces. However, when I see the
metamodel in the 'Metamodel Explorer' the enum elements appear with spaces.
This is very strange.
Jos
|
|
|
| Re: [QVTO] Parser error using enumeration [message #91281 is a reply to message #91266] |
Fri, 03 October 2008 17:13 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Jose,
In the Ecore metamodel, EEnums have both a "name" and a "literal"
attribute. The literal is used for serialization only, but the name is
used in code generation (I think). The same naming rules may not apply
to both.
OCL (and hence, I think, QVTo) uses the name attribute when looking up
the enumeration literal referenced by an expression.
Cheers,
Christian
Jose Bocanegra wrote:
> Hi Radek.
>
> I have seen the BPMN metamodel in the BPMN.ecore_diagram and the
> ActivityType enum elements appear without spaces. However, when I see the
> metamodel in the 'Metamodel Explorer' the enum elements appear with spaces.
>
> This is very strange.
>
> José.
>
> "Radek Dvorak" <radek.dvorak@borland.com> escribió en el mensaje
> news:op.uigi7mtqhj1a1g@czprl-rdvorak2.emea.borl.net...
>> Hi José,
>>
>> When looking at the 'ActivityType' enumeration, I can see that
>> there is no 'ActivityType::EventStartEmpty' enum literal but
>> 'ActivityType::Empty Start Event' instead.
>> Such a name with spaces inside is actually not a well-formed name and
>> ecore
>> validation reports an error in this case.
>> Also, it's surprising that ATL works in this case.
>>
>> MDT OCL comes with a non-stdandard option to enclose multi token names in
>> quotes, like "...".
>> QVTO does not enable this as we would get collisions with "" String
>> literal, which should work
>> in QVT as well as ''.
>>
>> I will take a look again at quoted names and will let you know what can be
>> done.
>> However, it's strange to me that an invalid ecore model is registered into
>> the global registry.
>>
>> Regards,
>> /Radek
>>
>>
>> On Fri, 03 Oct 2008 16:01:18 +0200, Jose Bocanegra
>> <jbocanegra@uniamazonia.edu.co> wrote:
>>
>>> Hi.
>>>
>>> I am using a BPMN metamodel that containts a ActivityType enum. Some
>>> elements are (Task, SubProcess, EventStartEmpty)
>>>
>>> If i use the element called Task, it works good, but, if i use the
>>> element
>>> called EventStartEmpty it dont work.
>>>
>>> --This work
>>>
>>> var VertStart:Activity :=object Activity{
>>> name:='Start';
>>> activityType:=ActivityType::Task
>>> }
>>>
>>> --This dont work
>>>
>>> var VertStart:Activity :=object Activity{
>>> name:='Start';
>>> activityType:=ActivityType::EventStartEmpty
>>> }
>>>
>>> In an ATl example the EventStartEmpty works good.
>>>
>>> --AtL example
>>> VertStart : bpmn!Activity (activityType<-#EventStartEmpty)
>>>
>>>
>>> There a way to get around this problem?
>>>
>>> Thanks,
>>>
>>> José
>>>
>>>
>>
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
>
|
|
|
| Re: [QVTO] Parser error using enumeration [message #91296 is a reply to message #91236] |
Fri, 03 October 2008 18:01 |
Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
> Ecore's validation is intended to ensure sane code generation, so where
> names are concerned, it requires well-formed Java identifiers. One can
> argue that these rules should not be applied to dynamic Ecore models.
I simply ran validation on a simple ecore model containing such enum
literal with
spaces and got that validation error.
No code generation involved and one may still consider this ecore model
invalid ;).
Perhaps, if such constraint is rather related to code generation,
a genmodel constraint might be more appropriate.
However, I think I understand the practical aspect of this constraint and
agree that QVT should be able to cope with that ;).
> In any case, EMF does not make any attempt to validate models when they
> are registered ... I don't think it should be concerned about that,
> because it is mainly an issue for textual languages like OCL and QVT.
Ah, I did not mean EMF should validate models on registration, for sure.
What I had in mind is generating java model from a valid ecore file, as
it finally gets into the global registry at runtime, too late to validate
then, IMO ;).
> Why did the QVT spec find it necessary to provide a redundant
> string-literal delimiter? To handle the problem of embedded apostrophes?
To be honest, I have no idea. It had been there before I first touched QVT.
Also, it is not the only case of redundancy in QVT.
Regards,
/Radek
|
|
|
| Re: [QVTO] Parser error using enumeration [message #91311 is a reply to message #91296] |
Fri, 03 October 2008 18:32 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Radek,
Comments below.
Radek Dvorak wrote:
> Hi Christian,
>
>> Ecore's validation is intended to ensure sane code generation, so
>> where names are concerned, it requires well-formed Java identifiers.
>> One can argue that these rules should not be applied to dynamic Ecore
>> models.
>
> I simply ran validation on a simple ecore model containing such enum
> literal with
> spaces and got that validation error.
We also use fragment paths to be able to refer to enum literals by
name. Such constraints on the names is not so different from XML Schema
requiring named components to use NCNames.
> No code generation involved and one may still consider this ecore model
> invalid ;).
It's our privilege to to decide what's valid. :-P Of course these kinds
of constraints are potentially useful when writing an expression
language against Ecore too by ensuring that names with a constrained set
of characters will be used....
> Perhaps, if such constraint is rather related to code generation,
> a genmodel constraint might be more appropriate.
In theory certainly, but I don't agree with that in this case.
>
> However, I think I understand the practical aspect of this constraint and
> agree that QVT should be able to cope with that ;).
After all, the literal value allows an arbitrary string to be serialized
as a data value...
>
>> In any case, EMF does not make any attempt to validate models when
>> they are registered ... I don't think it should be concerned about
>> that, because it is mainly an issue for textual languages like OCL
>> and QVT.
>
> Ah, I did not mean EMF should validate models on registration, for sure.
> What I had in mind is generating java model from a valid ecore file, as
> it finally gets into the global registry at runtime, too late to validate
> then, IMO ;).
Note that dynamic_package allows serialized models to be registered just
like generated ones...
>
>> Why did the QVT spec find it necessary to provide a redundant
>> string-literal delimiter? To handle the problem of embedded
>> apostrophes?
>
> To be honest, I have no idea. It had been there before I first touched
> QVT.
> Also, it is not the only case of redundancy in QVT.
I guess you can't have too much syntax, but you could have too little.
Some folks have argued that they should be able to define an EOperation
named "+", for example, but that's not allowed either.
>
>
> Regards,
> /Radek
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [QVTO] Parser error using enumeration [message #91325 is a reply to message #91266] |
Fri, 03 October 2008 20:05 |
Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
------------M8PzjayXjaigbuDnJBaarM
Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8
Content-Transfer-Encoding: 8bit
Hi José,
In the meantime (before we have a proper solution :),
I propose, that you could drop the contents of the attached zip file into
your QVT project.
This forces your transformations to resolve to
platform:/plugin/org.eclipse.stp.bpmn/model/bpmn.ecore.
That ecore model does not suffer from the spaces in name issues.
See the QVT code bellow, working fine after this step.
modeltype BPMN uses bpmn("http://stp.eclipse.org/bpmn");
transformation BPMNTest(inout bpmn : BPMN);
main() {
object BpmnDiagram {
pools += object Pool {
vertices += object Activity {
name := 'Foo';
activityType := ActivityType::EventStartEmpty;
};
}
};
}
Regards,
/Radek
On Fri, 03 Oct 2008 19:05:41 +0200, Jose Bocanegra
<jbocanegra@uniamazonia.edu.co> wrote:
> Hi Radek.
>
> I have seen the BPMN metamodel in the BPMN.ecore_diagram and the
> ActivityType enum elements appear without spaces. However, when I see the
> metamodel in the 'Metamodel Explorer' the enum elements appear with
> spaces.
>
> This is very strange.
>
> José.
>
> "Radek Dvorak" <radek.dvorak@borland.com> escribió en el mensaje
> news:op.uigi7mtqhj1a1g@czprl-rdvorak2.emea.borl.net...
>> Hi José,
>>
>> When looking at the 'ActivityType' enumeration, I can see that
>> there is no 'ActivityType::EventStartEmpty' enum literal but
>> 'ActivityType::Empty Start Event' instead.
>> Such a name with spaces inside is actually not a well-formed name and
>> ecore
>> validation reports an error in this case.
>> Also, it's surprising that ATL works in this case.
>>
>> MDT OCL comes with a non-stdandard option to enclose multi token names
>> in
>> quotes, like "...".
>> QVTO does not enable this as we would get collisions with "" String
>> literal, which should work
>> in QVT as well as ''.
>>
>> I will take a look again at quoted names and will let you know what can
>> be
>> done.
>> However, it's strange to me that an invalid ecore model is registered
>> into
>> the global registry.
>>
>> Regards,
>> /Radek
>>
>>
>> On Fri, 03 Oct 2008 16:01:18 +0200, Jose Bocanegra
>> <jbocanegra@uniamazonia.edu.co> wrote:
>>
>>> Hi.
>>>
>>> I am using a BPMN metamodel that containts a ActivityType enum. Some
>>> elements are (Task, SubProcess, EventStartEmpty)
>>>
>>> If i use the element called Task, it works good, but, if i use the
>>> element
>>> called EventStartEmpty it dont work.
>>>
>>> --This work
>>>
>>> var VertStart:Activity :=object Activity{
>>> name:='Start';
>>> activityType:=ActivityType::Task
>>> }
>>>
>>> --This dont work
>>>
>>> var VertStart:Activity :=object Activity{
>>> name:='Start';
>>> activityType:=ActivityType::EventStartEmpty
>>> }
>>>
>>> In an ATl example the EventStartEmpty works good.
>>>
>>> --AtL example
>>> VertStart : bpmn!Activity (activityType<-#EventStartEmpty)
>>>
>>>
>>> There a way to get around this problem?
>>>
>>> Thanks,
>>>
>>> José
>>>
>>>
>>
>>
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
------------M8PzjayXjaigbuDnJBaarM
Content-Disposition: attachment; filename=.settings.zip
Content-Type: application/zip; name=.settings.zip
Content-Transfer-Encoding: Base64
UEsDBBQAAAAIAEurQzmbroC70wAAAFMBAAAvAAAALnNldHRpbmdzL29yZy5l Y2xp
cHNlLm0ybS5xdnQub21sLm1tb2RlbC51cmltYXB1kLFuwyAQhvdKeQfEA/ia jMhO
VGXy4KVRpKyuQygSx1HAcR4/B1EtdejAwn3ff7+uPTzQibuOyZLv5LZ5l0L7 ia7W
m05+nI59Lw/7zVs7RzuMQfELPDqSz6P1OooHWrXqu6JzoE+K/zv5nXNQAMuy NISm
oWjgMvS/yCtypSqmJ2dD0hXFHcLPPQOhg2Ggq3bnagC35EXcSogWX4VEojlO +vzZ
r3kphz9xXwG9FHmMRufKBTfmG0VUENxsrAemVqPYxQAsi6vMM4paQjkH/HMP nj0B
UEsDBAoAAAAAAISuQzkAAAAAAAAAAAAAAAAKAAAALnNldHRpbmdzL1BLAQIU ABQA
AAAIAEurQzmbroC70wAAAFMBAAAvAAAAAAAAAAEAIAC2gQAAAAAuc2V0dGlu Z3Mv
b3JnLmVjbGlwc2UubTJtLnF2dC5vbWwubW1vZGVsLnVyaW1hcFBLAQIUAAoA AAAA
AISuQzkAAAAAAAAAAAAAAAAKAAAAAAAAAAAAEAD/QSABAAAuc2V0dGluZ3Mv UEsF
BgAAAAACAAIAlQAAAEgBAAAAAA==
------------M8PzjayXjaigbuDnJBaarM--
|
|
|
| Re: [QVTO] Parser error using enumeration [message #91340 is a reply to message #91325] |
Fri, 03 October 2008 21:32 |
| Eclipse User |
|
|
|
Originally posted by: jbocanegra.uniamazonia.edu.co
Hi Radek.
I have placed the file in my QVT project, but the error still apears :(
Attached I send a screenshot of the editor.
Can I be doing something wrong?
Regards,
Jos
|
|
|
| Re: [QVTO] Parser error using enumeration [message #91356 is a reply to message #91340] |
Fri, 03 October 2008 21:44 |
Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Make sure you extract the contents of the zip file into your project.
You should get the file bellow there.
projectName/.settings/org.eclipse.m2m.qvt.oml.mmodel.urimap
/Radek
On Fri, 03 Oct 2008 23:32:25 +0200, Jose Bocanegra
<jbocanegra@uniamazonia.edu.co> wrote:
> Hi Radek.
>
> I have placed the file in my QVT project, but the error still apears :(
>
> Attached I send a screenshot of the editor.
>
> Can I be doing something wrong?
>
> Regards,
>
> José.
>
> "Radek Dvorak" <radek.dvorak@borland.com> escribió en el mensaje
> news:op.uigsrvmhhj1a1g@czprl-rdvorak2.emea.borl.net...
>> Hi José,
>>
>> In the meantime (before we have a proper solution :),
>> I propose, that you could drop the contents of the attached zip file
>> into
>> your QVT project.
>> This forces your transformations to resolve to
>> platform:/plugin/org.eclipse.stp.bpmn/model/bpmn.ecore.
>> That ecore model does not suffer from the spaces in name issues.
>> See the QVT code bellow, working fine after this step.
>>
>> modeltype BPMN uses bpmn("http://stp.eclipse.org/bpmn");
>>
>> transformation BPMNTest(inout bpmn : BPMN);
>>
>> main() {
>> object BpmnDiagram {
>> pools += object Pool {
>> vertices += object Activity {
>> name := 'Foo';
>> activityType := ActivityType::EventStartEmpty;
>> };
>> }
>> };
>> }
>>
>> Regards,
>> /Radek
>>
>> On Fri, 03 Oct 2008 19:05:41 +0200, Jose Bocanegra
>> <jbocanegra@uniamazonia.edu.co> wrote:
>>
>>> Hi Radek.
>>>
>>> I have seen the BPMN metamodel in the BPMN.ecore_diagram and the
>>> ActivityType enum elements appear without spaces. However, when I see
>>> the
>>> metamodel in the 'Metamodel Explorer' the enum elements appear with
>>> spaces.
>>>
>>> This is very strange.
>>>
>>> José.
>>>
>>> "Radek Dvorak" <radek.dvorak@borland.com> escribió en el mensaje
>>> news:op.uigi7mtqhj1a1g@czprl-rdvorak2.emea.borl.net...
>>>> Hi José,
>>>>
>>>> When looking at the 'ActivityType' enumeration, I can see that
>>>> there is no 'ActivityType::EventStartEmpty' enum literal but
>>>> 'ActivityType::Empty Start Event' instead.
>>>> Such a name with spaces inside is actually not a well-formed name and
>>>> ecore
>>>> validation reports an error in this case.
>>>> Also, it's surprising that ATL works in this case.
>>>>
>>>> MDT OCL comes with a non-stdandard option to enclose multi token names
>>>> in
>>>> quotes, like "...".
>>>> QVTO does not enable this as we would get collisions with "" String
>>>> literal, which should work
>>>> in QVT as well as ''.
>>>>
>>>> I will take a look again at quoted names and will let you know what
>>>> can
>>>> be
>>>> done.
>>>> However, it's strange to me that an invalid ecore model is registered
>>>> into
>>>> the global registry.
>>>>
>>>> Regards,
>>>> /Radek
>>>>
>>>>
>>>> On Fri, 03 Oct 2008 16:01:18 +0200, Jose Bocanegra
>>>> <jbocanegra@uniamazonia.edu.co> wrote:
>>>>
>>>>> Hi.
>>>>>
>>>>> I am using a BPMN metamodel that containts a ActivityType enum. Some
>>>>> elements are (Task, SubProcess, EventStartEmpty)
>>>>>
>>>>> If i use the element called Task, it works good, but, if i use the
>>>>> element
>>>>> called EventStartEmpty it dont work.
>>>>>
>>>>> --This work
>>>>>
>>>>> var VertStart:Activity :=object Activity{
>>>>> name:='Start';
>>>>> activityType:=ActivityType::Task
>>>>> }
>>>>>
>>>>> --This dont work
>>>>>
>>>>> var VertStart:Activity :=object Activity{
>>>>> name:='Start';
>>>>> activityType:=ActivityType::EventStartEmpty
>>>>> }
>>>>>
>>>>> In an ATl example the EventStartEmpty works good.
>>>>>
>>>>> --AtL example
>>>>> VertStart : bpmn!Activity (activityType<-#EventStartEmpty)
>>>>>
>>>>>
>>>>> There a way to get around this problem?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> José
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>>>
>>>
>>
>>
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 11:33:37 GMT 2024
Powered by FUDForum. Page generated in 0.03156 seconds |
] 
Search
Help
Register
Login
Home
