ANF and CPF xschemas

[GoogleCodeExporter]

We need to agree on datatypes used in anf and cpf xml descriptions.

- For temporal values: couldn't we stick to string values instead of DateTime 
which are then mapped by JAXB into XMLGregorianCalendar which is not nicely 
mapped in Java

- What is the meaning of the attribute "version" in anf xschema?

- At the moment,as it is in xpdl, Apromore considers "version ids" as strings, 
not as decimals as it is in anf and cpf xschemas.

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

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

- For temporal values: couldn't we stick to string values instead of DateTime 
which are then mapped by JAXB into XMLGregorianCalendar which is not nicely 
mapped in Java

The advantage of using DateTime is that Java provides functions to compare 
dates, which can be useful.

- What is the meaning of the attribute "version" in anf xschema?

The attribute "version" in the ANF schema is like the version for CPF. This 
value should be unique throughout the repository to identify an ANF file. In 
theory, we could have two ANF files named "Green" with different version 
numbers. The type of this version should be the same as the one of a CPF file.

- At the moment,as it is in xpdl, Apromore considers "version ids" as strings, 
not as decimals as it is in anf and cpf xschemas.

It is fine if we internally treat versions as strings, so long as they remain 
decimals in the ANF and CPF schemas. BTW: I think you mean integers, not 
decimals?

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

[GoogleCodeExporter]

- About version Ids:

The attribute "version" which identifies a process version when the process 
name is fixed cannot be integer, otherwise values such as 0.21 are invalid. If 
we want to allow values such as 0.21 as well as 01.21, this attribute should be 
of type string.

- About temporal values (datetime vs. string): 

It's true that it would be useful to use temporal functions in Java. However, 
at the moment this is not the case. Issue 50 
(http://code.google.com/p/apromore/issues/detail?id=50) is related to this one.
I propose to use string until ICSOC demo is done.

- About versioning

Apromore does not support ANF versioning. 
I think that " This value should be unique throughout the repository to 
identify an ANF file." is not correct, unless a processId is fixed.

Original comment by macri.fa...@gmail.com on 15 Nov 2010 at 12:22

[GoogleCodeExporter]

- About version Ids:

I don't remember we have decimals but I might be wrong. I remember we take the 
current date/time and convert it to an integer.

- About temporal values

fine

- About versioning

In all honesty I don't remember it. Can you please check the UML diagram? I 
thought each ANF would have a version no. to uniquely identify it.

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

[GoogleCodeExporter]

About version Ids:

- we take the current date/time to generate canonical URIs. Actually, the cpf 
URI is: processId.toString() + version.replaceAll("\\.", "") + time

- version names are defined as decimals in cpf_0.5.xsd

About versioning: each ANF is uniquely identified byt its URI. There is no 
attribute version associated with it.

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

[GoogleCodeExporter]

As we agreed on the discussion, Apromore uses anf and cpf new facades 
respectively defined in anf_0.2m.xsd and cpf_05m.xsd. See attached files. 

Original comment by macri.fa...@gmail.com on 20 Nov 2010 at 10:42

• Changed state: Started

Attachments:

• anf_0.2m.xsd
• cpf_0.5m.xsd

[GoogleCodeExporter]

Marie, Adbul, please use the attached files. I realized the version no. of each 
document where not updated.

Original comment by marcello...@gmail.com on 22 Nov 2010 at 1:30

Attachments:

• anf_0.2.xsd
• cpf_0.5.xsd