Fix some typos

_glossary/atomic-state.md

@@ -1,6 +1,6 @@
 ---
 title: Atomic state
-oneliner: a state that has no substates
+oneliner: A state that has no substates
 keywords: atomic, simple, empty state
 breadcrumbs:
   - id: state
@@ -15,7 +15,7 @@ aka:
 
 _Also known as **Simple state**_
 
-An atomic state is a [state](state.html){:.glossary} that has no _substates_.  States that have substates are either [compound states](compound-state.html){:.glossary} or [parallel states](parallel-state.html){:.glossary}.
+An atomic state is a [state](state.html){:.glossary} that has no _substates_. States that have substates are either [compound states](compound-state.html){:.glossary} or [parallel states](parallel-state.html){:.glossary}.
 
 Atomic states do not define "initial" states either.
 
@@ -29,7 +29,7 @@ For atomic states that have no actions, and are otherwise empty, a very small, r
 
 In SCXML, an atomic state is any state that has no _state_ children:
 
-``` xml
+```xml
 <state id="my_atomic_state">
   <onentry>
     <script>do_the_thing()</script>

_glossary/automatic-transition.md

@@ -1,6 +1,6 @@
 ---
 title: Automatic transition
-oneliner: a transition that happens immediately upon entering a state or immediately after a condition arises
+oneliner: A transition that happens immediately upon entering a state or immediately after a condition arises
 breadcrumbs:
   - id: transition
     name: Transition
@@ -18,9 +18,9 @@ Automatic transitions are [transitions](transition.html){:.glossary} that are tr
 
 Automatic transitions don't have an associated [event](event.html){:.glossary}, as the mere being in the state implies that the transition should be taken.
 
-Automatic transitions are usually [guarded](guard.html){:.glossary}.  Such a guarded automatic transition is checked immediately after the state is entered.  If the condition doesn't hold then the machine remains in the state, with this automatic transition in play _for as long as the state is active_.  Every time the statechart handles an event, the guard condition for these automatic transitions are checked.  If the guard condition ever succeeds, then the transition happens. 
+Automatic transitions are usually [guarded](guard.html){:.glossary}. Such a guarded automatic transition is checked immediately after the state is entered. If the condition doesn't hold then the machine remains in the state, with this automatic transition in play _for as long as the state is active_. Every time the statechart handles an event, the guard condition for these automatic transitions are checked. If ever the guard condition ever succeeds, then the transition happens.
 
-If there are many automatic transitions in play, they are all checked.  In some statechart systems, only one guard is allowed to be true at any point in time; in others, the transitions are ordered, and the guards are checked until a one of them succeeds.
+If there are many automatic transitions in play, they are all checked. In some statechart systems, only one guard is allowed to be true at any point in time; in others, the transitions are ordered, and the guards are checked until a one of them succeeds.
 
 ## Notation
 
@@ -31,16 +31,15 @@ A transition arrow, but without the name of an event, only guards and/or actions
     ---------------------->
 ```
 
-
 ## Usage
 
-Guarded transitions can be used to cause a machine to "wait" in a certain state, _until_ some condition holds, regardless of what else is happening in the form of events.  For example, a machine could be in the 'filling' state until some threshold is reached, by defining an automatic transition from the 'filling' state with a guard `contents >= capacity`.  Immediately after the contents reach the capacity, it would exit from this 'filling' state.
+Guarded transitions can be used to cause a machine to "wait" in a certain state, _until_ some condition holds, regardless of what else is happening in the form of events. For example, a machine could be in the 'filling' state until some threshold is reached, by defining an automatic transition from the 'filling' state with a guard `contents >= capacity`. Immediately after the contents reach the capacity, it would exit from this 'filling' state.
 
-By using an _in_ guard, it is possible to coordinate different parts of a [parallel state](parallel-state.html){:.glossary}.  When the one region ends up on a certain state, it can wait until another region enters a specific state.
+By using an _in_ guard, it is possible to coordinate different parts of a [parallel state](parallel-state.html){:.glossary}. When the one region ends up on a certain state, it can wait until another region enters a specific state.
 
-If a machine is in a state with a guarded automatic transition, then that guard is checked as often as possible.  Being event driven, the guards are effectively only checked whenever an event has been processed, but also after other automatic transitions have fired, or other internal events (such as [raised events](raised-event.html){:.glossary} are fired.
+If a machine is in a state with a guarded automatic transition, then that guard is checked as often as possible. Being event–driven, the guards are effectively only checked whenever an event has been processed, but also after other automatic transitions have fired, or other internal events (such as [raised events](raised-event.html){:.glossary}) are fired.
 
-Automatic transitions can be used to implement a [condition states](condition-state.html){:.glossary}, in other words, a state that only has automatic transitions.  This is done by creating a state that only declares guarded automatic transitions, in such a way that it is guaranteed that the machine will always pick a transition upon entry, never _resting_ in that state.
+Automatic transitions can be used to implement a [condition states](condition-state.html){:.glossary}, in other words, a state that only has automatic transitions. This is done by creating a state that only declares guarded automatic transitions, in such a way that it is guaranteed that the machine will always pick a transition upon entry, never _resting_ in that state.
 
 ## SCXML
 

_glossary/compound-state.md

@@ -5,7 +5,7 @@ primaryImage: compound-state.svg
 keywords:
   - compound
   - compound state
-  - substate 
+  - substate
   - composite
   - composite state
   - child state
@@ -28,67 +28,66 @@ aka:
 
 _Also known as **Composite state** and **Or state**_
 
-A compound state is a [state](state.html){:.glossary} that includes one or more substates.  It is the main differentiating factor between traditional state machines and statecharts.  A compound state can be thought of as _containing its own state machine_.
+A compound state is a [state](state.html){:.glossary} that includes one or more substates. It is the main differentiating factor between traditional state machines and statecharts. A compound state can be thought of as _containing its own state machine_.
 
 ## Notation
 
 A compound state is a normal state with its substates depicted _inside_ the borders of the state itself:
 
 ![A state "Off" with substates A and B](compound-state.svg)
 
-Here, the state called **Off** is a compound state.  It has two states **A** and **B** as its substates.  Note how the substates constitute their own state machine, even with an [initial state](initial-state.html){:.glossary}.
+Here, the state called **Off** is a compound state. It has two states **A** and **B** as its substates. Note how the substates constitute their own state machine, even with an [initial state](initial-state.html){:.glossary}.
 
 ## Description
 
 If there are more than one substates, one of them is usually designated as the [initial](initial-state.html){:.glossary} state of that compound state.
 
-When a compound state is active, its substates behave as though they were an active state machine:  Exactly one child state must also be active.  This means that:
+When a compound state is active, its substates behave as though they were an active state machine: Exactly one child state must also be active. This means that:
 
-* When a compound state is [entered](enter.html){:.glossary}, it must also enter exactly one of its substates, usually its initial state.
-* When an [event](event.html){:.glossary} happens, the _substates_ have priority when it comes to selecting which transition to follow.  If a substate happens to handles an event, the event is consumed, it isn't passed to the parent compound state.
-* When a substate [transitions](transition.html){:.glossary} to another substate, both "inside" the compound state, the compound state does _not_ exit or enter; it remains active.
-* When a compound state [exits](exit.html){:.glossary}, its substate is simultaneously exited too. (Ttechnically, the substate exits first, _then_ its parent.)
+- When a compound state is [entered](enter.html){:.glossary}, it must also enter exactly one of its substates, usually its initial state.
+- When an [event](event.html){:.glossary} happens, the _substates_ have priority when it comes to selecting which transition to follow. If a substate happens to handles an event, the event is consumed, it isn't passed to the parent compound state.
+- When a substate [transitions](transition.html){:.glossary} to another substate, both "inside" the compound state, the compound state does _not_ exit or enter; it remains active.
+- When a compound state [exits](exit.html){:.glossary}, its substate is simultaneously exited too. (Technically, the substate exits first, _then_ its parent.)
 
 Compound states may be nested, or include [parallel](parallel-state.html){:.glossary} states.
 
 The opposite of a compound state is an [atomic state](atomic-state.html){:.glossary}, which is a state with no substates.
 
-A compound state is allowed to define transitions to its child states. Normally, when a transition leads from a state, it causes that state to be exited.  For transitions from a compound state to one of its descendantes, it is possible to define a transition that avoids exiting and entering the compound state itself, such transitions are called [local transitions](local-transition.html){:.glossary}. 
+A compound state is allowed to define transitions to its child states. Normally, when a transition leads from a state, it causes that state to be exited. For transitions from a compound state to one of its descendantes, it is possible to define a transition that avoids exiting and entering the compound state itself, such transitions are called [local transitions](local-transition.html){:.glossary}.
 
 ## Usage
 
-An atomic state is often converted to a compound state in order to change its behaviour slightly.  The newly introduced substates get a chance to override the behaviour by defining how to react to different events.  The substates only need to define the differences in behaviour.  The (now) compound state defines the general behaviour, and substates define deviations from this behaviour.
+An atomic state is often converted to a compound state in order to change its behaviour slightly. The newly introduced substates get a chance to override the behaviour by defining how to react to different events. The substates only need to define the differences in behaviour. The (now) compound state defines the general behaviour, and substates define deviations from this behaviour.
 
-The act of changing an atomic state into a compound state (by introducing a substate or two) is called _refining_ the state.  The refinement alludes to the different behaviour encoded in the substates as being a _refinement_, or _specialization_ of the general behavour of the compound state.
+The act of changing an atomic state into a compound state (by introducing a substate or two) is called _refining_ the state. The refinement alludes to the different behaviour encoded in the substates as being a _refinement_, or _specialization_ of the general behavour of the compound state.
 
-A group of states can be collected into a compound state to factor out _common transitions_.  For example, if five sibling states all have the same transitions to a particular target, it can be beneficial to move those five states into a single compound state, and then move the individual transitions to the compound state.
+A group of states can be collected into a compound state to factor out _common transitions_. For example, if five sibling states all have the same transitions to a particular target, it can be beneficial to move those five states into a single compound state, and then move the individual transitions to the compound state.
 
 The act of grouping states with commonalities into a compound state is called _clustering_.
 
-Technically a statechart itself is usually (at the top level) a compound state itself.  Some systems allow the machine to be a parallel state.
-
+Technically a statechart itself is usually (at the top level) a compound state itself. Some systems allow the machine to be a parallel state.
 
 ### Zooming in and out
 
-The nesting of states in a hierarchy can lead to complicated charts when it is visualized.  It is possible to conceal the internals of a compound state by excluding substates from the visualization.  This technique is called _zooming out_.  Zooming _in_ would then reveal the details.
+The nesting of states in a hierarchy can lead to complicated charts when it is visualized. It is possible to conceal the internals of a compound state by excluding substates from the visualization. This technique is called _zooming out_. Zooming _in_ would then reveal the details.
 
 ## SCXML
 
 In Statechart XML, a compound state is any state with nested state elements as direct children; this includes `<parallel>`, `<initial>` elements too, as these are also state elements.
 
-``` xml
+```xml
 <state id="off">
   <transition event="flick" target="on" />
-  <state id="A"/>
-  <state id="B"/>
+  <state id="A" />
+  <state id="B" />
 </state>
 ```
 
 A compound state's initial state is either identified by the `initial` attribute of the compound state, or the `<initial>` state, and if none of these is specified, the first state in document order.
 
 ## XState
 
