Data

Data components are the types and structures that define how information is stored, validated and used in code. They give shape to raw data so it can be processed logically and consistently.

Data component types

A Rune data component may include up to four types of data. Think of these as the building blocks for your data structures:

1. Built-in type: The most fundamental types, like numbers and text.
2. Data type (complex type): Used to describe complex business concepts (e.g. like an Engine or VehicleOwnership).
3. Enumeration (Enum): A list of specific, controlled values in a container.

1. Built-in type

Built-in types are defined at the language level and are fundamental to any model – they provide the most basic way to represent information. They help to ensure consistency across all models and provide a shared vocabulary for numbers, text, time and logic. They form the foundation on which more complex types (like data types or choice types) are built.

Built-in data types come in three flavors:

1.1 Basic types

These are your standard, non-composite data types and are defined as basicType at the language level:

• int: Integer numbers
• number: Decimal numbers
• booleanBoolean Data type with only two values (yes/no, on/off etc).: True or false values
• string: Text values
• time: Simple time values (e.g. "05:00:00")

1.2 Parameterized basic types

You can customize the number and string types by adding constraints or specific formatting.

Example: Parameterized number

This defines a positive decimal number with a maximum value of 5000. Note that the simple int type is just a shorthand for a number with no fractional digits, such as number(fractionalDigits: 0).

    number(digits: 18,fractionalDigits: 17,min: 0, max: 5000)

Example: Parameterized string

This example limits the string to between 3 and 5 characters and ensures it's alphanumeric.

    string(
    minLength: 3,
    maxLength: 5,
    pattern: "[a-zA-Z0-9]*"
    )

Type aliases

You can give a name (an alias) to any parameterized type to keep your model readable and avoid long, verbose declarations. Instead of typing the complex string definition, you can just use AlphaNumericText.

    typeAlias PositiveInteger: number(
    fractionalDigits: 0,
    min: 0
    )
    1 typeAlias AlphaNumericText: string(
    minLength: 1,
    pattern: "[a-zA-Z0-9]{1,4}")

Type aliases PositiveInteger and AlphaNumericText are both used in this example.

type DrivingLicence extends Person:
<"Driving licence authorisation granted by a jurisdiction">
    countryofIssuance string (1..1) [metadata scheme]
    licenceNumber AlphaNumericText (1..1)
    dateofIssuance date (1..1)
    dateOfRenewal date (0..1)
    vehicleEntitlement VehicleClassificationEnum (0..*)
    penaltyPoints PositiveInteger (1..1)

1.3 Record types

These are simple composite built-in types, essentially grouping basic types together. Record types are straightforward; they’re pure data definitions and don't allow for custom validation logic. They're defined as recordType at the language level.

• date: Combines a day, month and year.
• dateTime: Combines a date and a simple time.
• zonedDateTime: Combines date, time, and a time-zone specification for an unambiguous moment in time.

¹

2. Data type (complex type)

Data types are how you define the core business concepts in your model (like an 'entity' or 'object'). They’re sometimes called complex types because they’re composed of multiple elements called attributes (or 'fields'). It describes a logical concept in your business domain and is defined by the collection of attributes that make up that concept.

• Name (required): Written in PascalCase (e.g. VehicleOwnership). Must be unique in its namespace.
• Description (optional, but recommended): A plain-text definition inside angle brackets <"...">.
• Annotations (optional): Metadata enclosed in square brackets [ ... ].

Syntax:

type <TypeName>: <"Description">
[
<annotation1>]
    [
    <annotation2>]
        [...]
        <attribute1>
            <attribute2>
                <
                ...>

Example:

type VehicleOwnership:
<"Representative record of vehicle ownership">
[metadata key]
[rootType]

2.1 Attributes

A data type is made up of attributes (its fields). Attributes are optional, so a data type can even be empty. When present, each attribute has five parts:

• Name (required): Written in camelCase (starts lowercase). Must be unique within the data type.
• Type (required): Defined using one of the available data component types.
• CardinalityCardinality The number of elements in a set or other grouping, as a property of that grouping. (required): Sets the minimum and maximum number of times the attribute can appear.
• Description (optional, recommended): Plain-text explanation of the attribute’s role.
• Annotations (optional): Extra metadata, such as synonyms or tags.

Note: Rune DSLRune DSL A Domain Specific Language for defining business rules, data structures, and calculations in financial and regulatory contexts. Used in Rosetta. doesn’t use special symbols to end definitions. Each new definition begins with a keyword like type, which automatically closes the previous one. This keeps code cleaner by avoiding common delimiters like {} or ;.

Syntax:

<attributeName><AttributeType> (x..y) <"Description">
    [
    <annotation1>]
        [
        <annotation2>]
            [...]

Example:

    type Engine: <"Description of the engine.">
    engineType EngineTypeEnum (1..1) <"Type of engine.">
    power number (1..1) <"Break horse power.">
    mpg number (1..1) <"Miles per gallon.">
    emissionMetrics EmissionMetrics (1..1) <"List of emission metrics in grams per km.">

