DCR XML Log
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.
A log is a collection of traces:
[ entries ]
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
- created – created date of the trace
- Optional attributes
- title=”my very first trace”
- 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.
- `delta=”7″`. The duration to advance time in ISO 8601 duration format (https://en.wikipedia.org/wiki/ISO_8601#Durations). Mandatory.
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.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 (firstname.lastname@example.org)” timestamp=”2017-04-27T09:55:45.4412580+02:00″ />
Two types of DCR XML Logs
- Scenario Log
- 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.