Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMF Compare] Innacuracies while comparing lists of very similar elements
| |
| Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #124053 is a reply to message #123712] |
Fri, 30 May 2008 08:06   |
 Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi Víctor,
thanks for your feedback, you're not bothering us *at all* and the issues
you may encounter are likely to be encountered by other users not taking
the time to ask on the newsgroup, then thanks again :)
Cédric
Víctor Roldán Betancort wrote:
> Sorry to bother again about EMF Compare. I hope to help while reporting
> my findings.
>
> Try to imagine a multivalued referenced with lots of referenced
> children. These elements are simple named elements. Take a look at the
> following example (I'll put just 2 lists of names of these elements):
>
> ELEMENT01 -- ELEMENT01
> ELEMENT02 -- ELEMENT02
> ELEMENT03 -- ELEMENT03
> ELEMENT04 -- ELEMENT04
> ELEMENT05 -- ELEMENT05
> ELEMENT06 -- ELEMENT06
> ELEMENT07 -- ELEMENT07
>
> If I remove one element from the second EReference:
>
> ELEMENT01 -- ELEMENT01
> ELEMENT02 -- ELEMENT02
> ELEMENT03 -- .........
> ELEMENT04 -- ELEMENT04
> ELEMENT05 -- ELEMENT05
> ELEMENT06 -- ELEMENT06
> ELEMENT07 -- ELEMENT07
>
> The comparison will result in (its an example, but happens most of the
> times):
>
> ELEMENT01 -- ELEMENT01 <match>
> ELEMENT02 -- ELEMENT02 <match>
> ELEMENT03 -- ......... <deleted>
> ELEMENT04 -- ELEMENT05 <modified>
> ELEMENT05 -- ELEMENT06 <modified>
> ELEMENT06 -- ELEMENT04 <modified>
> ELEMENT07 -- ELEMENT07 <match>
>
> This is just an example situation, but as you can see, the engine tries
> to match elements in the same position, and gets a high similarity score
> (since these elements are very similar, even in the name).
>
> In my opinion, the engine should take a look in the neighborhood to
> search for a perfect match. In case there is no perfect match, then it
> could match those with the highest similarity score.
>
> Cheers!
>
> Víctor.
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
| Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #124800 is a reply to message #124053] |
Mon, 02 June 2008 09:39 |
|
This is a multi-part message in MIME format.
--------------070408040506040808080108
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Hi Víctor,
I took some time to tests this and couldn't reproduce your behavior with
the latest version of EMF Compare (0.8RC2 as I write this). My test case
was a simple ecore model with classes named ELEMENTx as you outlined in
your example, then deleting class ELEMENT3 was detected accurately by
EMF Compare. The same occured with EEnumLiterals named LITERALxx ... The
elements' name was the only thing I modified for this test.
Which version of Eclipse/EMF Compare are you using to reproduce this
bug? And can you provide us with the models you were comparing if they
do not contain any confidential information (preferred form is of course
a bug on Eclipse bugzilla ;)).
Laurent Goubet
Obeo
Cédric Brun a écrit :
> Hi Víctor,
>
> thanks for your feedback, you're not bothering us *at all* and the issues
> you may encounter are likely to be encountered by other users not taking
> the time to ask on the newsgroup, then thanks again :)
>
> Cédric
>
> Víctor Roldán Betancort wrote:
>
>> Sorry to bother again about EMF Compare. I hope to help while reporting
>> my findings.
>>
>> Try to imagine a multivalued referenced with lots of referenced
>> children. These elements are simple named elements. Take a look at the
>> following example (I'll put just 2 lists of names of these elements):
>>
>> ELEMENT01 -- ELEMENT01
>> ELEMENT02 -- ELEMENT02
>> ELEMENT03 -- ELEMENT03
>> ELEMENT04 -- ELEMENT04
>> ELEMENT05 -- ELEMENT05
>> ELEMENT06 -- ELEMENT06
>> ELEMENT07 -- ELEMENT07
>>
>> If I remove one element from the second EReference:
>>
>> ELEMENT01 -- ELEMENT01
>> ELEMENT02 -- ELEMENT02
>> ELEMENT03 -- .........
>> ELEMENT04 -- ELEMENT04
>> ELEMENT05 -- ELEMENT05
>> ELEMENT06 -- ELEMENT06
>> ELEMENT07 -- ELEMENT07
>>
>> The comparison will result in (its an example, but happens most of the
>> times):
>>
>> ELEMENT01 -- ELEMENT01 <match>
>> ELEMENT02 -- ELEMENT02 <match>
>> ELEMENT03 -- ......... <deleted>
>> ELEMENT04 -- ELEMENT05 <modified>
>> ELEMENT05 -- ELEMENT06 <modified>
>> ELEMENT06 -- ELEMENT04 <modified>
>> ELEMENT07 -- ELEMENT07 <match>
>>
>> This is just an example situation, but as you can see, the engine tries
>> to match elements in the same position, and gets a high similarity score
>> (since these elements are very similar, even in the name).
>>
>> In my opinion, the engine should take a look in the neighborhood to
>> search for a perfect match. In case there is no perfect match, then it
>> could match those with the highest similarity score.
>>
>> Cheers!
>>
>> Víctor.
>
--------------070408040506040808080108
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"
YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyLyI+T2JlbzwvYT4NCmVtYWls O2ludGVybmV0
OmxhdXJlbnQuZ291YmV0QG9iZW8uZnINCnVybDpodHRwOi8vd3d3Lm9iZW8u ZnINCnZlcnNp
b246Mi4xDQplbmQ6dmNhcmQNCg0K
--------------070408040506040808080108--
|
|
|
| Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #124859 is a reply to message #124800] |
Mon, 02 June 2008 11:15 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Laurent,
I think I must have correct one premise I posted in first instance:
these model elements aren't just plain elements, I mean, these element
weren't just classes with attributes, but rather classes with a mix of
attribs and references to other elements. Furthermore, another
characteristic I see is that these elements are part of a particular
hierarchy of EClasses. Using the original example, this would mean that
"ELEMENTx" is inherits from a somehow complex inheritance tree (lets
say, for instance, something like ELEMENTBASE -> ELEMENTABSTRACT -> ...
-> ELEMENT).
I'm using bleeding-edge stuff (All RC2 that's available). Using EMF
Compare 0.8RC2.
Unfortunately, as you say, the models I'm working on have confidential
information. I'll elaborate an "open source" clone of these
"confidential models" so I can provide it to you as test case ;) ;)
Regards,
Víctor.
laurent Goubet escribió:
> Hi Víctor,
>
> I took some time to tests this and couldn't reproduce your behavior with
> the latest version of EMF Compare (0.8RC2 as I write this). My test case
> was a simple ecore model with classes named ELEMENTx as you outlined in
> your example, then deleting class ELEMENT3 was detected accurately by
> EMF Compare. The same occured with EEnumLiterals named LITERALxx ... The
> elements' name was the only thing I modified for this test.
>
> Which version of Eclipse/EMF Compare are you using to reproduce this
> bug? And can you provide us with the models you were comparing if they
> do not contain any confidential information (preferred form is of course
> a bug on Eclipse bugzilla ;)).
>
> Laurent Goubet
> Obeo
>
> Cédric Brun a écrit :
>> Hi Víctor,
>>
>> thanks for your feedback, you're not bothering us *at all* and the issues
>> you may encounter are likely to be encountered by other users not taking
>> the time to ask on the newsgroup, then thanks again :)
>>
>> Cédric
>>
>> Víctor Roldán Betancort wrote:
>>
>>> Sorry to bother again about EMF Compare. I hope to help while reporting
>>> my findings.
>>>
>>> Try to imagine a multivalued referenced with lots of referenced
>>> children. These elements are simple named elements. Take a look at the
>>> following example (I'll put just 2 lists of names of these elements):
>>>
>>> ELEMENT01 -- ELEMENT01
>>> ELEMENT02 -- ELEMENT02
>>> ELEMENT03 -- ELEMENT03
>>> ELEMENT04 -- ELEMENT04
>>> ELEMENT05 -- ELEMENT05
>>> ELEMENT06 -- ELEMENT06
>>> ELEMENT07 -- ELEMENT07
>>>
>>> If I remove one element from the second EReference:
>>>
>>> ELEMENT01 -- ELEMENT01
>>> ELEMENT02 -- ELEMENT02
>>> ELEMENT03 -- .........
>>> ELEMENT04 -- ELEMENT04
>>> ELEMENT05 -- ELEMENT05
>>> ELEMENT06 -- ELEMENT06
>>> ELEMENT07 -- ELEMENT07
>>>
>>> The comparison will result in (its an example, but happens most of the
>>> times):
>>>
>>> ELEMENT01 -- ELEMENT01 <match>
>>> ELEMENT02 -- ELEMENT02 <match>
>>> ELEMENT03 -- ......... <deleted>
>>> ELEMENT04 -- ELEMENT05 <modified>
>>> ELEMENT05 -- ELEMENT06 <modified>
>>> ELEMENT06 -- ELEMENT04 <modified>
>>> ELEMENT07 -- ELEMENT07 <match>
>>>
>>> This is just an example situation, but as you can see, the engine tries
>>> to match elements in the same position, and gets a high similarity score
>>> (since these elements are very similar, even in the name).
>>>
>>> In my opinion, the engine should take a look in the neighborhood to
>>> search for a perfect match. In case there is no perfect match, then it
>>> could match those with the highest similarity score.
>>>
>>> Cheers!
>>>
>>> Víctor.
>>
>
|
|
|
| Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #124884 is a reply to message #124859] |
Mon, 02 June 2008 11:39 |
|
This is a multi-part message in MIME format.
--------------000109080502080507080501
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Thanks, will be waiting to try and fix these ;)
Laurent Goubet
Obeo
Víctor Roldán Betancort a écrit :
> Laurent,
>
> I think I must have correct one premise I posted in first instance:
> these model elements aren't just plain elements, I mean, these element
> weren't just classes with attributes, but rather classes with a mix of
> attribs and references to other elements. Furthermore, another
> characteristic I see is that these elements are part of a particular
> hierarchy of EClasses. Using the original example, this would mean that
> "ELEMENTx" is inherits from a somehow complex inheritance tree (lets
> say, for instance, something like ELEMENTBASE -> ELEMENTABSTRACT -> ...
> -> ELEMENT).
>
> I'm using bleeding-edge stuff (All RC2 that's available). Using EMF
> Compare 0.8RC2.
>
> Unfortunately, as you say, the models I'm working on have confidential
> information. I'll elaborate an "open source" clone of these
> "confidential models" so I can provide it to you as test case ;) ;)
>
> Regards,
> Víctor.
>
> laurent Goubet escribió:
>> Hi Víctor,
>>
>> I took some time to tests this and couldn't reproduce your behavior
>> with the latest version of EMF Compare (0.8RC2 as I write this). My
>> test case was a simple ecore model with classes named ELEMENTx as you
>> outlined in your example, then deleting class ELEMENT3 was detected
>> accurately by EMF Compare. The same occured with EEnumLiterals named
>> LITERALxx ... The elements' name was the only thing I modified for
>> this test.
>>
>> Which version of Eclipse/EMF Compare are you using to reproduce this
>> bug? And can you provide us with the models you were comparing if they
>> do not contain any confidential information (preferred form is of
>> course a bug on Eclipse bugzilla ;)).
>>
>> Laurent Goubet
>> Obeo
>>
>> Cédric Brun a écrit :
>>> Hi Víctor,
>>>
>>> thanks for your feedback, you're not bothering us *at all* and the
>>> issues
>>> you may encounter are likely to be encountered by other users not taking
>>> the time to ask on the newsgroup, then thanks again :)
>>>
>>> Cédric
>>>
>>> Víctor Roldán Betancort wrote:
>>>
>>>> Sorry to bother again about EMF Compare. I hope to help while reporting
>>>> my findings.
>>>>
>>>> Try to imagine a multivalued referenced with lots of referenced
>>>> children. These elements are simple named elements. Take a look at the
>>>> following example (I'll put just 2 lists of names of these elements):
>>>>
>>>> ELEMENT01 -- ELEMENT01
>>>> ELEMENT02 -- ELEMENT02
>>>> ELEMENT03 -- ELEMENT03
>>>> ELEMENT04 -- ELEMENT04
>>>> ELEMENT05 -- ELEMENT05
>>>> ELEMENT06 -- ELEMENT06
>>>> ELEMENT07 -- ELEMENT07
>>>>
>>>> If I remove one element from the second EReference:
>>>>
>>>> ELEMENT01 -- ELEMENT01
>>>> ELEMENT02 -- ELEMENT02
>>>> ELEMENT03 -- .........
>>>> ELEMENT04 -- ELEMENT04
>>>> ELEMENT05 -- ELEMENT05
>>>> ELEMENT06 -- ELEMENT06
>>>> ELEMENT07 -- ELEMENT07
>>>>
>>>> The comparison will result in (its an example, but happens most of the
>>>> times):
>>>>
>>>> ELEMENT01 -- ELEMENT01 <match>
>>>> ELEMENT02 -- ELEMENT02 <match>
>>>> ELEMENT03 -- ......... <deleted>
>>>> ELEMENT04 -- ELEMENT05 <modified>
>>>> ELEMENT05 -- ELEMENT06 <modified>
>>>> ELEMENT06 -- ELEMENT04 <modified>
>>>> ELEMENT07 -- ELEMENT07 <match>
>>>>
>>>> This is just an example situation, but as you can see, the engine tries
>>>> to match elements in the same position, and gets a high similarity
>>>> score
>>>> (since these elements are very similar, even in the name).
>>>>
>>>> In my opinion, the engine should take a look in the neighborhood to
>>>> search for a perfect match. In case there is no perfect match, then it
>>>> could match those with the highest similarity score.
>>>>
>>>> Cheers!
>>>>
>>>> Víctor.
>>>
>>
--------------000109080502080507080501
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"
YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyLyI+T2JlbzwvYT4NCmVtYWls O2ludGVybmV0
OmxhdXJlbnQuZ291YmV0QG9iZW8uZnINCnVybDpodHRwOi8vd3d3Lm9iZW8u ZnINCnZlcnNp
b246Mi4xDQplbmQ6dmNhcmQNCg0K
--------------000109080502080507080501--
|
|
|
| Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #124924 is a reply to message #124884] |
Mon, 02 June 2008 12:48 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Ok, got to reproduce it in a test metamodel. Should I open a bugzilla
and attach the files , or...?
laurent Goubet escribió:
> Thanks, will be waiting to try and fix these ;)
>
> Laurent Goubet
> Obeo
>
> Víctor Roldán Betancort a écrit :
>> Laurent,
>>
>> I think I must have correct one premise I posted in first instance:
>> these model elements aren't just plain elements, I mean, these element
>> weren't just classes with attributes, but rather classes with a mix of
>> attribs and references to other elements. Furthermore, another
>> characteristic I see is that these elements are part of a particular
>> hierarchy of EClasses. Using the original example, this would mean
>> that "ELEMENTx" is inherits from a somehow complex inheritance tree
>> (lets say, for instance, something like ELEMENTBASE -> ELEMENTABSTRACT
>> -> ... -> ELEMENT).
>>
>> I'm using bleeding-edge stuff (All RC2 that's available). Using EMF
>> Compare 0.8RC2.
>>
>> Unfortunately, as you say, the models I'm working on have confidential
>> information. I'll elaborate an "open source" clone of these
>> "confidential models" so I can provide it to you as test case ;) ;)
>>
>> Regards,
>> Víctor.
>>
>> laurent Goubet escribió:
>>> Hi Víctor,
>>>
>>> I took some time to tests this and couldn't reproduce your behavior
>>> with the latest version of EMF Compare (0.8RC2 as I write this). My
>>> test case was a simple ecore model with classes named ELEMENTx as you
>>> outlined in your example, then deleting class ELEMENT3 was detected
>>> accurately by EMF Compare. The same occured with EEnumLiterals named
>>> LITERALxx ... The elements' name was the only thing I modified for
>>> this test.
>>>
>>> Which version of Eclipse/EMF Compare are you using to reproduce this
>>> bug? And can you provide us with the models you were comparing if
>>> they do not contain any confidential information (preferred form is
>>> of course a bug on Eclipse bugzilla ;)).
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Cédric Brun a écrit :
>>>> Hi Víctor,
>>>>
>>>> thanks for your feedback, you're not bothering us *at all* and the
>>>> issues
>>>> you may encounter are likely to be encountered by other users not
>>>> taking
>>>> the time to ask on the newsgroup, then thanks again :)
>>>>
>>>> Cédric
>>>>
>>>> Víctor Roldán Betancort wrote:
>>>>
>>>>> Sorry to bother again about EMF Compare. I hope to help while
>>>>> reporting
>>>>> my findings.
>>>>>
>>>>> Try to imagine a multivalued referenced with lots of referenced
>>>>> children. These elements are simple named elements. Take a look at the
>>>>> following example (I'll put just 2 lists of names of these elements):
>>>>>
>>>>> ELEMENT01 -- ELEMENT01
>>>>> ELEMENT02 -- ELEMENT02
>>>>> ELEMENT03 -- ELEMENT03
>>>>> ELEMENT04 -- ELEMENT04
>>>>> ELEMENT05 -- ELEMENT05
>>>>> ELEMENT06 -- ELEMENT06
>>>>> ELEMENT07 -- ELEMENT07
>>>>>
>>>>> If I remove one element from the second EReference:
>>>>>
>>>>> ELEMENT01 -- ELEMENT01
>>>>> ELEMENT02 -- ELEMENT02
>>>>> ELEMENT03 -- .........
>>>>> ELEMENT04 -- ELEMENT04
>>>>> ELEMENT05 -- ELEMENT05
>>>>> ELEMENT06 -- ELEMENT06
>>>>> ELEMENT07 -- ELEMENT07
>>>>>
>>>>> The comparison will result in (its an example, but happens most of the
>>>>> times):
>>>>>
>>>>> ELEMENT01 -- ELEMENT01 <match>
>>>>> ELEMENT02 -- ELEMENT02 <match>
>>>>> ELEMENT03 -- ......... <deleted>
>>>>> ELEMENT04 -- ELEMENT05 <modified>
>>>>> ELEMENT05 -- ELEMENT06 <modified>
>>>>> ELEMENT06 -- ELEMENT04 <modified>
>>>>> ELEMENT07 -- ELEMENT07 <match>
>>>>>
>>>>> This is just an example situation, but as you can see, the engine
>>>>> tries
>>>>> to match elements in the same position, and gets a high similarity
>>>>> score
>>>>> (since these elements are very similar, even in the name).
>>>>>
>>>>> In my opinion, the engine should take a look in the neighborhood to
>>>>> search for a perfect match. In case there is no perfect match, then it
>>>>> could match those with the highest similarity score.
>>>>>
>>>>> Cheers!
>>>>>
>>>>> Víctor.
>>>>
>>>
>
|
|
|
| Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #124936 is a reply to message #124924] |
Mon, 02 June 2008 12:50 |
|
This is a multi-part message in MIME format.
--------------000100020104050708010102
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Yes, bugzilla will be easier to track evolutions of this.
Thanks!
Laurent Goubet
Obeo
Víctor Roldán Betancort a écrit :
> Ok, got to reproduce it in a test metamodel. Should I open a bugzilla
> and attach the files , or...?
>
> laurent Goubet escribió:
>> Thanks, will be waiting to try and fix these ;)
>>
>> Laurent Goubet
>> Obeo
>>
>> Víctor Roldán Betancort a écrit :
>>> Laurent,
>>>
>>> I think I must have correct one premise I posted in first instance:
>>> these model elements aren't just plain elements, I mean, these
>>> element weren't just classes with attributes, but rather classes with
>>> a mix of attribs and references to other elements. Furthermore,
>>> another characteristic I see is that these elements are part of a
>>> particular hierarchy of EClasses. Using the original example, this
>>> would mean that "ELEMENTx" is inherits from a somehow complex
>>> inheritance tree (lets say, for instance, something like ELEMENTBASE
>>> -> ELEMENTABSTRACT -> ... -> ELEMENT).
>>>
>>> I'm using bleeding-edge stuff (All RC2 that's available). Using EMF
>>> Compare 0.8RC2.
>>>
>>> Unfortunately, as you say, the models I'm working on have
>>> confidential information. I'll elaborate an "open source" clone of
>>> these "confidential models" so I can provide it to you as test case
>>> ;) ;)
>>>
>>> Regards,
>>> Víctor.
>>>
>>> laurent Goubet escribió:
>>>> Hi Víctor,
>>>>
>>>> I took some time to tests this and couldn't reproduce your behavior
>>>> with the latest version of EMF Compare (0.8RC2 as I write this). My
>>>> test case was a simple ecore model with classes named ELEMENTx as
>>>> you outlined in your example, then deleting class ELEMENT3 was
>>>> detected accurately by EMF Compare. The same occured with
>>>> EEnumLiterals named LITERALxx ... The elements' name was the only
>>>> thing I modified for this test.
>>>>
>>>> Which version of Eclipse/EMF Compare are you using to reproduce this
>>>> bug? And can you provide us with the models you were comparing if
>>>> they do not contain any confidential information (preferred form is
>>>> of course a bug on Eclipse bugzilla ;)).
>>>>
>>>> Laurent Goubet
>>>> Obeo
>>>>
>>>> Cédric Brun a écrit :
>>>>> Hi Víctor,
>>>>>
>>>>> thanks for your feedback, you're not bothering us *at all* and the
>>>>> issues
>>>>> you may encounter are likely to be encountered by other users not
>>>>> taking
>>>>> the time to ask on the newsgroup, then thanks again :)
>>>>>
>>>>> Cédric
>>>>>
>>>>> Víctor Roldán Betancort wrote:
>>>>>
>>>>>> Sorry to bother again about EMF Compare. I hope to help while
>>>>>> reporting
>>>>>> my findings.
>>>>>>
>>>>>> Try to imagine a multivalued referenced with lots of referenced
>>>>>> children. These elements are simple named elements. Take a look at
>>>>>> the
>>>>>> following example (I'll put just 2 lists of names of these elements):
>>>>>>
>>>>>> ELEMENT01 -- ELEMENT01
>>>>>> ELEMENT02 -- ELEMENT02
>>>>>> ELEMENT03 -- ELEMENT03
>>>>>> ELEMENT04 -- ELEMENT04
>>>>>> ELEMENT05 -- ELEMENT05
>>>>>> ELEMENT06 -- ELEMENT06
>>>>>> ELEMENT07 -- ELEMENT07
>>>>>>
>>>>>> If I remove one element from the second EReference:
>>>>>>
>>>>>> ELEMENT01 -- ELEMENT01
>>>>>> ELEMENT02 -- ELEMENT02
>>>>>> ELEMENT03 -- .........
>>>>>> ELEMENT04 -- ELEMENT04
>>>>>> ELEMENT05 -- ELEMENT05
>>>>>> ELEMENT06 -- ELEMENT06
>>>>>> ELEMENT07 -- ELEMENT07
>>>>>>
>>>>>> The comparison will result in (its an example, but happens most of
>>>>>> the
>>>>>> times):
>>>>>>
>>>>>> ELEMENT01 -- ELEMENT01 <match>
>>>>>> ELEMENT02 -- ELEMENT02 <match>
>>>>>> ELEMENT03 -- ......... <deleted>
>>>>>> ELEMENT04 -- ELEMENT05 <modified>
>>>>>> ELEMENT05 -- ELEMENT06 <modified>
>>>>>> ELEMENT06 -- ELEMENT04 <modified>
>>>>>> ELEMENT07 -- ELEMENT07 <match>
>>>>>>
>>>>>> This is just an example situation, but as you can see, the engine
>>>>>> tries
>>>>>> to match elements in the same position, and gets a high similarity
>>>>>> score
>>>>>> (since these elements are very similar, even in the name).
>>>>>>
>>>>>> In my opinion, the engine should take a look in the neighborhood to
>>>>>> search for a perfect match. In case there is no perfect match,
>>>>>> then it
>>>>>> could match those with the highest similarity score.
>>>>>>
>>>>>> Cheers!
>>>>>>
>>>>>> Víctor.
>>>>>
>>>>
>>
--------------000100020104050708010102
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"
YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyLyI+T2JlbzwvYT4NCmVtYWls O2ludGVybmV0
OmxhdXJlbnQuZ291YmV0QG9iZW8uZnINCnVybDpodHRwOi8vd3d3Lm9iZW8u ZnINCnZlcnNp
b246Mi4xDQplbmQ6dmNhcmQNCg0K
--------------000100020104050708010102--
|
|
| |
| Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #619096 is a reply to message #123712] |
Fri, 30 May 2008 08:06 |
Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi Víctor,
thanks for your feedback, you're not bothering us *at all* and the issues
you may encounter are likely to be encountered by other users not taking
the time to ask on the newsgroup, then thanks again :)
Cédric
Víctor Roldán Betancort wrote:
> Sorry to bother again about EMF Compare. I hope to help while reporting
> my findings.
>
> Try to imagine a multivalued referenced with lots of referenced
> children. These elements are simple named elements. Take a look at the
> following example (I'll put just 2 lists of names of these elements):
>
> ELEMENT01 -- ELEMENT01
> ELEMENT02 -- ELEMENT02
> ELEMENT03 -- ELEMENT03
> ELEMENT04 -- ELEMENT04
> ELEMENT05 -- ELEMENT05
> ELEMENT06 -- ELEMENT06
> ELEMENT07 -- ELEMENT07
>
> If I remove one element from the second EReference:
>
> ELEMENT01 -- ELEMENT01
> ELEMENT02 -- ELEMENT02
> ELEMENT03 -- .........
> ELEMENT04 -- ELEMENT04
> ELEMENT05 -- ELEMENT05
> ELEMENT06 -- ELEMENT06
> ELEMENT07 -- ELEMENT07
>
> The comparison will result in (its an example, but happens most of the
> times):
>
> ELEMENT01 -- ELEMENT01 <match>
> ELEMENT02 -- ELEMENT02 <match>
> ELEMENT03 -- ......... <deleted>
> ELEMENT04 -- ELEMENT05 <modified>
> ELEMENT05 -- ELEMENT06 <modified>
> ELEMENT06 -- ELEMENT04 <modified>
> ELEMENT07 -- ELEMENT07 <match>
>
> This is just an example situation, but as you can see, the engine tries
> to match elements in the same position, and gets a high similarity score
> (since these elements are very similar, even in the name).
>
> In my opinion, the engine should take a look in the neighborhood to
> search for a perfect match. In case there is no perfect match, then it
> could match those with the highest similarity score.
>
> Cheers!
>
> Víctor.
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
| Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #619136 is a reply to message #124053] |
Mon, 02 June 2008 09:39 |
|
This is a multi-part message in MIME format.
--------------070408040506040808080108
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Hi Víctor,
I took some time to tests this and couldn't reproduce your behavior with
the latest version of EMF Compare (0.8RC2 as I write this). My test case
was a simple ecore model with classes named ELEMENTx as you outlined in
your example, then deleting class ELEMENT3 was detected accurately by
EMF Compare. The same occured with EEnumLiterals named LITERALxx ... The
elements' name was the only thing I modified for this test.
Which version of Eclipse/EMF Compare are you using to reproduce this
bug? And can you provide us with the models you were comparing if they
do not contain any confidential information (preferred form is of course
a bug on Eclipse bugzilla ;)).
Laurent Goubet
Obeo
Cédric Brun a écrit :
> Hi Víctor,
>
> thanks for your feedback, you're not bothering us *at all* and the issues
> you may encounter are likely to be encountered by other users not taking
> the time to ask on the newsgroup, then thanks again :)
>
> Cédric
>
> Víctor Roldán Betancort wrote:
>
>> Sorry to bother again about EMF Compare. I hope to help while reporting
>> my findings.
>>
>> Try to imagine a multivalued referenced with lots of referenced
>> children. These elements are simple named elements. Take a look at the
>> following example (I'll put just 2 lists of names of these elements):
>>
>> ELEMENT01 -- ELEMENT01
>> ELEMENT02 -- ELEMENT02
>> ELEMENT03 -- ELEMENT03
>> ELEMENT04 -- ELEMENT04
>> ELEMENT05 -- ELEMENT05
>> ELEMENT06 -- ELEMENT06
>> ELEMENT07 -- ELEMENT07
>>
>> If I remove one element from the second EReference:
>>
>> ELEMENT01 -- ELEMENT01
>> ELEMENT02 -- ELEMENT02
>> ELEMENT03 -- .........
>> ELEMENT04 -- ELEMENT04
>> ELEMENT05 -- ELEMENT05
>> ELEMENT06 -- ELEMENT06
>> ELEMENT07 -- ELEMENT07
>>
>> The comparison will result in (its an example, but happens most of the
>> times):
>>
>> ELEMENT01 -- ELEMENT01 <match>
>> ELEMENT02 -- ELEMENT02 <match>
>> ELEMENT03 -- ......... <deleted>
>> ELEMENT04 -- ELEMENT05 <modified>
>> ELEMENT05 -- ELEMENT06 <modified>
>> ELEMENT06 -- ELEMENT04 <modified>
>> ELEMENT07 -- ELEMENT07 <match>
>>
>> This is just an example situation, but as you can see, the engine tries
>> to match elements in the same position, and gets a high similarity score
>> (since these elements are very similar, even in the name).
>>
>> In my opinion, the engine should take a look in the neighborhood to
>> search for a perfect match. In case there is no perfect match, then it
>> could match those with the highest similarity score.
>>
>> Cheers!
>>
>> Víctor.
>
--------------070408040506040808080108
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"
YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyLyI+T2JlbzwvYT4NCmVtYWls O2ludGVybmV0
OmxhdXJlbnQuZ291YmV0QG9iZW8uZnINCnVybDpodHRwOi8vd3d3Lm9iZW8u ZnINCnZlcnNp
b246Mi4xDQplbmQ6dmNhcmQNCg0K
--------------070408040506040808080108--
|
|
|
| Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #619141 is a reply to message #124800] |
Mon, 02 June 2008 11:15 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Laurent,
I think I must have correct one premise I posted in first instance:
these model elements aren't just plain elements, I mean, these element
weren't just classes with attributes, but rather classes with a mix of
attribs and references to other elements. Furthermore, another
characteristic I see is that these elements are part of a particular
hierarchy of EClasses. Using the original example, this would mean that
"ELEMENTx" is inherits from a somehow complex inheritance tree (lets
say, for instance, something like ELEMENTBASE -> ELEMENTABSTRACT -> ...
-> ELEMENT).
I'm using bleeding-edge stuff (All RC2 that's available). Using EMF
Compare 0.8RC2.
Unfortunately, as you say, the models I'm working on have confidential
information. I'll elaborate an "open source" clone of these
"confidential models" so I can provide it to you as test case ;) ;)
Regards,
Víctor.
laurent Goubet escribió:
> Hi Víctor,
>
> I took some time to tests this and couldn't reproduce your behavior with
> the latest version of EMF Compare (0.8RC2 as I write this). My test case
> was a simple ecore model with classes named ELEMENTx as you outlined in
> your example, then deleting class ELEMENT3 was detected accurately by
> EMF Compare. The same occured with EEnumLiterals named LITERALxx ... The
> elements' name was the only thing I modified for this test.
>
> Which version of Eclipse/EMF Compare are you using to reproduce this
> bug? And can you provide us with the models you were comparing if they
> do not contain any confidential information (preferred form is of course
> a bug on Eclipse bugzilla ;)).
>
> Laurent Goubet
> Obeo
>
> Cédric Brun a écrit :
>> Hi Víctor,
>>
>> thanks for your feedback, you're not bothering us *at all* and the issues
>> you may encounter are likely to be encountered by other users not taking
>> the time to ask on the newsgroup, then thanks again :)
>>
>> Cédric
>>
>> Víctor Roldán Betancort wrote:
>>
>>> Sorry to bother again about EMF Compare. I hope to help while reporting
>>> my findings.
>>>
>>> Try to imagine a multivalued referenced with lots of referenced
>>> children. These elements are simple named elements. Take a look at the
>>> following example (I'll put just 2 lists of names of these elements):
>>>
>>> ELEMENT01 -- ELEMENT01
>>> ELEMENT02 -- ELEMENT02
>>> ELEMENT03 -- ELEMENT03
>>> ELEMENT04 -- ELEMENT04
>>> ELEMENT05 -- ELEMENT05
>>> ELEMENT06 -- ELEMENT06
>>> ELEMENT07 -- ELEMENT07
>>>
>>> If I remove one element from the second EReference:
>>>
>>> ELEMENT01 -- ELEMENT01
>>> ELEMENT02 -- ELEMENT02
>>> ELEMENT03 -- .........
>>> ELEMENT04 -- ELEMENT04
>>> ELEMENT05 -- ELEMENT05
>>> ELEMENT06 -- ELEMENT06
>>> ELEMENT07 -- ELEMENT07
>>>
>>> The comparison will result in (its an example, but happens most of the
>>> times):
>>>
>>> ELEMENT01 -- ELEMENT01 <match>
>>> ELEMENT02 -- ELEMENT02 <match>
>>> ELEMENT03 -- ......... <deleted>
>>> ELEMENT04 -- ELEMENT05 <modified>
>>> ELEMENT05 -- ELEMENT06 <modified>
>>> ELEMENT06 -- ELEMENT04 <modified>
>>> ELEMENT07 -- ELEMENT07 <match>
>>>
>>> This is just an example situation, but as you can see, the engine tries
>>> to match elements in the same position, and gets a high similarity score
>>> (since these elements are very similar, even in the name).
>>>
>>> In my opinion, the engine should take a look in the neighborhood to
>>> search for a perfect match. In case there is no perfect match, then it
>>> could match those with the highest similarity score.
>>>
>>> Cheers!
>>>
>>> Víctor.
>>
>
|
|
|
| Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #619143 is a reply to message #124859] |
Mon, 02 June 2008 11:39 |
|
This is a multi-part message in MIME format.
--------------000109080502080507080501
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Thanks, will be waiting to try and fix these ;)
Laurent Goubet
Obeo
Víctor Roldán Betancort a écrit :
> Laurent,
>
> I think I must have correct one premise I posted in first instance:
> these model elements aren't just plain elements, I mean, these element
> weren't just classes with attributes, but rather classes with a mix of
> attribs and references to other elements. Furthermore, another
> characteristic I see is that these elements are part of a particular
> hierarchy of EClasses. Using the original example, this would mean that
> "ELEMENTx" is inherits from a somehow complex inheritance tree (lets
> say, for instance, something like ELEMENTBASE -> ELEMENTABSTRACT -> ...
> -> ELEMENT).
>
> I'm using bleeding-edge stuff (All RC2 that's available). Using EMF
> Compare 0.8RC2.
>
> Unfortunately, as you say, the models I'm working on have confidential
> information. I'll elaborate an "open source" clone of these
> "confidential models" so I can provide it to you as test case ;) ;)
>
> Regards,
> Víctor.
>
> laurent Goubet escribió:
>> Hi Víctor,
>>
>> I took some time to tests this and couldn't reproduce your behavior
>> with the latest version of EMF Compare (0.8RC2 as I write this). My
>> test case was a simple ecore model with classes named ELEMENTx as you
>> outlined in your example, then deleting class ELEMENT3 was detected
>> accurately by EMF Compare. The same occured with EEnumLiterals named
>> LITERALxx ... The elements' name was the only thing I modified for
>> this test.
>>
>> Which version of Eclipse/EMF Compare are you using to reproduce this
>> bug? And can you provide us with the models you were comparing if they
>> do not contain any confidential information (preferred form is of
>> course a bug on Eclipse bugzilla ;)).
>>
>> Laurent Goubet
>> Obeo
>>
>> Cédric Brun a écrit :
>>> Hi Víctor,
>>>
>>> thanks for your feedback, you're not bothering us *at all* and the
>>> issues
>>> you may encounter are likely to be encountered by other users not taking
>>> the time to ask on the newsgroup, then thanks again :)
>>>
>>> Cédric
>>>
>>> Víctor Roldán Betancort wrote:
>>>
>>>> Sorry to bother again about EMF Compare. I hope to help while reporting
>>>> my findings.
>>>>
>>>> Try to imagine a multivalued referenced with lots of referenced
>>>> children. These elements are simple named elements. Take a look at the
>>>> following example (I'll put just 2 lists of names of these elements):
>>>>
>>>> ELEMENT01 -- ELEMENT01
>>>> ELEMENT02 -- ELEMENT02
>>>> ELEMENT03 -- ELEMENT03
>>>> ELEMENT04 -- ELEMENT04
>>>> ELEMENT05 -- ELEMENT05
>>>> ELEMENT06 -- ELEMENT06
>>>> ELEMENT07 -- ELEMENT07
>>>>
>>>> If I remove one element from the second EReference:
>>>>
>>>> ELEMENT01 -- ELEMENT01
>>>> ELEMENT02 -- ELEMENT02
>>>> ELEMENT03 -- .........
>>>> ELEMENT04 -- ELEMENT04
>>>> ELEMENT05 -- ELEMENT05
>>>> ELEMENT06 -- ELEMENT06
>>>> ELEMENT07 -- ELEMENT07
>>>>
>>>> The comparison will result in (its an example, but happens most of the
>>>> times):
>>>>
>>>> ELEMENT01 -- ELEMENT01 <match>
>>>> ELEMENT02 -- ELEMENT02 <match>
>>>> ELEMENT03 -- ......... <deleted>
>>>> ELEMENT04 -- ELEMENT05 <modified>
>>>> ELEMENT05 -- ELEMENT06 <modified>
>>>> ELEMENT06 -- ELEMENT04 <modified>
>>>> ELEMENT07 -- ELEMENT07 <match>
>>>>
>>>> This is just an example situation, but as you can see, the engine tries
>>>> to match elements in the same position, and gets a high similarity
>>>> score
>>>> (since these elements are very similar, even in the name).
>>>>
>>>> In my opinion, the engine should take a look in the neighborhood to
>>>> search for a perfect match. In case there is no perfect match, then it
>>>> could match those with the highest similarity score.
>>>>
>>>> Cheers!
>>>>
>>>> Víctor.
>>>
>>
--------------000109080502080507080501
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"
YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyLyI+T2JlbzwvYT4NCmVtYWls O2ludGVybmV0
OmxhdXJlbnQuZ291YmV0QG9iZW8uZnINCnVybDpodHRwOi8vd3d3Lm9iZW8u ZnINCnZlcnNp
b246Mi4xDQplbmQ6dmNhcmQNCg0K
--------------000109080502080507080501--
|
|
|
| Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #619146 is a reply to message #124884] |
Mon, 02 June 2008 12:48 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Ok, got to reproduce it in a test metamodel. Should I open a bugzilla
and attach the files , or...?
laurent Goubet escribió:
> Thanks, will be waiting to try and fix these ;)
>
> Laurent Goubet
> Obeo
>
> Víctor Roldán Betancort a écrit :
>> Laurent,
>>
>> I think I must have correct one premise I posted in first instance:
>> these model elements aren't just plain elements, I mean, these element
>> weren't just classes with attributes, but rather classes with a mix of
>> attribs and references to other elements. Furthermore, another
>> characteristic I see is that these elements are part of a particular
>> hierarchy of EClasses. Using the original example, this would mean
>> that "ELEMENTx" is inherits from a somehow complex inheritance tree
>> (lets say, for instance, something like ELEMENTBASE -> ELEMENTABSTRACT
>> -> ... -> ELEMENT).
>>
>> I'm using bleeding-edge stuff (All RC2 that's available). Using EMF
>> Compare 0.8RC2.
>>
>> Unfortunately, as you say, the models I'm working on have confidential
>> information. I'll elaborate an "open source" clone of these
>> "confidential models" so I can provide it to you as test case ;) ;)
>>
>> Regards,
>> Víctor.
>>
>> laurent Goubet escribió:
>>> Hi Víctor,
>>>
>>> I took some time to tests this and couldn't reproduce your behavior
>>> with the latest version of EMF Compare (0.8RC2 as I write this). My
>>> test case was a simple ecore model with classes named ELEMENTx as you
>>> outlined in your example, then deleting class ELEMENT3 was detected
>>> accurately by EMF Compare. The same occured with EEnumLiterals named
>>> LITERALxx ... The elements' name was the only thing I modified for
>>> this test.
>>>
>>> Which version of Eclipse/EMF Compare are you using to reproduce this
>>> bug? And can you provide us with the models you were comparing if
>>> they do not contain any confidential information (preferred form is
>>> of course a bug on Eclipse bugzilla ;)).
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Cédric Brun a écrit :
>>>> Hi Víctor,
>>>>
>>>> thanks for your feedback, you're not bothering us *at all* and the
>>>> issues
>>>> you may encounter are likely to be encountered by other users not
>>>> taking
>>>> the time to ask on the newsgroup, then thanks again :)
>>>>
>>>> Cédric
>>>>
>>>> Víctor Roldán Betancort wrote:
>>>>
>>>>> Sorry to bother again about EMF Compare. I hope to help while
>>>>> reporting
>>>>> my findings.
>>>>>
>>>>> Try to imagine a multivalued referenced with lots of referenced
>>>>> children. These elements are simple named elements. Take a look at the
>>>>> following example (I'll put just 2 lists of names of these elements):
>>>>>
>>>>> ELEMENT01 -- ELEMENT01
>>>>> ELEMENT02 -- ELEMENT02
>>>>> ELEMENT03 -- ELEMENT03
>>>>> ELEMENT04 -- ELEMENT04
>>>>> ELEMENT05 -- ELEMENT05
>>>>> ELEMENT06 -- ELEMENT06
>>>>> ELEMENT07 -- ELEMENT07
>>>>>
>>>>> If I remove one element from the second EReference:
>>>>>
>>>>> ELEMENT01 -- ELEMENT01
>>>>> ELEMENT02 -- ELEMENT02
>>>>> ELEMENT03 -- .........
>>>>> ELEMENT04 -- ELEMENT04
>>>>> ELEMENT05 -- ELEMENT05
>>>>> ELEMENT06 -- ELEMENT06
>>>>> ELEMENT07 -- ELEMENT07
>>>>>
>>>>> The comparison will result in (its an example, but happens most of the
>>>>> times):
>>>>>
>>>>> ELEMENT01 -- ELEMENT01 <match>
>>>>> ELEMENT02 -- ELEMENT02 <match>
>>>>> ELEMENT03 -- ......... <deleted>
>>>>> ELEMENT04 -- ELEMENT05 <modified>
>>>>> ELEMENT05 -- ELEMENT06 <modified>
>>>>> ELEMENT06 -- ELEMENT04 <modified>
>>>>> ELEMENT07 -- ELEMENT07 <match>
>>>>>
>>>>> This is just an example situation, but as you can see, the engine
>>>>> tries
>>>>> to match elements in the same position, and gets a high similarity
>>>>> score
>>>>> (since these elements are very similar, even in the name).
>>>>>
>>>>> In my opinion, the engine should take a look in the neighborhood to
>>>>> search for a perfect match. In case there is no perfect match, then it
>>>>> could match those with the highest similarity score.
>>>>>
>>>>> Cheers!
>>>>>
>>>>> Víctor.
>>>>
>>>
>
|
|
|
| Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #619147 is a reply to message #124924] |
Mon, 02 June 2008 12:50 |
|
This is a multi-part message in MIME format.
--------------000100020104050708010102
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Yes, bugzilla will be easier to track evolutions of this.
Thanks!
Laurent Goubet
Obeo
Víctor Roldán Betancort a écrit :
> Ok, got to reproduce it in a test metamodel. Should I open a bugzilla
> and attach the files , or...?
>
> laurent Goubet escribió:
>> Thanks, will be waiting to try and fix these ;)
>>
>> Laurent Goubet
>> Obeo
>>
>> Víctor Roldán Betancort a écrit :
>>> Laurent,
>>>
>>> I think I must have correct one premise I posted in first instance:
>>> these model elements aren't just plain elements, I mean, these
>>> element weren't just classes with attributes, but rather classes with
>>> a mix of attribs and references to other elements. Furthermore,
>>> another characteristic I see is that these elements are part of a
>>> particular hierarchy of EClasses. Using the original example, this
>>> would mean that "ELEMENTx" is inherits from a somehow complex
>>> inheritance tree (lets say, for instance, something like ELEMENTBASE
>>> -> ELEMENTABSTRACT -> ... -> ELEMENT).
>>>
>>> I'm using bleeding-edge stuff (All RC2 that's available). Using EMF
>>> Compare 0.8RC2.
>>>
>>> Unfortunately, as you say, the models I'm working on have
>>> confidential information. I'll elaborate an "open source" clone of
>>> these "confidential models" so I can provide it to you as test case
>>> ;) ;)
>>>
>>> Regards,
>>> Víctor.
>>>
>>> laurent Goubet escribió:
>>>> Hi Víctor,
>>>>
>>>> I took some time to tests this and couldn't reproduce your behavior
>>>> with the latest version of EMF Compare (0.8RC2 as I write this). My
>>>> test case was a simple ecore model with classes named ELEMENTx as
>>>> you outlined in your example, then deleting class ELEMENT3 was
>>>> detected accurately by EMF Compare. The same occured with
>>>> EEnumLiterals named LITERALxx ... The elements' name was the only
>>>> thing I modified for this test.
>>>>
>>>> Which version of Eclipse/EMF Compare are you using to reproduce this
>>>> bug? And can you provide us with the models you were comparing if
>>>> they do not contain any confidential information (preferred form is
>>>> of course a bug on Eclipse bugzilla ;)).
>>>>
>>>> Laurent Goubet
>>>> Obeo
>>>>
>>>> Cédric Brun a écrit :
>>>>> Hi Víctor,
>>>>>
>>>>> thanks for your feedback, you're not bothering us *at all* and the
>>>>> issues
>>>>> you may encounter are likely to be encountered by other users not
>>>>> taking
>>>>> the time to ask on the newsgroup, then thanks again :)
>>>>>
>>>>> Cédric
>>>>>
>>>>> Víctor Roldán Betancort wrote:
>>>>>
>>>>>> Sorry to bother again about EMF Compare. I hope to help while
>>>>>> reporting
>>>>>> my findings.
>>>>>>
>>>>>> Try to imagine a multivalued referenced with lots of referenced
>>>>>> children. These elements are simple named elements. Take a look at
>>>>>> the
>>>>>> following example (I'll put just 2 lists of names of these elements):
>>>>>>
>>>>>> ELEMENT01 -- ELEMENT01
>>>>>> ELEMENT02 -- ELEMENT02
>>>>>> ELEMENT03 -- ELEMENT03
>>>>>> ELEMENT04 -- ELEMENT04
>>>>>> ELEMENT05 -- ELEMENT05
>>>>>> ELEMENT06 -- ELEMENT06
>>>>>> ELEMENT07 -- ELEMENT07
>>>>>>
>>>>>> If I remove one element from the second EReference:
>>>>>>
>>>>>> ELEMENT01 -- ELEMENT01
>>>>>> ELEMENT02 -- ELEMENT02
>>>>>> ELEMENT03 -- .........
>>>>>> ELEMENT04 -- ELEMENT04
>>>>>> ELEMENT05 -- ELEMENT05
>>>>>> ELEMENT06 -- ELEMENT06
>>>>>> ELEMENT07 -- ELEMENT07
>>>>>>
>>>>>> The comparison will result in (its an example, but happens most of
>>>>>> the
>>>>>> times):
>>>>>>
>>>>>> ELEMENT01 -- ELEMENT01 <match>
>>>>>> ELEMENT02 -- ELEMENT02 <match>
>>>>>> ELEMENT03 -- ......... <deleted>
>>>>>> ELEMENT04 -- ELEMENT05 <modified>
>>>>>> ELEMENT05 -- ELEMENT06 <modified>
>>>>>> ELEMENT06 -- ELEMENT04 <modified>
>>>>>> ELEMENT07 -- ELEMENT07 <match>
>>>>>>
>>>>>> This is just an example situation, but as you can see, the engine
>>>>>> tries
>>>>>> to match elements in the same position, and gets a high similarity
>>>>>> score
>>>>>> (since these elements are very similar, even in the name).
>>>>>>
>>>>>> In my opinion, the engine should take a look in the neighborhood to
>>>>>> search for a perfect match. In case there is no perfect match,
>>>>>> then it
>>>>>> could match those with the highest similarity score.
>>>>>>
>>>>>> Cheers!
>>>>>>
>>>>>> Víctor.
>>>>>
>>>>
>>
--------------000100020104050708010102
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"
YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyLyI+T2JlbzwvYT4NCmVtYWls O2ludGVybmV0
OmxhdXJlbnQuZ291YmV0QG9iZW8uZnINCnVybDpodHRwOi8vd3d3Lm9iZW8u ZnINCnZlcnNp
b246Mi4xDQplbmQ6dmNhcmQNCg0K
--------------000100020104050708010102--
|
|
|
Goto Forum:
Current Time: Tue Apr 16 03:50:19 GMT 2024
Powered by FUDForum. Page generated in 0.60013 seconds |
] 
Search
Help
Register
Login
Home