-An XState [compound state](https://xstate.js.org/docs/guides/hierarchical.html) is declared using the `states` property of the state, holding an object containing substates.  Each key value pair declares the name and definition of the state, respectively.
+An XState [compound state](https://xstate.js.org/docs/guides/hierarchical.html) is declared using the `states` property of the state, holding an object containing substates. Each key value pair declares the name and definition of the state, respectively.
 
 ```javascript
 "off": {
@@ -109,7 +108,7 @@ The `initial` property must specify the initial state.
 
 In SCION-CORE, a compound state is declared by specifying the `states` property of the state in question, containing an array of state objects.
 
-``` javascript
+```javascript
 {
   id: "off",
   states: [

_glossary/condition-state.md

@@ -1,6 +1,6 @@
 ---
 title: Condition state
-oneliner: A pseudo-state that only has transitions, guarded in such a way that it immediately moves to another state.
+oneliner: A pseudo-state that only has transitions, guarded in such a way that it immediately moves to another state
 date: 2019-02-24
 breadcrumbs:
   - id: state
@@ -18,28 +18,28 @@ aka:
 
 # Condition state
 
-A condition state is a state that essentially consists _solely_ of [automatic](automatic-transition.html){:.glossary}, [guarded](guard.html){:.glossary} [transitions](transition.html){:.glossary}, so that upon entry, the state will always immediately exit to another state.  A condition state is used to group similar sets of incoming transitions, so that the guards of those transitions don't need to be repeated.  It can also be used to simplify entry to a state, by allowing the source of a transition to target a single condition state, where the choice of target state happens.
+A condition state is a state that essentially consists _solely_ of [automatic](automatic-transition.html){:.glossary}, [guarded](guard.html){:.glossary} [transitions](transition.html){:.glossary}, so that upon entry, the state will always immediately exit to another state. A condition state is used to group similar sets of incoming transitions, so that the guards of those transitions don't need to be repeated. It can also be used to simplify entry to a state, by allowing the source of a transition to target a single condition state, where the choice of target state happens.
 
-To be called a condition state, there should be no actions or activities defined in the state.  Condition states do not have child states.  All transitions must be automatic, and care must be taken when defining the guards, to ensure that at least one transition will always be taken. This is usually done by including one unguarded automatic transition.
+To be called a condition state, there should be no actions or activities defined in the state. Condition states do not have child states. All transitions must be automatic, and care must be taken when defining the guards, to ensure that at least one transition will always be taken. This is usually done by including one unguarded automatic transition.
 
 ## Notation
 
 Harel's original paper defined a condition state to be denoted using a capital letter C enclosed by a circle.
 
 ![A compound state B with condition state](condition-state.svg)
 
-Note that in UML, _junction states_ and _choice states_ are similar to condition states, and use slightly different notation:  Junction states are denoted by an opaque, black circle, while choice states are denoted by a diamond.
+Note that in UML, _junction states_ and _choice states_ are similar to condition states, and use slightly different notation: Junction states are denoted by an opaque, black circle, while choice states are denoted by a diamond.
 
 ## Usage
 
-Statecharts can easily get cluttered when the number of states increases.  Not necessarily due to the number of states, but rather the number of transitions between the states.  Condition states allow you to combine similar transitions thereby reducing the number of lines connecting the various states.  The usefulness is increased if many of the transitions have the same guard conditions.
+Statecharts can easily get cluttered when the number of states increases. Not necessarily due to the number of states, but rather the number of transitions between the states. Condition states allow you to combine similar transitions thereby reducing the number of lines connecting the various states. The usefulness is increased if many of the transitions have the same guard conditions.
 
 Condition states are often used in two ways:
 
-* Reduce the number of transitions from a compound state that end up in the same target, by combining the transitions in the source state.
-* Combine several guarded transitions going in to a compound state (that come from the same source).  This is known as a conditional entry to a state.
+- Reduce the number of transitions from a compound state that end up in the same target, by combining the transitions in the source state.
+- Combine several guarded transitions going in to a compound state (that come from the same source). This is known as a conditional entry to a state.
 
-When making changes to a statechart, it is often the case that you need similar sets of guards to control different states.  In the following example, we have two main states A and B, where state A has three separte transitions for event _e_, each leading to a specific substate of B.  The choice of which substate we end up in is determined by the individual guards.
+When making changes to a statechart, it is often the case that you need similar sets of guards to control different states. In the following example, we have two main states A and B, where state A has three separte transitions for event _e_, each leading to a specific substate of B. The choice of which substate we end up in is determined by the individual guards.
 
 **The guards that determine the final source, are outside the compound state B.**{:.caption}
 ![Atomic state A and compound state B, the latter with substates 1, 2, and 3. An event e enters 1, 2 or 3 depending on guards](condition-state-before.svg)
@@ -49,24 +49,25 @@ The problem is apparent if you try to introduce another state, say C, which also
 **By adding a single state C, which has transitions similar to A, we had to duplicate many guards.**{:.caption}
 ![Atomic states A and C, and compound state B, the latter with substates 1, 2, and 3. An event e in A (or event f in C) enters states 1, 2 or 3 depending on guards](condition-state-before-two.svg)
 
-By defining a condition state inside the compound state itself, the guard definitions are closer to the target states, making the statechart easier to reason about.  Let's remove state C again, and instead first introduce the _condition state_:
+By defining a condition state inside the compound state itself, the guard definitions are closer to the target states, making the statechart easier to reason about. Let's remove state C again, and instead first introduce the _condition state_:
 
-**The guards that determine the correct substate of B are now inside B, and state A is already easier to understand.  It also becomes easier to make changes to the statechart.**{:.caption}
+**The guards that determine the correct substate of B are now inside B, and state A is already easier to understand. It also becomes easier to make changes to the statechart.**{:.caption}
 ![Atomic state A, and compound state B, the latter with substates 1, 2, and 3.  An event e in A always leads to a condition state, which determines the final state using guards](condition-state-after.svg)
 
-Now, it becomes a lot easier to introduce the C state, without doubling the amount of transitions.  Now, since we have a state that represents the _conditional entry_, we can re-use that condition state by transitioning to it:
+Now, it becomes a lot easier to introduce the C state, without doubling the amount of transitions. Now, since we have a state that represents the _conditional entry_, we can re-use that condition state by transitioning to it:
 
 **The guards that determine the state of B are inside B, and states A and C are easier to understand.**{:.caption}
 ![Atomic states A and C, and compound state B, the latter with substates 1, 2, and 3.  An event e in A (or event f in C) enters a condition state, which determines the final state using guards](condition-state-after-two.svg)
 
-Condition states can help reduce clutter when introducing states and a whole set of transitions need to be copied over to a new state, or when several different events need similar sets of guards.  In such situations, consider introducing a condition state to encapsulate the logic.  Condition states can also help move guards closer to the target states, where this is desirable.
+Condition states can help reduce clutter when introducing states and a whole set of transitions need to be copied over to a new state, or when several different events need similar sets of guards. In such situations, consider introducing a condition state to encapsulate the logic. Condition states can also help move guards closer to the target states, where this is desirable.
 
 ## SCXML
 
 Condition states are not native to SCXML, but can easily be implemented by making a `<state>` element that consists only of automatic guarded transitions, ensuring that being in the state has no other effects than transitioning to another state:
 
 **`B_COND` is a condition state, used to provide a conditional entry to state B.**{:.caption}
-``` xml
+
+```xml
 <state id="A">
   <transition target="B_COND" event="e"/>
 </state>
@@ -83,24 +84,25 @@ Condition states are not native to SCXML, but can easily be implemented by makin
 </state>
 ```
 
-Here we have a state A which, on event "e" will transition to B_COND, which is a condition state, because it consists only of automatic, guarded transitions.  When in state A, and the event "e" happens:
+Here we have a state A which, on event "e" will transition to B_COND, which is a condition state, because it consists only of automatic, guarded transitions. When in state A, and the event "e" happens:
 
-* A will exit and enter B_COND.
-* Being in B_COND will immediately evaluate the guard `a == 1` and go directly to B1 if this is true.
-* Otherwise, B_COND will evaluate the guard `a == 0` and go to B2 if this is true.
-* Otherwiser, B_COND will go to B3.
+- A will exit and enter B_COND.
+- Being in B_COND will immediately evaluate the guard `a == 1` and go directly to B1 if this is true.
+- Otherwise, B_COND will evaluate the guard `a == 0` and go to B2 if this is true.
+- Otherwiser, B_COND will go to B3.
 
 This offers many benefits:
 
-* If this were to be implemented without the condition states, the transitions with `cond` logic would be in state `A`, whereas it is probably wiser to keep this logic closer to the states B1, B2 and B3.
-* If more events (e.g. `<transition target="B_COND" event="e2"/>`), or more sources of events (e.g. other than from `A`) lead to the same guarded transitions, a condition state reduces the amount of transitions that need to be defined.
+- If this were to be implemented without the condition states, the transitions with `cond` logic would be in state `A`, whereas it is probably wiser to keep this logic closer to the states B1, B2 and B3.
+- If more events (e.g. `<transition target="B_COND" event="e2"/>`), or more sources of events (e.g. other than from `A`) lead to the same guarded transitions, a condition state reduces the amount of transitions that need to be defined.
 
 ## XState
 
 Condition states are not native to XState, but can easily be implemented by making a state that consists only of automatic, guarded transitions, ensuring that being in the state has no other effects than transitioning to another state.
 
 **`COND` is a condition state, used to provide a conditional entry to state B.**{:.caption}
-``` javascript
+
+```javascript
 {
   states: {
     A: {
@@ -129,17 +131,17 @@ Condition states are not native to XState, but can easily be implemented by maki
 }
 ```
 
-Here we have a state "A" which, on event "e" will transition to "B.COND", which is a condition state, because it consists only of automatic, guarded transitions.  When in state A, and the event "e" happens:
+Here we have a state "A" which, on event "e" will transition to "B.COND", which is a condition state, because it consists only of automatic, guarded transitions. When in state A, and the event "e" happens:
 
-* A will exit and enter B.COND.
-* Being in COND will immediately evaluate the guard `a == 1` and go directly to "1" if this is true.
-* Otherwise, COND will evaluate the guard `a == 0` and go to "2" if this is true.
-* Otherwiser, COND will go to "3".
+- A will exit and enter B.COND.
+- Being in COND will immediately evaluate the guard `a == 1` and go directly to "1" if this is true.
+- Otherwise, COND will evaluate the guard `a == 0` and go to "2" if this is true.
+- Otherwiser, COND will go to "3".
 
 This offers many benefits:
 
-* If this were to be implemented without the condition states, the transitions with `cond` logic would be in state `A`, whereas it is probably wiser to keep this logic closer to the states B.1, B.2 and B.3.
-* If more events (e.g. `on: {e2: "B.COND"}`), or more sources of events elsewhere in the statechart (e.g. other than from `A`) lead to the same choices being made, a choice state reduces the amount of transitions that need to be defined.
+- If this were to be implemented without the condition states, the transitions with `cond` logic would be in state `A`, whereas it is probably wiser to keep this logic closer to the states B.1, B.2 and B.3.
+- If more events (e.g. `on: {e2: "B.COND"}`), or more sources of events elsewhere in the statechart (e.g. other than from `A`) lead to the same choices being made, a choice state reduces the amount of transitions that need to be defined.
 
 ## Relation to UML choice and junction states
 

_glossary/delayed-event.md

@@ -1,14 +1,14 @@
 ---
 title: Delayed event
-oneliner: an event that is raised some time after a transition takes place.
+oneliner: An event that is raised some time after a transition takes place
 breadcrumbs:
   - id: event
     name: Event
 ---
 
 # Delayed Event
 
-A delayed event is the ability for the statechart to send an event after a certain period of time.  Delayed events can be used to simulate [delayed transitions](delayed-transition.html){:.glossary}.
+A delayed event is the ability for the statechart to send an event after a certain period of time. Delayed events can be used to simulate [delayed transitions](delayed-transition.html){:.glossary}.
 
 ## Notation
 
@@ -19,45 +19,44 @@ Not sure
 A delayed event is specified using the following syntax:
 
 ```xml
-<send event="my_event" delay="5s"/>
+<send event="my_event" delay="5s" />
 ```
 
-The `delay` attribute specifies a CSS timing value.  The statechart implementation will raise the specified event after the amount of time.  It is possible to _cancel_ such a delayed event.  In order to do so, an identifier needs to be added to the `<send>`
+The `delay` attribute specifies a CSS timing value. The statechart implementation will raise the specified event after the amount of time. It is possible to _cancel_ such a delayed event. In order to do so, an identifier needs to be added to the `<send>`
 
 ```xml
-<send id="my_timeout" event="my_event" delay="5s"/>
+<send id="my_timeout" event="my_event" delay="5s" />
 ```
 
 To cancel, use the identifier in a `<cancel>` element:
 
 ```xml
-<cancel sendid="my_timeout"/>
+<cancel sendid="my_timeout" />
 ```
 
 These operations are typically done in entry or exit handlers, but can also be used in transitions.
 
 ### Simulating delayed transitions
 
-Delayed transitions are not part of Statechart XML.  Instead, you have to specify to send a delayed event, and a normal transition that handles that event.
+Delayed transitions are not part of Statechart XML. Instead, you have to specify to send a delayed event, and a normal transition that handles that event.
 
 For a simple delayed transition from `some_state` to `some_other_state` after 5 seconds, you need:
 
-* An entry handler that send a "fake" event `my_event` with a 5 second delay
-* An exit handler that cancels the sending of the event (in case the state is exited before 5 seconds)
-* A transition that handles the "fake" event by transitioning to the `some_other_state`.
+- An entry handler that send a "fake" event `my_event` with a 5 second delay
+- An exit handler that cancels the sending of the event (in case the state is exited before 5 seconds)
+- A transition that handles the "fake" event by transitioning to the `some_other_state`.
 
 Care must be taken to ensure statechart-wide unique values for the event and id, because there is no "local" scope.
 
 This is the result:
 
-
 ```xml
 <state id="some_state">
   <onentry>
-    <send id="my_timeout" event="my_event"  delay="5s"/>
+    <send id="my_timeout" event="my_event" delay="5s" />
   </onentry>
   <onexit>
-    <cancel sendid="my_timeout"/>
+    <cancel sendid="my_timeout" />
   </onexit>
   <transition event="my_event" target="some_other_state" />
 </state>

_glossary/delayed-transition.md

@@ -1,6 +1,6 @@
 ---
 title: Delayed transition
-oneliner: a transition that executes automatically when a machine has been in a state for a particular amount of time
+oneliner: A transition that executes automatically when a machine has been in a state for a particular amount of time
 breadcrumbs:
   - id: transition
     name: Transition
@@ -10,7 +10,7 @@ breadcrumbs:
 
 A delayed transition is an [transition](transition.html){:.glossary} that happens after a period of time, specifically being in a specific state for a certain amount of time.
 
-Whenever such a delayed transition exists in a state, the state machine will execute the transition if and only if the machine has stayed continously in the state for a given period of time.  If the state has a [self transition](self-transition.html){:.glossary} which is executed, this causes the state to be [exited](exit.html){:.glossary} and then [entered](enter.html){:.glossary} again, interrupting any continuity.
+Whenever such a delayed transition exists in a state, the state machine will execute the transition if and only if the machine has stayed continously in the state for a given period of time. If the state has a [self transition](self-transition.html){:.glossary} which is executed, this causes the state to be [exited](exit.html){:.glossary} and then [entered](enter.html){:.glossary} again, interrupting any continuity.
 
 ## Notation
 
@@ -21,7 +21,7 @@ A delayed event uses the phrase "after <timespec>" as the name of the event
 
 ## SCXML
 
-Delayed transitions are not part of Statechart XML.  Instead, you have to specify to send a [delayed event](delayed-event.html){:.glossary}, and a normal transition that handles that event.  The delayed event must be given a name, and also a unique identifier (in order to cancel the delayed event).
+Delayed transitions are not part of Statechart XML. Instead, you have to specify to send a [delayed event](delayed-event.html){:.glossary}, and a normal transition that handles that event. The delayed event must be given a name, and also a unique identifier (in order to cancel the delayed event).
 
 ## XState
 

_glossary/enter.md

@@ -7,10 +7,10 @@ redirect_from:
 
 # Enter
 
-Refers to the act of _entering a state_ during the execution of a state machine.  The state machine keeps track of which state is [active](active.html){:.glossary} and its behaviour is defined based on the active state(s).  A state may declare entry [actions](action.html){:.glossary}, which will be executed when a state is entered.
+Refers to the act of _entering a state_ during the execution of a state machine. The state machine keeps track of which state is [active](active.html){:.glossary} and its behaviour is defined based on the active state(s). A state may declare entry [actions](action.html){:.glossary}, which will be executed when a state is entered.
 
 If a state is a [compound state](compound-state.html){:.glossary}, the defined [initial state](initial-state.html){:.glossary} is also entered, since in an active compound state, exactly one substate must also be active.
 
 If a state is a [parallel state], each region and their initial states will also be entered.
 
-Entry of a state is defined to be instantaneous for all practical purposes; this includes the execution of any entry actions, and the entry of all substates.  In other words, a state can never be "half entered" or "half active".
+Entry of a state is defined to be instantaneous for all practical purposes; this includes the execution of any entry actions, and the entry of all substates. In other words, a state can never be "half entered" or "half active."

_glossary/final-state.md

@@ -1,33 +1,32 @@
 ---
 title: Final state
-oneliner: a helper state which designates that its parent state has completed
+oneliner: A helper state which designates that its parent state has completed
 breadcrumbs:
   - id: state
     name: State
 ---
 
 # Final State
 
-A final state is a state in a [compound state](compound-state.html){:.glossary} that designates that the compound state in question has completed, i.e. will not process any further events.  Reaching a final state can generate an internal event, which in turn can allow other parts of the state machine to react to the fact that the compound state has "completed".
+A final state is a state in a [compound state](compound-state.html){:.glossary} that designates that the compound state in question has completed, i.e. will not process any further events. Reaching a final state can generate an internal event, which in turn can allow other parts of the state machine to react to the fact that the compound state has "completed".
 
-The "completion" of a state is wholly defined by the statechart itself.  
+The "completion" of a state is wholly defined by the statechart itself.
 
 ## Notation
 
-Final states are depicted using a solid filled circle, like the [initial state](initial-state.html){:.glossary} with an additional circle enclosing it.  Transitions from the final state must be [automatic], in other words they can not rely on events.
-
+Final states are depicted using a solid filled circle, like the [initial state](initial-state.html){:.glossary} with an additional circle enclosing it. Transitions from the final state must be [automatic], in other words they can not rely on events.
 
 ## SCXML
 
-In SCXML, the `<final>` element is used to define a final state.  When a final state is reached, the parent state generates a `done.state.<ID>` (where `<ID>` is the state of the parent state).  This allows the statechart to react to those events, effectively mimicing transitions upon the "completion" of states.
+In SCXML, the `<final>` element is used to define a final state. When a final state is reached, the parent state generates a `done.state.<ID>` (where `<ID>` is the state of the parent state). This allows the statechart to react to those events, effectively mimicing transitions upon the "completion" of states.
 
 ## XState
 
 In XState, final states are defined with `type: "final"`:
 
 ```js
 resolved: {
-  type: 'final';
+  type: 'final'
 }
 ```
 

_glossary/initial-state.md

@@ -1,6 +1,6 @@
 ---
 title: Initial state
-oneliner: The state which is entered when a state machine starts, or when a compound state is entered.
+oneliner: The state which is entered when a state machine starts, or when a compound state is entered
 primaryImage: initial-state.svg
 keywords:
   - default
@@ -21,45 +21,45 @@ aka:
     url: initial-state.html
 ---
 
-When a state machine starts, it starts by [entering](enter.html){:.glossary} the machine's **initial state**.  Likewise, when a [compound state](compound-state.html){:.glossary} is entered, _its_ **initial state** is also entered.  The initial state is not a separate state, but more like an indication of which state that the machine should _start_ in by default.
+When a state machine starts, it starts by [entering](enter.html){:.glossary} the machine's **initial state**. Likewise, when a [compound state](compound-state.html){:.glossary} is entered, _its_ **initial state** is also entered. The initial state is not a separate state, but more like an indication of which state that the machine should _start_ in by default.
 
-A [transition](transition.html){:.glossary} from a different state can target a substate of a compound state, thereby bypassing the state's initial state.  An initial state should be thought of as the default starting point of a compound state if a transition points directly to the compound state.
+A [transition](transition.html){:.glossary} from a different state can target a substate of a compound state, thereby bypassing the state's initial state. An initial state should be thought of as the default starting point of a compound state if a transition points directly to the compound state.
 
 ## Notation
 
-A state machine, or compound state's _initial_ state is specified by way a black circle with exactly one transition arrow to a sibling state that should be entered.  The black circle and arrow have no name, it is the target state that is called the 'initial' state.
+A state machine, or compound state's _initial_ state is specified by way a black circle with exactly one transition arrow to a sibling state that should be entered. The black circle and arrow have no name, it is the target state that is called the "initial" state.
 
 ![Black circle pointing to a state labeled A.  A is the initial state.](initial-state.svg)
 
 ## Usage
 
-Initial states are impossible to avoid, and follows from the definition of compound states:  For a compound state, whenever it becomes active, exactly one of its direct children are also active.  The "initial" state simply denotes _which_ of the child states become active when this happens.
+Initial states are impossible to avoid, and follows from the definition of compound states: For a compound state, whenever it becomes active, exactly one of its direct children are also active. The "initial" state simply denotes _which_ of the child states become active when this happens.
 
-Picking the right initial state can help decouple the various parts of the statechart.  It allows transitions to target the compound (parent) state instead of a child directly.  This allows collapsing the view of a compound state to see the bigger picture.
+Picking the right initial state can help decouple the various parts of the statechart. It allows transitions to target the compound (parent) state instead of a child directly. This allows collapsing the view of a compound state to see the bigger picture.
 
 ## SCXML
 
 In Statechart XML, the initial state is denoted in one of these ways:
 
-* using the `initial` attribute of the `<state>` element:
+- Using the `initial` attribute of the `<state>` element:
   ```xml
   <state id="P" initial="A">
-    <state id="B"/>
-    <state id="A"/>
+    <state id="B" />
+    <state id="A" />
   </state>
   ```
-* Using the `<initial>` element instead of a `<state>` element.  The `<initial>` element is identical to any other `<state>` except that it is an `<initial>` state.
+- Using the `<initial>` element instead of a `<state>` element. The `<initial>` element is identical to any other `<state>` except that it is an `<initial>` state.
   ```xml
   <state id="P">
-    <state id="B"/>
-    <initial id="A"/>
+    <state id="B" />
+    <initial id="A" />
   </state>
   ```
-* Implicitly, by relying on document order, the first `<state>` element will be the initial state:
+- Implicitly, by relying on document order, the first `<state>` element will be the initial state:
   ```xml
   <state id="P">
-    <state id="A"/>
-    <state id="B"/>
+    <state id="A" />
+    <state id="B" />
   </state>
   ```
 
@@ -77,4 +77,3 @@ In XState, a compound state must have the `initial` property declaring the key o
   }
 }
 ```
-

_glossary/internal-event.md

@@ -15,52 +15,49 @@ An internal event is a [generated event](generated-event.html){:.glossary} that
 
 ## Notation
 
-Internal events don't have specific names; the events themselves are generated automatically by the statechart.  However, sensing (reacting to) an event is done by way of transitions that specify events such as `entered(somestate)` or `in(somestate)`.
+Internal events don't have specific names; the events themselves are generated automatically by the statechart. However, sensing (reacting to) an event is done by way of transitions that specify events such as `entered(somestate)` or `in(somestate)`.
 
 ```
        in (somestate)
    ———————————————————————>
 ```
 
-
 ```
          entered (B)
    ———————————————————————>
 ```
 
 ## Usage
 
-When processing an external event, the statechart might go from state A to state B; this state change can "generate" new events such as
+When processing an external event, the statechart might go from state A to state B; this state change can "generate" new events such as:
 
-* We're no longer 'in' state A
-* State A was exited
-* State B was entered
-* We're now 'in' state B
+- We're no longer 'in' state A
+- State A was exited
+- State B was entered
+- We're now 'in' state B
 
-Immediately after a state transition happens (and importantly before the next external event is processed), the state machine checks if any transitions get "enabled" by any such internal events.  If there are any, then they are considered _triggered_ by an internal event, and those transitions happen immediately.
+Immediately after a state transition happens (and importantly before the next external event is processed), the state machine checks if any transitions get "enabled" by any such internal events. If there are any, then they are considered _triggered_ by an internal event, and those transitions happen immediately.
 
 When a statechart defines an activity or otherwise invokes a service, it can also declare the effect of the completion of the activity or service.
 
-
 ## SCXML
 
-In SCXML, the`In(state)` [conditional expression](https://www.w3.org/TR/scxml/#ConditionalExpressions) that can be used in guard functions.  Technically, this is not an event, but such a guard ends up being evaluated whenever a state transition happens.
+In SCXML, the`In(state)` [conditional expression](https://www.w3.org/TR/scxml/#ConditionalExpressions) that can be used in guard functions. Technically, this is not an event, but such a guard ends up being evaluated whenever a state transition happens.
 
 SCXML also [specifies a number of events](https://www.w3.org/TR/scxml/#errorsAndEvents) that are generated by the execution of a statechart:
 
-* a `done.state.<ID>` event is generated whenever a [compound state](compound-state.html){:.glossary} reaches its [final state](final-state.html){:.glossary}.
+- a `done.state.<ID>` event is generated whenever a [compound state](compound-state.html){:.glossary} reaches its [final state](final-state.html){:.glossary}.
 
-* a `done.invoke.<ID>` event is generated whenever an invoke completes.
+- a `done.invoke.<ID>` event is generated whenever an invoke completes.
 
-* various `error` events
+- various `error` events
 
 ## XState
 
-XState [natively supports](https://xstate.js.org/docs/guides/guards.html#in-state-guards) `in: 'state'` guards defined on the transition.  Technically, this is not its own event, but rather a side effect of a state transition.
+XState [natively supports](https://xstate.js.org/docs/guides/guards.html#in-state-guards) `in: 'state'` guards defined on the transition. Technically, this is not its own event, but rather a side effect of a state transition.
 
 XState also supports
 
-* `onDone` and `onError` event handlers for an [invoked service](https://xstate.js.org/docs/guides/communication.html#the-invoke-property).
-
-* a `done.state.<ID>` event is generated whenever a compound state reaches its [final state](https://xstate.js.org/docs/guides/final.html).
+- `onDone` and `onError` event handlers for an [invoked service](https://xstate.js.org/docs/guides/communication.html#the-invoke-property).
 
+- a `done.state.<ID>` event is generated whenever a compound state reaches its [final state](https://xstate.js.org/docs/guides/final.html).

_glossary/parallel-state.md

@@ -1,6 +1,6 @@
 ---
 title: Parallel State
-oneliner: a compound state that divides its substates into separate state machines that all get to be active at the same time
+oneliner: A compound state that divides its substates into separate state machines that all get to be active at the same time
 keywords:
   - orthogonal
   - orthogonal state
@@ -21,19 +21,19 @@ aka:
 
 # Parallel state
 
-_Also known as **Orthogonal state** and **And state**_ 
+_Also known as **Orthogonal state** and **And state**_
 
-A parallel state is a [state](state.html){:.glossary} that is divided into separate regions.  Each region contains more substates.  When a parallel state is entered, _each_ of the regions are also entered; their [initial states](initial-state.html){:.glossary} are entered and so on.  When a machine is _in_ a parallel state, _all_ of its regions are active.
+A parallel state is a [state](state.html){:.glossary} that is divided into separate regions. Each region contains more substates. When a parallel state is entered, _each_ of the regions are also entered; their [initial states](initial-state.html){:.glossary} are entered and so on. When a machine is _in_ a parallel state, _all_ of its regions are active.
 
 ![An example of a parallel state](parallel.svg)
 
-If the state above is entered, both B and D states are entered too.  As you can see the _flick_ event is handled by both B _and_ D.  If the _flick_ event happens, _both_ B and D get to "handle" the event, and the resulting state is C _and_ E.  Note: It is not possible to send an event specifically to a single region.
+If the state above is entered, both B and D states are entered too. As you can see the _flick_ event is handled by both B _and_ D. If the _flick_ event happens, _both_ B and D get to "handle" the event, and the resulting state is C _and_ E. Note: It is not possible to send an event specifically to a single region.
 
-If another _flick_ event happens E will transition back to D, while C will ignore the event, since C doesn't handle the event.  After 1 second, C will transition back to B, ready to handle the _flick_ event again.
+If another _flick_ event happens E will transition back to D, while C will ignore the event, since C doesn't handle the event. After 1 second, C will transition back to B, ready to handle the _flick_ event again.
 
 ## Notation
 
-A parallel state is like any other state, but it is subdivided into regions by way of straight, dashed lines.  Each such region can then include states.
+A parallel state is like any other state, but it is subdivided into regions by way of straight, dashed lines. Each such region can then include states.
 
 ![A state with four regions](parallel-notation.svg)
 
@@ -43,34 +43,34 @@ Each of those regions can hold their own sets of states
 
 Parallel states are used when the machine needs to combine several discrete behaviours at the same time.
 
-Without parallel states, modeling a set of four independent on/off switches (e.g. four independent toggle buttons with _on_ and _off_) would require 16 atomic states (`1on2on3on4on`, `1off2on3on4on`, `1on2off3on4on`, etc.) and 64 transitions (!) to be able to model all possible transitions.  Increasing the data model from four to five toggle buttons _doubles_ the number of states (32) _and_ transitions (128).
+Without parallel states, modeling a set of four independent on/off switches (e.g. four independent toggle buttons with _on_ and _off_) would require 16 atomic states (`1on2on3on4on`, `1off2on3on4on`, `1on2off3on4on`, etc.) and 64 transitions (!) to be able to model all possible transitions. Increasing the data model from four to five toggle buttons _doubles_ the number of states (32) _and_ transitions (128).
 
-With parallel states, modeling the same set of four independent on/off-switches requires only eight states (four _on_ states and four _off_ states) and eight transitions (each state transitions to its counterpart).  Increasing the data model from four to five toggle buttons increases the number of states and transitions by a fixed amount (two each).
+With parallel states, modeling the same set of four independent on/off-switches requires only eight states (four _on_ states and four _off_ states) and eight transitions (each state transitions to its counterpart). Increasing the data model from four to five toggle buttons increases the number of states and transitions by a fixed amount (two each).
 
-When events are completely independent of one another, parallel states shine.  But by using [in guards](guard.html){:.glossary} it is possible to coordinate the different regions, and have states in one region _wait_ until another region reaches a particular state or raises an event.  This makes it possible to model only partially independent behaviours using parallel states.
+When events are completely independent of one another, parallel states shine. But by using [in guards](guard.html){:.glossary} it is possible to coordinate the different regions, and have states in one region _wait_ until another region reaches a particular state or raises an event. This makes it possible to model only partially independent behaviours using parallel states.
 
 ## SCXML
 
-In Statechart XML, [the `<parallel>` element](https://www.w3.org/TR/scxml/#parallel) declares a parallel state.  It has more or less exactly the same set of attributes and elements as the `<state>` element, except it has no _initial_ or _final_ states.  The various _regions_ are defined by way of the direct child `<state>` elements.
+In Statechart XML, [the `<parallel>` element](https://www.w3.org/TR/scxml/#parallel) declares a parallel state. It has more or less exactly the same set of attributes and elements as the `<state>` element, except it has no _initial_ or _final_ states. The various _regions_ are defined by way of the direct child `<state>` elements.
 
 This is a parallel state with two _regions_. When `p` becomes active, so does `foo1` and `bar1`
 
-``` xml
+```xml
 <parallel id="p">
   <state id="region1">
-    <state id="foo1"/>
-    <state id="foo2"/>
+    <state id="foo1" />
+    <state id="foo2" />
   </state>
   <state id="region2">
-    <state id="bar1"/>
-    <state id="bar2"/>
+    <state id="bar1" />
+    <state id="bar2" />
   </state>
 </parallel>
 ```
 
 ## XState
 
-In XState, the state node must have `type: 'parallel'` (as of version 4.0) specified for a state to be marked as [a parallel state with regions](https://xstate.js.org/docs/guides/parallel.html).  A parallel state can not define an `initial` property, since all regions are entered simultaneously.
+In XState, the state node must have `type: 'parallel'` (as of version 4.0) specified for a state to be marked as [a parallel state with regions](https://xstate.js.org/docs/guides/parallel.html). A parallel state can not define an `initial` property, since all regions are entered simultaneously.
 
 ```
 p: {

_glossary/pseudostate.md

@@ -1,6 +1,6 @@
 ---
 title: Pseudostate
-oneliner: A set of types of state that are transient in nature. 
+oneliner: A set of types of state that are transient in nature
 breadcrumbs:
   - id: state
     name: State
@@ -12,5 +12,4 @@ aka:
 
 # Pseudostate
 
-Statechart concepts include both concrete types of state, such as _atomic states_ and _compound states_ but also non-concrete, or abstract types of state such as _initial state_ and _history state_.  A state machine can only be resting in such concrete states; pseudostates are therefore not _really_ states that the machine can be in, hence the prefix _pseudo-_.
-
+Statechart concepts include both concrete types of state, such as _atomic states_ and _compound states_ but also non-concrete, or abstract types of state such as _initial state_ and _history state_. A state machine can only be resting in such concrete states; pseudostates are therefore not _really_ states that the machine can be in, hence the prefix _pseudo-_.

_glossary/raised-event.md

@@ -11,29 +11,29 @@ date: 2019-05-08
 
 # Raised Event
 
-A raised event is a type of [generated event](generated-event.html){:.glossary} that is explicitly mentioned in the statechart.  A raised event is usually declared as an [action](action.html){:.glossary} assigned to the [entry](enter.html){:.glossary} or [exit](exit.html){:.glossary} of a state, or on a [transition](transition.html){:.glossary} between states.
+A raised event is a type of [generated event](generated-event.html){:.glossary} that is explicitly mentioned in the statechart. A raised event is usually declared as an [action](action.html){:.glossary} assigned to the [entry](enter.html){:.glossary} or [exit](exit.html){:.glossary} of a state, or on a [transition](transition.html){:.glossary} between states.
 
 ## Notation
 
-A raised event is usually shown in the same manner as actions, in other words, after a slash.  For example `entry / B`, which would mean that if this state was entered, the system would _generate_ the event `B` and process it as part of the current event, before processing any external events.
+A raised event is usually shown in the same manner as actions, in other words, after a slash. For example `entry / B`, which would mean that if this state was entered, the system would _generate_ the event `B` and process it as part of the current event, before processing any external events.
 
 ## Usage
 
-Raising events can be used as a way to coordinate different parts of a statechart.  For example. exiting one state can trigger another transition in a different part of the statechart.
+Raising events can be used as a way to coordinate different parts of a statechart. For example, exiting one state can trigger another transition in a different part of the statechart.
 
 ## SCXML
 
 In SCXML, an event can be raised using the `<raise>` element, wherever you can place so-called executable content:
 
 ```xml
 <onentry>
-  <raise event="B"/>
+  <raise event="B" />
 </onentry>
 ```
 
 ## XState
 
-In XState, an event can be raised by specifying the reserved action type `xstate.raise`
+In XState, an event can be raised by specifying the reserved action type `xstate.raise`.
 
 ```
 onEntry: {

_glossary/refine.md

@@ -1,6 +1,6 @@
 ---
 title: Refine
-oneliner: The conversion of an atomic state to a compound state by the addition of substates.
+oneliner: The conversion of an atomic state to a compound state by the addition of substates
 aka:
   - title: Specialise
     url: refine.html
@@ -11,11 +11,11 @@ aka:
 
 **Also known as _specialise_**
 
-Refinement of a state refers to the process of converting an [atomic state](atomic-state.html){:.glossary} to a [compound state](compound-state.html){:.glossary} by introducing substates.  This is done to change the behaviour of the state in question, typically by virtue of the substates handling (and therefore consuming) some, or all events before the refined state.
+Refinement of a state refers to the process of converting an [atomic state](atomic-state.html){:.glossary} to a [compound state](compound-state.html){:.glossary} by introducing substates. This is done to change the behaviour of the state in question, typically by virtue of the substates handling (and therefore consuming) some, or all events before the refined state.
 
 ## Example
 
-For example, a state A could react to the event ε1 by transitioning to the state B, and react to the event ε2 by transitioning to state C .  If it is desirable that the ε2 transition to state C should only be valid after, say, one second, the atomic state A can be converted to a compound state A by introducing a couple of substates.  The ε2 event from A to C could then be moved to one of those substates.
+For example, a state A could react to the event ε1 by transitioning to the state B, and react to the event ε2 by transitioning to state C . If it is desirable that the ε2 transition to state C should only be valid after, say, one second, the atomic state A can be converted to a compound state A by introducing a couple of substates. The ε2 event from A to C could then be moved to one of those substates.
 
 The act of introducing these substates to change A's behaviour, is called a _refining_, or _specialising_ state A.
 

_glossary/self-transition.md

@@ -1,6 +1,6 @@
 ---
 title: Self transition
-oneliner: A transition from a state back to itself.
+oneliner: A transition from a state back to itself
 breadcrumbs:
   - id: transition
     name: Transition
@@ -10,7 +10,7 @@ keywords:
 
 # Self transition
 
-A self transition is a [transition](transition.html){:.glossary} that starts and ends in the same state.  When a self transition is taken, the state in question is [exited](exit.html){:.glossary} and [entered](enter.html){:.glossary} again.
+A self transition is a [transition](transition.html){:.glossary} that starts and ends in the same state. When a self transition is taken, the state in question is [exited](exit.html){:.glossary} and [entered](enter.html){:.glossary} again.
 
 ## Notation
 
@@ -20,19 +20,19 @@ A self transition is depicted as a segment of a circle, here with the event _aga
 
 ## Usage
 
-Self transitions are commonly used to "restart" the current state, causing the exit actions to happen, followed by the entry actions.  This also resets the timer for how long the machine has been in the state, meaning that [delayed transitions](delayed-transition.html){:.glossary} start counting from 0 again.
+Self transitions are commonly used to "restart" the current state, causing the exit actions to happen, followed by the entry actions. This also resets the timer for how long the machine has been in the state, meaning that [delayed transitions](delayed-transition.html){:.glossary} start counting from 0 again.
 
-It is important to note that self transitions (or transitions to own child states) will in fact _exit_ the state in which the transition starts.  This is important to keep in mind and can be a source of confusion, since it leads to the _exit_ and _entry_ actions of the state to be re-executed.
+It is important to note that self transitions (or transitions to own child states) will in fact _exit_ the state in which the transition starts. This is important to keep in mind and can be a source of confusion, since it leads to the _exit_ and _entry_ actions of the state to be re-executed.
 
-For [compound states](compound-state.html){:.glossary} this means that all substates are exited, and its [initial state](initial-state.html){:.glossary} is entered.  This effectively restarts the compound state itself.
+For [compound states](compound-state.html){:.glossary} this means that all substates are exited, and its [initial state](initial-state.html){:.glossary} is entered. This effectively restarts the compound state itself.
 
 ## SCXML
 
 In Statechart XML, a self transition uses the standard `<transition>` syntax, with the target the same as its containing state.
 
 ```xml
 <state id="important_state">
-  <transition event="again" target="important_state"/>
+  <transition event="again" target="important_state" />
 </state>
 ```
 

_glossary/state.md

@@ -5,63 +5,62 @@ oneliner: A particular behaviour of a state machine
 
 # State
 
-A state in a state machine describes a particular behaviour of the machine.  When we say that a machine is "in" a state, it means that the machine behaves in the way that state describes.
+A state in a state machine describes a particular behaviour of the machine. When we say that a machine is "in" a state, it means that the machine behaves in the way that state describes.
 
-The behaviour of a state is defined as how the state reacts to [events](event.html){:.glossary}.  Each state can specify a number of events that it "understands", and specifies, for each event, any number of [transitions](transition.html){:.glossary} that could be taken, if that event happens.  A state also describes a set of [actions](action.html){:.glossary} to execute when the state is entered or exited, and in some implementations, [activities](activity.html){:.glossary} that should be happening for the entire duration of time that the machine is _in_ the state.
+The behaviour of a state is defined as how the state reacts to [events](event.html){:.glossary}. Each state can specify a number of events that it "understands", and specifies, for each event, any number of [transitions](transition.html){:.glossary} that could be taken, if that event happens. A state also describes a set of [actions](action.html){:.glossary} to execute when the state is entered or exited, and in some implementations, [activities](activity.html){:.glossary} that should be happening for the entire duration of time that the machine is _in_ the state.
 
 A state usually has a name, but some systems allow for anonymous states.
 
-When a state machine is _executed_, it [enters](enter.html){:.glossary} the [initial state](initial-state.html){:.glossary}, and adopts the behaviour associated with that state.  As the machine handles events, it transitions to other states, thus changing the behaviour of the machine over time.
-
+When a state machine is _executed_, it [enters](enter.html){:.glossary} the [initial state](initial-state.html){:.glossary}, and adopts the behaviour associated with that state. As the machine handles events, it transitions to other states, thus changing the behaviour of the machine over time.
 
 ## States in statcharts
 
 There are a few special types of states in statecharts:
 
-* [Atomic](atomic-state.html){:.glossary} (or simple) states, are states that have no substates.
-* [Compound](compound-state.html){:.glossary} (or composite) states, are states that have one or more substates.  The substates can be said to be a _refinement_ of their parent state.  Coversely, the parent state can be said to provide a _default behaviour_ of the substates.
-* [Parallel](parallel-state.html){:.glossary} (or orthogonal) states, are states that (like a compound states) have substates, but where the child states are grouped into orthogonal regions, and those regions are all active simultaneously.
+- [Atomic](atomic-state.html){:.glossary} (or simple) states, are states that have no substates.
+- [Compound](compound-state.html){:.glossary} (or composite) states, are states that have one or more substates. The substates can be said to be a _refinement_ of their parent state. Conversly, the parent state can be said to provide a _default behaviour_ of the substates.
+- [Parallel](parallel-state.html){:.glossary} (or orthogonal) states, are states that (like compound states) have substates, but where the child states are grouped into orthogonal regions, and those regions are all active simultaneously.
 
 ## Hierarchy
 
-These constructs allow statecharts to be hierarchically organized.  When a compound state is active (when the machine is _in_ that state), exactly one of its child states are also active.  When a parallel state is active, by definition, all of the child states (called regions) are also active.  This implies that in a hierarchically organized statechart, many states can be active at any point in time.  Specifically, for each active atomic state, all the compound and parallel parents are also deemed to be "active".  When an event happens, the "deepest" of the states get to handle the event, pre-empting the behaviour of the parent states that contain it.
+These constructs allow statecharts to be hierarchically organized. When a compound state is active (when the machine is _in_ that state), exactly one of its child states is also active. When a parallel state is active, by definition, all of the child states (called regions) are also active. This implies that in a hierarchically organized statechart, many states can be active at any point in time. Specifically, for each active atomic state, all the compound and parallel parents are also deemed to be "active". When an event happens, the "deepest" of the states get to handle the event, pre-empting the behaviour of the parent states that contain it.
 
 ## Notation
 
-A state is generally depicted as a rounded box, with the name of the state centered at the top of the box, with a horizontal line sparating the name of the state from the actions and activities.  The original statechart paper did not have these lines, they come from the UML Statechart standard.  It is common to drop this line in states that have no substates and no actions.
+A state is generally depicted as a rounded box, with the name of the state centered at the top of the box, with a horizontal line sparating the name of the state from the actions and activities. The original statechart paper did not have these lines, they come from the UML Statechart standard. It is common to drop this line in states that have no substates and no actions.
 
-Transitions _from_ this state are depicted as curvy lines pointing away.  Transitions _to_ this state are depicted as curved lines that point to this state.
+Transitions _from_ this state are depicted as curvy lines pointing away. Transitions _to_ this state are depicted as curved lines that point to this state.
 
-Entry and Exit actions are written in text form inside the state.
+Entry and exit actions are written in text form inside the state.
 
 ![A rounded rectangle with a horizontal line, on top of which the word "On", and below which the words "entry / turn on"](state.svg)
 
 ## SCXML
 
-In SCXML, a state is defined by the `<state>` element, with the name of the state in its `id` attribute.  An empty state:
+In SCXML, a state is defined by the `<state>` element, with the name of the state in its `id` attribute. An empty state:
 
-``` xml
-<state id="my_state"/>
+```xml
+<state id="my_state" />
 ```
 
 The child elements of the `<state>` include entry and exit actions, transitions, along with substates:
 
-``` xml
+```xml
 <state id="my_state">
   <onentry>
     <script>do_something()</script>
   </onentry>
-  <transition event="some_event" target="some_other_state"/>
+  <transition event="some_event" target="some_other_state" />
   <state id="my_substate">
-    <transition event="some_event" target="my_other_substate"/>
+    <transition event="some_event" target="my_other_substate" />
   </state>
-  <state id="my_other_substate"/>
+  <state id="my_other_substate" />
 </state>
 ```
 
 ## XState
 
-In XState, a state node is specified as a named object in the `states` property of a state machine or compound state node.  The key becomes the name of the state node (and is used to construct the state node's ID), and the object defines the state's behaviour.
+In XState, a state node is specified as a named object in the `states` property of a state machine or compound state node. The key becomes the name of the state node (and is used to construct the state node's ID), and the object defines the state's behaviour.
 
 Here's an empty state called `my_state`:
 
@@ -100,9 +99,9 @@ Here's the `my_state` with an action, transitions, and substates:
 
 In SCION Core, a state is described by an object with an `id` property, denoting the identifier of the state.
 
-``` javascript
+```javascript
 {
-  id: 'my_state';
+  id: 'my_state'
 }
 ```
 

_glossary/transition.md

@@ -1,45 +1,45 @@
 ---
 title: Transition
-oneliner: The instantaneous transfer from one state to another.
+oneliner: The instantaneous transfer from one state to another
 ---
 
 # Transition
 
-In an executing state machine, a transition is the instantaneous transfer from one [state](state.html){:.glossary} to another.  In a state machine, a transition tells us what happens when an [event](event.html){:.glossary} occurs.
+In an executing state machine, a transition is the instantaneous transfer from one [state](state.html){:.glossary} to another. In a state machine, a transition tells us what happens when an [event](event.html){:.glossary} occurs.
 
-When an event happens, the currently active state(s) are inspected, looking for an outbound transition that could be triggered by the event.  If it is [guarded](guard.html){:.glossary}, the guard is checked, and the machine keeps looking for a transition.  At last, if a transition is found, it is then _executed_ by [exiting](exit.html){:.glossary} the state in question, and [entering](enter.html){:.glossary} the state that the transition points to.
+When an event happens, the currently active state(s) are inspected, looking for an outbound transition that could be triggered by the event. If it is [guarded](guard.html){:.glossary}, the guard is checked, and the machine keeps looking for a transition. At last, if a transition is found, it is then _executed_ by [exiting](exit.html){:.glossary} the state in question, and [entering](enter.html){:.glossary} the state that the transition points to.
 
 A [self transition](self-transition.html){:.glossary} is a transition that goes from and to the same state.
 
 A [local transition](local-transition.html){:.glossary} is a transition that does not exit the source state, but the target state _must_ be a substate of the source state.
 
-An [automatic transition](automatic-transition.html){:.glossary} is a transition that is not tied to any particular event, but rather tries to fire at all times.  Automatic transitions are usually guarded.
+An [automatic transition](automatic-transition.html){:.glossary} is a transition that is not tied to any particular event, but rather tries to fire at all times. Automatic transitions are usually guarded.
 
 A transition can define [actions](action.html){:.glossary} that will be executed whenever that transition is executed.
 
 ## Notation
 
-A transition is depicted as a curved arrow.  The name of the event that triggers the transition is written close by, perhaps on top of the arrow.
+A transition is depicted as a curved arrow. The name of the event that triggers the transition is written close by, perhaps on top of the arrow.
 
 ![A transition, for the event _my_event_](event-arrow.svg)
 
 The transition always sits between two distinct states
 
 ![A transition from _somestate_ to _otherstate_ given the _my_event_ event](event.svg)
 
-The state that the arrow points _from_ is the state in which the event in question is handled.  The state that the arrow points _to_  is the state that the state machine ends up in, if the transition is executed.
+The state that the arrow points _from_ is the state in which the event in question is handled. The state that the arrow points _to_ is the state that the state machine ends up in, if the transition is executed.
 
-A transition can have multiple targets, in case of targetting different regions of a [parallel state](parallel-state.html){:.glossary}
+A transition can have multiple targets, in case of targetting different regions of a [parallel state](parallel-state.html){:.glossary}.
 
 ## Usage
 
-Alongside _states_, transitions are the main ingredient of state machines and statecharts.  A single transition defines how the machine might react to a particular event in case the machine is in a particular state.  The combination of the different states and their transition together make up the statechart's behaviour.
+Alongside _states_, transitions are the main ingredient of state machines and statecharts. A single transition defines how the machine might react to a particular event in case the machine is in a particular state. The combination of the different states and their transition together make up the statechart's behaviour.
 
 Transitions are primarily used to move the machine between states, possibly executing _transition actions_ if they are defined.
 
 ## SCXML
 
-In Statechart XML, a transition is a `<transition>` element nested inside the `<state>` element to which it applies.  The `target` attribute identifies the state to which it points, while `cond` is used for the guard.
+In Statechart XML, a transition is a `<transition>` element nested inside the `<state>` element to which it applies. The `target` attribute identifies the state to which it points, while `cond` is used for the guard.
 
 ```xml
 <state id="somestate">
@@ -48,7 +48,7 @@ In Statechart XML, a transition is a `<transition>` element nested inside the `<
 <state id="otherstate" />
 ```
 
-Multiple transitions for the same event are defined by defining several transitions for the same event.  The transitions are inspected in _document order_:
+Multiple transitions for the same event are defined by defining several transitions for the same event. The transitions are inspected in _document order_:
 
 ```xml
 <state id="somestate">
@@ -61,7 +61,7 @@ Multiple transitions for the same event are defined by defining several transiti
 
 ## XState
 
-In XState, a transition is defined using [the *on* property](https://xstate.js.org/docs/guides/transitions.html) of a state.  The key is the event in question, and the value is the name of the target state:
+In XState, a transition is defined using [the _on_ property](https://xstate.js.org/docs/guides/transitions.html) of a state. The key is the event in question, and the value is the name of the target state:
 
 ```json
 "somestate": {
@@ -72,7 +72,7 @@ In XState, a transition is defined using [the *on* property](https://xstate.js.o
 "otherstate": {}
 ```
 
-It is also possible to define an array of transitions for any given event.  Each element in the array defines a transition to be handled by that event, and they are inspected in array order:
+It is also possible to define an array of transitions for any given event. Each element in the array defines a transition to be handled by that event, and they are inspected in array order:
 
 ```json
 "somestate": {
@@ -86,4 +86,3 @@ It is also possible to define an array of transitions for any given event.  Each
 "otherstate": {},
 "thirdstate": {}
 ```
-