ITuple with complex structure

This is a work in progress area for ITuple with complex structure. This document
collects the main concepts behind this issue and it is
meant to incorporate the comments,suggestions and resolutions that
emerge from the on-going parallel
e-mail forum discussion.
By complex structure we mean the possibility of supporting a folder-like
data arrangement inside an ITuple. As in AIDA we already have the concept of Folders within ITree
we will try not to use the word "folder" to avoid confusion.

An improvement is the current ITuple design is needed
to allow the user to store data with an internal
structure (i.e. event->tracks->hits kind of cascade).
This can be obtained with minimal changes to the current schema.

The user's prospective

The main concept is that additional structure is achieved by allowing an ITuple to
store another ITuple.
An example of what an user should do to create and fill an ITuple with additional
internal structure follows:

To access the data stored in the ITuple the user will have to do:

Changes to ITuple

The only change required to the ITuple interface is to add the method:

ITuple getTuple( int index );

that returns the ITuple at the column's position index.

Changes to the DTD for XML input/output

A change is also needed to the aida.dtd to allow for XML
saving and restoring of the internal structure for an ITuple.
As the columns, their names and their types are specified in the
top level ITuple, all is needed is to save the data stored in
the internal ITuple.

To distinguish an ordinary "entry" in a "row" from the one
corresponding to the internal ITuple we need a new element
"entryITuple" and to modify the "row" element to account for
its presence.

The XML output for the example above will look like:

Implementation notes

The internal structure we discussed above can be achieved by creating
the desired ITules when needed and store them as Objects in the current
ITuple schema. This implementation would not require any changes to
the current ITuple. Nevertheless we think that this kind of implementation
is inefficient and goes against the current AIDA standards.

To create a new set of ITuples inside the main loop, the user will
have to access the ITupleFactory. This will automatically put the newly
created ITuple in the ITree in which the top-level ITuple is living.
This is probably inappropriate as the internal ITuples should not
be part of the ITree.

Moreover when creating ITuples we allocate memory that might be left
unused. A trim() method would be required at the expence of speed.

The above example on how to create and fill an ITuple will then
look like:

while the one on how to access the data is unchanged.

Rather that creating an ITuple each time, we create the needed ITuples
only once when the top level ITuple is created. We then append the data
when the corresponding addRow() method is called. This way the user does
not have to create an ITuple insed the event loop and we solve the
above efficiency problem. The two approaches are represented schematically
in the figure below.

The price to be paid is the need of the
new ITuple method mentioned above ( getTuple(index) ) that returns
the ITuple in a configuration ready to be filled ( the getObject() method
returns the SAME ITuple in a configuration corresponding to the "current"
position of the top-level ITuple ).
Another small price is that for each internal ITuple, we have to create
an additional column ("helper" in the figure below) in the the top-level
ITuple to keep track of where the data starts and ends for a given entry.

Please note that with this implementation the ITuple automatically supports
random access if we provide a setRow() method.

Column parsing

In this schema it is necessary to define the nested ITuples at the
top ITuple level. The examples in this document used the following conventions:

the type for a nested ITuple is ITuple

the default value for each column is provided after the column's
name being separated from it by an equal sign ( = )

the string defining a nested ITuple structure is regarded
as a default value ad it is delimited by curly brackets.

if a column has the same type of the previous column, its
type can be omitted (this does not apply when the types are provided
in an array).

the options for a nested ITuple are provided as a string
between round brackets before the ITuple's name.

There are two ways to create an ITuple using the create() method of
an ITupleFactory:

The second create() method was used in the first example in this
document; the code below shows how to create the same ITuple
using the other ITupleFactory's create() method.