1. TODL - Temporal Object Definition Language

2. Objectives
TODL should support all TODM constructs
TODL is not a full programming language, but rather a specification language
TODL should be programming language independent
TODL should be compatible with ODL
TODL should be extensible

3. Instance properties with temporal characteristics
Attributes
Introduction of new clauses to declare the temporal dimensions specified for the attributes
valid clause for valid time specification
transaction clause for transaction time specification
Relationships
As above plus an extension of the order_by clause

4. Temporal Attributes - examples
An attribute with valid time characteristics of period type with year granularity at the default calendar (Gregorian)
attribute TypeA attr_name valid granularity year
An attribute with overlapping valid time characteristics of period type, with seconds granularity at the default calendar.
attribute TypeB attr_name valid state
overlaps granularity second calendar gregorian
An attribute with transaction time characteristics.
attribute TypeC attr_name transaction
An attribute with valid time of instant type, with minutes granularity at the default calendar and transaction time.
attribute TypeD attr_name valid event
granularity minute transaction

5. Temporal relationships - examples
A historical relationship ordered by valid time
relationship Atype arelat valid state granularity day {order_by valid}

6. Operations
Operation’s result may have temporal dimensions
Operation’s arguments may have temporal dimensions
The operation may be applied to a state of a temporal object or to an object as a whole.

7. Temporal objects
Use the valid and transaction clauses as shortcuts for definition of temporal dimensions that are the same for all the attributes and relationships
Use the valid and transaction clauses to define objects which have states that change as a whole with time.
interface VisitStatement
transaction {
attribute Boolean asthmaControl;
attribute Boolean aggravationCriteria; }

8. Overlapping valid time (1)
Overlapping in the same object
Default no overlapping
Usage of the overlaps keyword to specify that there may be overlapping valid time timestamps in the same object
Overlapping valid time timestamps in the same object are used mainly for statistics reasons
Overlapping for objects in the same extent
Three kinds of overlapping
They are defined using special keywords in key definition
Inter-object period: Two objects may have the same value at one of their instance properties and overlapping valid time timestamps as long as the timestamps are not exactly the same. Keyword used: period

9. Overlapping valid time (2)
Overlapping for objects in the same extent
Inter-object point: Two objects may not have the same value and overlapping valid time timestamps for a historical property. Keyword: point
Extent-wide point:Two objects may not have the same value for a historical property at any time in the valid time axis. Keyword: object

10. Overlapping valid time (3)
Examples
Non-overlapping in the same object: An employee may have only one salary at any specified moment in time
Inter-object point: No two departments of the same corporation may have the same name at the same time
Extent-wide point: No two persons or corporations may have the same internal revenue record number at any time

11. User-defined time Unanchored quantity of time
Interval
May specify the granularity and the calendar
Example
attribute Interval granularity month month_interval
Anchored quantity of time
Instant and Period
Can define granularity, calendar
The attribute may contain only relative timestamps (declared through the relative keyword), only absolute timestamps (absolute keyword) or both (default behaviour)

12. State relationships
Relationships that point to certain “slices” of temporal objects.
Defined by prepending the state keyword at the relationship definition
State relationships do not have inverse relationships so the inverse statement is not used

13. Calendar definition
The programmer may define a new calendar. He has to define:
a name
the calendar’s origin
a set of granules
linear mapping among the granules
Extra work through TODM API
Define extra operations. The operations' signatures are provided by TODL generated files

14. How does it work?
What TODL does is that it accepts a file of TODL declarations and then produces:
A .hxx file containing O2 C++ Binding declarations of the defined classes
A .cc file containing generated code for constructors and destructors, as well as get and set methods using C++ and TODM API
A sample .cf file to use for the import phase
The user is expected to:
Implement any operations defined and/or special operations for user-defined calendars
Perform an o2import to import the defined classes to O2