baifanvhai / apromore

Automatically exported from code.google.com/p/apromore
0 stars 0 forks source link

Assciation aren't aligned properly when exporting from EPML to XPDL #96

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The associations are not aligned when exporting EPML model to XPDL. They should 
be aligned with the XPDL elements as well as the transition.

Original issue reported on code.google.com by aah.shareef@gmail.com on 30 Sep 2010 at 6:53

GoogleCodeExporter commented 9 years ago
This issue can't be solved currently due to the fact that the canonical format 
represents this relation as a reference to the object type. Thus, the 
annotation data for this relation  (between the object and the connected 
element) will be lost when canonizing the EPML file.

Original comment by aah.shareef@gmail.com on 3 Oct 2010 at 10:44

GoogleCodeExporter commented 9 years ago
This can be fixed by extending the annotation format to capture presentation 
properties of the relation Work node - Object. I propose you prepare a proposal 
for such an extension and we discuss this next time we meet. 

Original comment by marcello...@gmail.com on 3 Oct 2010 at 8:18

GoogleCodeExporter commented 9 years ago
Can we add an ID for the reference? If we do that, we can keep the annotation 
data that is linked to that id and use them when exporting to XPDL or even EPML.

Original comment by aah.shareef@gmail.com on 5 Oct 2010 at 3:55

GoogleCodeExporter commented 9 years ago
What do you mean by reference?

Original comment by marcello...@gmail.com on 5 Oct 2010 at 4:23

GoogleCodeExporter commented 9 years ago
the reference to Object Type or to Resource Type. It doesn't have an ID in the 
canonical facade. If we added an ID for it, then we would be able to store its 
annotation in the annotation file. The problem would be solved by that.

Original comment by aah.shareef@gmail.com on 5 Oct 2010 at 4:35

GoogleCodeExporter commented 9 years ago
All elements have an Id including objects and resoucetypes. Check the schema

Original comment by marcello...@gmail.com on 5 Oct 2010 at 4:49

GoogleCodeExporter commented 9 years ago
Yes, I know that. But the references to those objects or resources type don't 
have. For example:

<Node xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:type="ns2:TaskType" id="1285814466691">
            <name>F2</name>
            <objectRef objectId="1285814466694" type="input"/>
</Node>

<Object id="1285814466694">
        <name>O2</name>
</Object>

The objectRef referes to this Object, but itself doesn't have an ID. I would 
recommend to update the facade by giving it an ID to maintain the annotation 
data using that ID.

Original comment by aah.shareef@gmail.com on 5 Oct 2010 at 4:58

GoogleCodeExporter commented 9 years ago
Ok, we could automatically generate such an id by concatenating the id of the 
node with that of the object/resource. Or we simply generate a new one.

Original comment by marcello...@gmail.com on 5 Oct 2010 at 11:12

GoogleCodeExporter commented 9 years ago
Now, we add an attribute with name 'RefID' for each object reference in order 
to maintain the annotation data. The example shows how:

<objectRef objectId="1286339803660" type="input">
                <attribute typeRef="RefID" value="1286339803665"/>
 </objectRef>

The value will address the graphical data related to that reference in the 
annotation file.

Original comment by aah.shareef@gmail.com on 6 Oct 2010 at 4:57

GoogleCodeExporter commented 9 years ago
Rather, add an id like this

<objectRef id="1286339803665" objectId="1286339803660" type="input"/>

Original comment by marcello...@gmail.com on 6 Oct 2010 at 5:19

GoogleCodeExporter commented 9 years ago
That would require to change the CPF schema, then the facade. Unless you want 
me to change the Java CPF facade manually but then the facade wouldn't reflect 
the current CPF schema.

Original comment by aah.shareef@gmail.com on 6 Oct 2010 at 5:28

GoogleCodeExporter commented 9 years ago
Please change the schema and the facade. The latter can be changed manually

Original comment by marcello...@gmail.com on 6 Oct 2010 at 5:49

GoogleCodeExporter commented 9 years ago

Original comment by aah.shareef@gmail.com on 3 Nov 2010 at 9:14