v8.2.0

This release adds support for the conversion operations to-enum, to-string, to-number, to-int, and to-time. Examples:

Given the following enum

enum Foo:
    VALUE1
    VALUE2 displayName "Value 2"

• Foo -> VALUE1 to-string will result in the string "VALUE1",
• Foo -> VALUE2 to-string will result in the string "Value 2", (note that the display name is used if present)
• "VALUE1" to-enum Foo will result in the enum value Foo -> VALUE1,
• "Value 2" to-enum Foo will result in the enum value Foo -> VALUE2, (again, the display name is used if present)
• "-3.14" to-number will result in the number -3.14,
• "17:05:33" to-time will result in a value representing the local time 17 hours, 5 minutes and 33 seconds.

If the conversion fails, the result is an empty value. For example,

• "VALUE2" to-enum Foo results in an empty value, (because Foo -> VALUE2 has a display name "Value 2", this conversion fails)
• "3.14" to-int results in an empty value.

v8.1.0

This release contains additional type validation and various patches.

• It enables type validation for legacy-syntax rules to check that the declared input type matches the expected input type.
• It contains a patch for redirecting Xtext's logging (which uses reload4j) to slf4j, so we get additional useful debugging info in our BSP logs. I've also added a maven-enforcer rule to make sure we don't include log4j/reload4j/log4j-core anywhere.
• It contains various patches which reduces the amount of superfluous validation messages (e.g., EValidator has crashed , NPE's) when validating a partial model (while typing/in process of upgrading DSL versions).
• It contains a patch for our blueprint code generator, which was generating uncompilable code for legacy-syntax rules containing a filter when expression.

v8.0.0

This release is a step towards the harmonisation of the expression syntaxes for functions and rules. (#397, #455, #584)

• Support for using core syntax expressions in rules. This is the default behaviour. Legacy syntax is still supported by applying the [legacy-syntax] annotation to a rule. This allows us to gradually move away from the old syntax, and to identify use cases that are not yet supported in the core syntax.
• Deprecated support for referring to the implicit input by using the type name. (e.g., ReportableEvent -> ...) This usage is still allowed in legacy syntax rules. In all other cases, item should be used instead.
• Made colons for rules mandatory.
• Support for specifying the input type of a rule and a report with from <type>. This is mandatory.
• Support for using filter on expressions of singular cardinality.
• Removal of the output keyword on rules.
• Support for calling rules from within the core syntax, similar to a function call with one parameter. This is limited to expressions in rules - functions cannot call rules.
• Fixed various null pointer exceptions and validator crashes while working with partial or invalid rules.

v7.7.0

This release introduces an additional feature of the Java code generator. For each Rosetta type, a new <type name>TypeFormatValidator class will be generated which will perform type format validation on all attributes of the type.

Type format validation includes all checks associated with the parametrized string and number types, i.e., minLength, maxLength and pattern for string, and digits, fractionalDigits, min and max for number.

v7.6.0

This release features the beforeAllGenerate and afterAllGenerate hooks for external code generators.

It also adds a rosetta-maven-plugin - an extension of the xtext-maven-plugin which will actually call these new hooks.

v7.5.3

Changes make parameterized types backwards compatible

v7.5.2

Import model from xsd updated to support different documentation tags

v7.5.1

Added template for GitHub Pull Requests

v7.5.0

Parametrized basic types

This release introduces parametrized basic types, which allows modellers to further specify properties of the type. For example, modellers can further specify that something isn't just any string, but a string with at least one character and a maximum of 80 characters with string(minLength: 1, maxLength: 80), or they can specify that something is a positive number - not just any number - with number(min: 0).

Important notes for developers

This feature constitutes an important change to our DSL's syntax tree (Ecore). Accessing the type of an attribute directly via RosettaType Attribute::getType() isn't possible anymore. Types are now replaced by type calls - much like a function call but on the type level - which can be accessed using TypeCall Attribute::getTypeCall().

Note that a RosettaType is now similar to a function - it needs arguments before it can be evaluated.

Recommended way of processing types of attributes:

• inject RosettaTypeProvider and use its method symbolToRType(attribute) (or any of its other utility methods), which will evaluate the type call and provide you with a normalized representation of a type - an RType. For example, evaluating the type call number(min: 0) will result in a RNumberType with its property min set to Optional.of(0) and all of its other properties set to Optional.empty().
• lower-level: inject TypeSystem and use its method typeCallToRType(typeCall) to directly evaluate a type call.

Type aliases

This release introduces type aliases, which allows modellers to define meaningful names for parametrized basic types. For example, modellers can define an alias typeAlias max80Text: string(minLength: 1, maxLength: 80), and then further use the type max80Text to refer to the verbose string(minLength: 1, maxLength: 80) type.

Furthermore, these type aliases may specify parameters themselves, e.g., typeAlias maxNText(n int): string(minLength: 1, maxLength: n). Using this principle, the int type is now defined as an alias of number - instead of as a basic type - by setting the property fractionalDigits to 0:

typeAlias int(digits int, min int, max int): number(digits: digits, fractionalDigits: 0, min: min, max: max)

Important notes for developers

With the introduction of type aliases, common equality checks for types such as type.getName().equals("string") and type.equals(typeOfParentAttribute) won't work anymore. For the first case for example, type might be an alias of string such as max80Text instead, which will make the condition fail although it probably shouldn't.

Recommended way of comparing types:

• never compare names (i.e., type.getName().equals(...)). To refer to a builtin type such as string, inject RBuiltinTypeService, and use one of the constants it defines such as BOOLEAN and UNCONSTRAINED_STRING.
• replace an equality check with an appropriate subtype check. Use the method TypeSystem::isSubtypeOf(RType a, RType b) for this. For example, the check type.getName().equals("string") can be replaced with isSubtypeOf(type, UNCONSTRAINED_STRING).

v7.4.0

Generate model from imported xsd