A DCR XML Log format is defined in

This document proposes an XML format for serializing DCR runs. Recording traces comes up in several contexts:

  • Input for the “Simulation Log” in the simulator in the portal
  • Input for the swimlane visualiser
  • Output of the path analyser
  • Data structure for saved simulations
  • (Potential) data structure for DCR logs in a process mining context

The format below attempts to cater to all of these.

One could imagine a log format that is relative to a DCR graph. Such a format would not need to represent explicitly roles or labels, as these would be reconstructible from said DCR graph. The present format *does not* attempt such minimality, opting rather to be complete enough for all of the above purposes.

2, 4, and 5 does not have such a context DCR graph.

NB! A log processor must preserve labels and nodes not mentioned in this document.

Log format

A log is a collection of traces:



[ entries ]





Trace format

A trace is a sequence of entries, where an entry is either an <event> element or an <advance> element, the former indicating the execution of an event, the latter that time advanced.

The <trace> element has the following attributes:

  • Mandatory attributes
    • initTime – initialization time of trace
    • id=”19-1234″
    • created – created date of the trace
  • Optional attributes
    • title=”my very first trace”
    • description=…
  • For scenarios – the following attributes are mandatory
    • isAccepting – true/false
    • percentage=”7″ – how often does this trace occur in the overall list of traces (scenario log)
    • type – required, neutral, forbidden (scenario log)
    • isScenario – true/false (scenario log)

The <event> element has the following attributes. Attributes not explicitly
marked as “mandatory” are optional.

  • `id=”A”`. The id of the event to execute. Mandatory.
  • `timestamp=”2017-04-27T09:55:45.4412580+02:00″`. The physical time in [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) of the execution of the event.
  • `user=”Thomas”`. A string identifying the user requesting the execution of the event. The interpretation of the string is implementation specific.
  • `role=”doctor”`. The role under which the user executed the event. Multiple roles are permitted and must be separated by commas. Each role must be a “role” of the (an) underlying DCR process.
  • `label=”Administer medicine”`. The DCR label of the event.
  • `data=”9″`. The data-value supplied as input.

The <advance> element has the following attributes.

The <note> element has the following attributes.

  • `id=”A”`. The id of the event to execute. Optional.
  • `comment=”this is a comment”`. A comment entered by the end user. Optional.
  • `timestamp=”2017-04-27T09:55:45.4412580+02:00″`. The physical time in [ISO 8601]

Moreover, the <advance> element admits the “timestamp” and “user” attributes, with syntax, requiredness and semantics as for the `event` element.


<trace id=”19-1234″ title=”My very first trace” percentage=”90,00″  initTime=”2020-01-02T15:39:25.4577929Z”>

<event id=”A” label=”Administer medicine” data=”‘8cc'”/>

<event id=”T” label=”Receive permission” timestamp=”2017-04-27T09:55:45.4412580+02:00″ />

<note id=”A” comment=”I do not understand why this event is still in the task list” />

<event id=”Process[0].A” label=”Initiate investigation” user=”Morten Marquard” role=”Doctor” timestamp=”2017-04-27T09:55:45.4412587+02:00″ />

<advance delta=”P0Y0M7D” />

<advance delta=”P0Y0M5D” user=”Thomas Hildebrandt (hilde@itu.dk)” timestamp=”2017-04-27T09:55:45.4412580+02:00″ />



Two types  of DCR XML Logs

  1. Scenario Log
  2. Instance log

Add definion – todo

Changes to DCR XML

We propose replacing the current “log” element with “trace”, conforming to the above specification. This proposal loses backwards compatbility on two counts:

  • Current DCR xml does not have a ‘trace’, using instead a ‘log’ element for the same purpose.
  • Current DCR uses the attribute “timeStamp” rather than “timestamp”

Ad (2). The “timestamp” attribute loses backwards compatibility with existing formats; however, as “timestamp” is an [english word](https://en.oxforddictionaries.com/definition/timestamp), the name `timestamp` is not camel-case but a spelling error.

We propose, for backwards compatibility, that the Engine correctly reads the trace-less log format and the name “timeStamp”, but always emits the new format.