Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jwt-dev] Re: AW: Source Forge

Thanks for your reply.

I would like to discuss data in AgilPro for a moment.
XPDL has XPDL:DataField. This is an atomic data object, as far as XPDL is
It has an XPDL:DataType, which describes its structure, which may be very,
very complex,
and contain a number of simple data ements as well as other nested data
However, XPDL:DataField is the smallest chunk of data that XPDL directly
manipulates.  XPDL maps an entire
XPDL:DataField data object to a single Application calling parameter.
Another way of thinking of this atomic data object would be a variable
I will henceforth just call this simply a data object.

I have experimented with Data in AgilPro, and have formulated a working
mental model,
which I would like to validate and clarify.

The AgilPro elements which corespond to XPDL's atomic data objects appear
to be the parameter elements of AgilPro:Data,
since these are the entitites that are mapped to an Application's calling
However, there is no way to directly specify the data type of an individual

It would then appear that an AgilPro:Data entity would essentially be a
collection of data objects (AgilPro:Data.parameters), all of the same type,
since the DataType and InformationType are specified in common in the
AgilPro:Data entity. However, the Value is also specified in common in the
AgilPro:Data entity, which makes no sense for this conceptualization.

Another problem with this mental  model is that these parameters can be
only one of an AgilPro:Data.Parameter  or an AgilPro:Data.InputParameter or
an AgilPro:Data.OutputParameter. If these parameters corespond to data
objects, or variables, it will often be the case that a variable that is an
output of the Application that performs one AgilPro:Action will be an input
to the Application that performs a subsequent AgilPro:Action, but I cannot
figure out how to model this in AgilPro.

I had originally thought that the AgilPro:Data element would corespond to
an individual data object, rather than a collection. However, if this was
the case, you would need to be able to map an AgilPro:Data element directly
to a specific calling parameter of an Application. If the parameters are
how you define the structure of the data object, you would need to be able
to specify different types for the parameters, and probably be able to
recursively nest them.

Could you please provide some guidance in this area?
When you correct the issue with not being able to use the simple types
AgilPro:string, and AgilPro:integer, will they behave like an AgilPro:Data
element or as one of the parameter type children of an AgilPro:Data

Thank you;

             <florian.lautenba                                          To 
             cher@informatik.u         <Steve.Egbert@xxxxxxxx>, "'Java     
   >           Workflow Toolbox'"                  
             04/18/2007 07:52                                           cc 
             AM                        <emmanuel.rias@xxxxxxxx>,           
                                       AW: Source Forge                    

Hi Steve,

thanks for the bug in the AgilPro tracker. We were already aware of that
and fixed it in the code for version 1.2.0. So, it will be removed in the
upcoming version.

Concerning your questions about the metamodel:

>>Difference between data type and information type:

The data type is thought for the description of the file format and the
of file, so for example it could be XML, Word 2007, but also URL or
eu.emundo.agilpro.fw.fe.dto.FileDTO which are used in the adapters of the
Simulation Desktop for simulating the processes. InformationType on the
other side are for describing what functional kind of resource should be
described: is it an order, an invoice, etc.

>>Parameter entries and Data mapping:

A data can contain several parts. These parts are called parameters, as
are also used for the invocation of applications as InputParameter or
execution) OutputParameter.
The DataMapping is responsible for the binding of data elements to
application parameters. An application might need three parameters and a
data might have three parts (parameters). How should the application know
which part of the data is the first parameter (second, third), if it is not
directly bound? It could be possible that the first part of the data is the
third parameter of the application and the other way round. That's why we
introduced the DataMapping concept which binds a parameter of the data to a
(boundParameter) of an application.

>>Under the Package node in the outline view, I can add strings and
as children. However, I cannot use them where data is expected, such as
selecting them in the Input Data dialog. What is the purpose of these
elements and how are they used?

You are right, that's probably a bug. We introduced the simple datatypes in
the metamodel but didn't need them till now. So it went unnoticed that they
were not selectable in the input data dialog. I'll add that one to the bug

Best regards,


Back to the top