authoring/Scenario.md

@@ -60,14 +60,14 @@ The optional **`<bounds>`** node, with its **`<x>`**, **`<y>`**, **`<width>`** a
 Last but not least, the optional **`<backgroundColour>`** allows determining the background colour of the blank stage. The background colour will default to **Black** if the property is not provided. Have a look at the section about [common colour properties](bootstrapping/common/colour) for more information about how to define a colour in TULIP scenarios.
 
 ## Macros Tag
-Macros play a crucial role in object templating. In the [Getting started](Getting-started) section we briefly mentioned the concept of templating. [Templates](bootstrapping/templates) can be compared to a blueprint or a mould to produce a number of similar objects, sharing some but not all properties with their siblings. Values for the differentiating properties are generally provided by individual **template variables**, identified by the **`$`** (dollar) sign and a pair of enclosing **{}** (brackets), or more complex expressions involving multiple variables. If an expression is being used in multiple locations, it is advisable to define the expression only once in the form of a **`<macro>`** and replace each occurrence of the given expression with the corresponding macro. Macros use a notation for their placeholder similar to template variables. Macro placeholders are identified by the **`%`** (percent) sign and a pair of enclosing **{}** (brackets). The following example defines a macro named **CriterionStartAngle**.
+Macros play a crucial role in object templating. In the [Getting started](Getting-started) section we briefly mentioned the concept of templating. [Templates](authoring/Templates) can be compared to a blueprint or a mould to produce a number of similar objects, sharing some but not all properties with their siblings. Values for the differentiating properties are generally provided by individual **template variables**, identified by the **`$`** (dollar) sign and a pair of enclosing **{}** (brackets), or more complex expressions involving multiple variables. If an expression is being used in multiple locations, it is advisable to define the expression only once in the form of a **`<macro>`** and replace each occurrence of the given expression with the corresponding macro. Macros use a notation for their placeholder similar to template variables. Macro placeholders are identified by the **`%`** (percent) sign and a pair of enclosing **{}** (brackets). The following example defines a macro named **CriterionStartAngle**.
 
 > \<macro identifier="CriterionStartAngle"\>${CriterionIndex} * (360 / ${NumberOfCriteria})\</macro\> 
 
 The macro defines an expression using two templating variables,i.e. **${CriterionIndex}** and **${NumberOfCriteria}**. It is worth mentioning that expressions defined in macros are replaced as is, i.e. they are not pre-evaluated but are instead evaluated *in situ*. You may compare this behaviour to a Find & Replace operation taking place during runtime, replacing every occurrence of the **%{CriterionStartAngle}** placeholder with the content of the corresponding **`<macro>`** tag.
 
 ## Template Tag
-[Templates](bootstrapping/templates) will be discussed in detail in a dedicated [templating](bootstrapping/templates) section, so we won't go into much detail here. Suffice it to say that templates are the actual workhorse of most scenarios implemented with TULIP. Templates are essential for dynamic scenarios, relying on data provided from external systems to populate individual objects.
+[Templates](authoring/Templates) will be discussed in detail in a dedicated [templating](authoring/Templates) section, so we won't go into much detail here. Suffice it to say that templates are the actual workhorse of most scenarios implemented with TULIP. Templates are essential for dynamic scenarios, relying on data provided from external systems to populate individual objects.
 
 ## Object Tag
 The **`<objects>`** tag groups all *explicit* tangible object definitions. By explicit object definitions we understand objects which are completely and unequivocally defined and can be instantiated as is. The opposite form of object definitions are those objects requiring data from external systems, which should be defined in the previously introduced [templates](/nui/tulip/-/wikis/bootstrapping/templates) section. It is important to note though, that independently from whether an object is declared in the **`templates`** or **`objects`** section, they always share the same properties. The difference resides in what you're allowed to use to get the respective values from. If defined inside the **`templates`** sections, you're allowed the use variables to provided property values, which you're not allowed to do inside **`objects`** sections. Apart from that, declaring objects in both sections is identical. Each object definition is encapsulated in its own `<object>` tag. Tangible objects are the functional software representation of the physical object manipulated by the user and will be called hereafter **Widgets**. TULIP comes with a number of predefined widgets implementing different behaviors, however, all widgets have a set of basic properties which we'd like to introduce in the [following section](/authoring/objects).