Canonical2XPDL issue

[GoogleCodeExporter]

I suspect the adapter Canonical2XPDL not to work properly:

1- I created test-blue.xpdl a simple model in xpdl, one task colored in blue
2- I edited this model, annotation only: chose Initial, colored the task in 
green, then save it as Green (the annotation which is reloaded has no layout, 
no color)

This results in two annotations associated with test-blue.xpdl

To reproduce what happened at step 2, I exported test-blue canonical in 
test-blue.cpf and each annotations respectively in test-blue-initial.anf and 
test-blue-green.anf. Then I applied the adapter Canonical2XPDL on test-blue.cpf 
and test-blue-green.anf. This produced a model with no layout, no color.

Looks like there is something wrong with the cpfId....

Original issue reported on code.google.com by macri.fa...@gmail.com on 13 Nov 2010 at 2:31

[GoogleCodeExporter]

Abdul, can you please check this issue?

Original comment by marcello...@gmail.com on 14 Nov 2010 at 11:03

[GoogleCodeExporter]

The CPF ids in the green annotation file are totally different. It seems that 
they are generated for another CPF file because they have correct id values but 
non of them are exist in the CPF file. So, they might be for another CPF file.

Original comment by aah.shareef@gmail.com on 15 Nov 2010 at 11:43

[GoogleCodeExporter]

I think there is something wrong with the management of CPF Ids. Please try the 
scenario I described in my previous comment, and check that. 

BTW, there are many CPF Ids in a ANF description, why is it so? why not exactly 
one?

Original comment by macri.fa...@gmail.com on 15 Nov 2010 at 11:58

[GoogleCodeExporter]

There are many CPF ids, because each ANF element refers to a specific CPF 
element, which is identified by its id.

Original comment by marcello...@gmail.com on 16 Nov 2010 at 3:21

[GoogleCodeExporter]

I talked to Mehrad and maybe we have understood where the problem is. When 
editing an annotation, the model created in Oryx, is exported say in XPDL. Then 
this is converted into CPF + ANF. However, this CPF must have the same ids of 
the original CPF that was used to create/edit the annotation. So Marie, you 
need to make sure that when the CPF is produced from the XPDL file provided by 
Oryx, this CPF doesn't take the current timestamp to generate ids, but rather 
the timestamp used in the original CPF. In this way the ids of the newly 
created ANF file will match those of the original CPF.

Original comment by marcello...@gmail.com on 16 Nov 2010 at 8:04

[GoogleCodeExporter]

The Ids you are talking about are those generated by the adapter 
XPDL2Canonical. The id I generate are processID (CPF URI) only.
Abdul, could you check how you generate the cpdIds?

Original comment by macri.fa...@gmail.com on 16 Nov 2010 at 8:15

[GoogleCodeExporter]

That's what i expected the new annotation file is linked with the new another 
generated CPF file. When importing an xpdl file, the adapter gives the CPF file 
new id values based on the current time no matter if the modification was on 
the annotation or the model itself because the adapter doesn't actually 
distinguish.

Original comment by aah.shareef@gmail.com on 16 Nov 2010 at 8:37

[GoogleCodeExporter]

We agreed this problem be fixed by changing the Decanonization methods 
(XPDLtoCanonical and EPMLtoCanonical) in the Adapter to take an existing 
timestamp (long value) rather than creating a new one. This timestamp 
corresponds to the URI to be used in the CPF that will be generated. In this 
way, if an existing URI is used, the generated CPF will be the same as the one 
stored in Apromore. Thus, the annotations in the ANF file will refer to the 
proper CPF elements.

Original comment by marcello...@gmail.com on 17 Nov 2010 at 9:56

[GoogleCodeExporter]

For the classes: XPDL2Canonical and EPML2Canonical, new constructors have been 
added to receive one more argument which will be used as a start for CPF ids 
generation.

Original comment by aah.shareef@gmail.com on 18 Nov 2010 at 12:41