Below is a description of the scenario definition syntax, which includes elements, attributes, and metadata — followed by a formal syntax definition (for reference).


The most basic form in a scenario definition is an element. You write a scenario definition as a tree of elements. An element starts with an optional name. Below is an example with a name but no value:


Values or child elements

The element can either take an optional value, which is expressed like this:

myElement "some value";

…​or it can take a list of child elements, expressed like this:

myElement {
  child1 "some value";
  child2 "some value";


Below is simplified example of how this looks in practice:

callBarringScenario {
  InitialDP {
    callingPartyNumber "123456";


A number of different instructions can affect the behaviour of the scenario. These are expressed as attributes of the element. For example:

callingPartyNumber (COUNT 0..1, ALIAS caller) "123456";

COUNT and ALIAS are attribute names. Both these attributes take values, but not all do. For example, the DISABLED attribute takes no value:

callingPartyNumber (DISABLED) "123456";

If necessary, an attribute value may quoted:

callingPartyNumber (ALIAS "some long name") "123456";

Each attribute may occur at most once in an element. For example, the following element is not valid because it defines the ALIAS attribute twice:

    (ALIAS name1, ALIAS name2) // Invalid


Some elements may also contain metadata, commonly used by the graphical editor to store display data in the scenario file. Metadata doesn’t affect the runtime behaviour of the scenario, and can be ignored by a scenario author. Below is an example element containing both attributes and metadata:

    [ui_node_collapsed true, ui_selected false]
    (COUNT 0..1, ALIAS caller) "123456";

Formal syntax definition

While it’s not necessary to understand the formal definition of the DSL to read and write scenario definitions, you can use the following ANTLR grammar file as reference.

grammar ScenarioDefinition;

// Parser rules ...

element : header QUOTED_STRING? ';'
    | header '{' element* '}'

header  : NAME? attributes_and_metadata

    // Allow for either order
    : attributes metadata
    | metadata attributes
    | attributes
    | metadata

    : '(' (attribute (',' attribute)*)? ')'

    : '[' (attribute (',' attribute)*)? ']'

    | key=NAME val=NAME

// Lexer rules ...

NAME: ('a'..'z'|'A'..'Z'|'0'..'9')
    | ('a'..'z'|'A'..'Z'|'0'..'9') ('a'..'z'|'A'..'Z'|'0'..'9'|'.'|'_'|'-')* ('a'..'z'|'A'..'Z'|'0'..'9')

    : '"' ( ESCAPE_SEQUENCE | ~( '"' | '\\' ) )* '"'

    : '\\' ('t'|'n'|'r'|'\\'|'\"')

COMMENT	: '//' ~('\n'|'\r')* ('\n'|'\r'|'\r\n')	 { skip(); }
    | '//' ~('\n'|'\r')*                     { skip(); }

WS	: (' '|'\t'|'\n'|'\r')+ { skip(); }
Previous page Next page