2.2 Inheritance

You can enhance definitions via an inheritance mechanism. If you add a sub-type it inherits all its behaviour and attributes from a super-type and adds its own behaviour and set of attributes on top.

Inheritance is supported by the extends keyword.

Syntax:

type <SubType> extends <SuperType>

Example:

type Vehicle extends VehicleFeature:
specification Specification (1..1)
registrationID string (1..1)
vehicleTaxBand VehicleTaxBandEnum (1..1)
vehicleClassification VehicleClassificationEnum (1..1)

You can also use the override keyword to restrict the type or cardinalityCardinality The number of elements in a set or other grouping, as a property of that grouping., or to add annotations to a definition.

Note: For clarity, our documentation snippets leave out annotations and type details, unless the snippet is meant to show them.

Syntax:

type <SubType> extends <SuperType>
override

Example:

type VehicleReport:
vehicleRegistrationID string (1..1)
firstRegistrationDate date (0..1)
engineType EngineTypeEnum (0..1)

type EuropeanParliamentReport extends VehicleReport:
override vehicleRegistrationID Max40Text (1..1) // Change type to compatible string type limited to 40 characters
[ruleReference VehicleRegistrationID] // Add rule reference
override firstRegistrationDate date (1..1) // Change cardinality to be required
[ruleReference FirstRegistrationDate] // Add rule reference
override engineType EngineTypeEnum (1..1) // Change cardinality to be required
[ruleReference EngineType] // Add rule reference
// New attributes can be a added after all overrides
vehicleClassificationType VehicleClassificationEnum (1..1)
[ruleReference VehicleClassificationType]
euroEmissionStandard string (1..1)
[ruleReference EuroEmissionStandard]

2.3 Choice type (union type)

A choice type component is a user interface element that lets you select values from a predefined list, which may be shown as a dropdown menu, radio buttons or checkboxes. It allows you to define a group of related types where a value can be one of the listed options. It's often called a union type in other languages.

You define a choice type using the choice keyword, followed by a name and a list of the possible types. A description for your choice type is optional but recommended.

Syntax:

choice <TypeName>: <"Description">
[
<annotation1>]
    [
    <annotation2>]
        [...]
        <Type1>
            <Type2>
                <
                ...>

Example:

choice Vehicle:
[metadata key]
Car
Bicycle
Motorcycle

3. Enumeration (Enum)

An enumeration ensures a type can only take on a specific, controlled set of values. It’s basically a named container for a list of valid values (sometimes called a scheme).

Enumeration is defined using the enum keyword. The name should use PascalCase and be unique to a namespace. It should end with the suffix Enum. The definition contains a plain-text description of the enumeration and the list of enumeration values.

Syntax:

enum <EnumerationName>: <"Description">
<Value1> (optional: displayName <"DisplayName">) <"Description">
    <Value2>
        <
        "Description">
        <...>

Example:

        enum PeriodEnum: <"The enumerated values to specify the period, e.g. day, week.">
        D <"Day">
        W <"Week">
        M <"Month">
        Y <"Year">

3.1 Display names and special characters

Enumeration values can't start with digits or use special characters (except underscore _).

If you need to integrate scheme values with special characters you can use a displayName and replace special characters with _ while the displayName entry corresponds to the actual value. For example, the day count fraction scheme for interest rate calculation includes values such as ACT/365.FIXED and 30/360. These are associated as displayName to the ACT_365_FIXED and _30_360 enumeration values, respectively.

Syntax:

enum <EnumerationName>: <"Description">
<Value_1>
    <
    "DisplayName">) <"Value/1">

Example:

enum DayCountFractionEnum:
ACT_360 displayName "ACT/360"
ACT_365L displayName "ACT/365L"
ACT_365_FIXED displayName "ACT/365.FIXED"
ACT_ACT_AFB displayName "ACT/ACT.AFB"
ACT_ACT_ICMA displayName "ACT/ACT.ICMA"
ACT_ACT_ISDA displayName "ACT/ACT.ISDA"
ACT_ACT_ISMA displayName "ACT/ACT.ISMA"
BUS_252 displayName "BUS/252"
_1_1 displayName "1/1"
_30E_360 displayName "30E/360"
_30E_360_ISDA displayName "30E/360.ISDA"
_30_360 displayName "30/360"

3.2 External reference data

To avoid duplicating data, you can link an enumeration to an external source (like a URL) using [docReference ... schemeLocation ...], which instructs the model processor to import the values from that source.

Syntax:

[docReference <Body> <Corpus> schemeLocation <"URL">]

Example:

enum FloatingRateIndexEnum: <"The enumerated values to specify the list of floating rate index.">
[docReference ISDA FpML_Coding_Scheme schemeLocation
"http://www.fpml.org/coding-scheme/floating-rate-index-3-2"]

// Those enumeration values are imported from the source scheme
AED_EBOR_Reuters displayName "AED-EBOR-Reuters"
<...>

Footnotes

1. Do we need an example for each: date, dateTime, zonedDateTime? ↩