Update Tenzir Node documentation

Author: tenzir-bot

src/content/docs/reference/functions.mdx

@@ -746,8 +746,9 @@ TODO: the following functions still need to be documented:
 
 */}
 
-Functions appear in [expressions](/reference/language/expressions) and take positional
-and/or named arguments, producing a value as a result of their computation.
+Functions appear in [expressions](/explanations/language/expressions) and take
+positional and/or named arguments, producing a value as a result of their
+computation.
 
 Function signatures have the following notation:
 
@@ -760,18 +761,6 @@ f(arg1:<type>, arg2=<type>, [arg3=type]) -> <type>
 - `[arg=type]`: optional (named) argument
 - `-> <type>`: function return type
 
-TQL features the [uniform function call syntax
-(UFCS)](https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax), which
-allows you to interchangeably call a function with at least one argument either
-as _free function_ or _method_. For example, `length(str)` and `str.length()`
-resolve to the identical function call. The latter syntax is particularly
-suitable for function chaining, e.g., `x.f().g().h()` reads left-to-right as
-"start with `x`, apply `f()`, then `g()` and then `h()`," compared to
-`h(g(f(x)))`, which reads "inside out."
-
-Throughout our documentation, we use the free function style in the synopsis
-but often resort to the method style when it is more idiomatic.
-
 ## Aggregation
 
 <CardGrid>

src/content/docs/reference/functions/match_regex.md

@@ -58,7 +58,3 @@ output = input.match_regex("^[E|e]xample[!]?$")
 {input: "example!", output: true}
 {input: "example?", output: false}
 ```
-
-## See Also
-
-[String Operations](/reference/language/expressions#string-operations)

src/content/docs/reference/operators/set.md

@@ -21,13 +21,13 @@ yet.
 Within assignments, the `move` keyword in front of a field causes a field to be
 removed from the input after evaluation.
 
-:::tip
+:::tip[Implied operator]
 The `set` operator is implied whenever a direct assignment is written. We
 recommend to use the implicit version. For example, use `test = 42` instead of
 `set test=42`.
 
-Read our [language reference](/reference/language/statements#assignment) for a more
-detailed description.
+Read our [language documentation](/explanations/language/statements/#assignment)
+for a more detailed description.
 :::
 
 ## Examples

src/content/docs/reference/operators/sigma.md

@@ -21,14 +21,15 @@ operator discards all events that do not match the provided rules.
 <summary> Transpilation Process </summary>
 
 For each rule, the operator transpiles the YAML into an
-[expression](/reference/language/expressions) and instantiates a [`where`](/reference/operators/where)
-operator, followed by assignments to generate an output. Here's how the
-transpilation works. The Sigma rule YAML format requires a `detection` attribute
-that includes a map of named sub-expression called *search identifiers*. In
-addition, `detection` must include a final `condition` that combines search
-identifiers using boolean algebra (AND, OR, and NOT) or syntactic sugar to
-reference groups of search expressions, e.g., using the `1/all of *` or plain
-wildcard syntax. Consider the following `detection` embedded in a rule:
+[expression](/explanations/language/expressions) and instantiates a
+[`where`](/reference/operators/where) operator, followed by assignments to
+generate an output. Here's how the transpilation works. The Sigma rule YAML
+format requires a `detection` attribute that includes a map of named
+sub-expression called *search identifiers*. In addition, `detection` must
+include a final `condition` that combines search identifiers using boolean
+algebra (AND, OR, and NOT) or syntactic sugar to reference groups of search
+expressions, e.g., using the `1/all of *` or plain wildcard syntax. Consider the
+following `detection` embedded in a rule:
 
 ```yaml
 detection: