anchor.diff:  
   |[[content-based-router-topic-regex]]<<content-based-router-topic-regex, `topic.regex`>>
   |
  -|An optional regular expression for specifying the topic(s) this transformation should be applied to. Records on any topic whose name does not match the given expression are passed on as-is.
  +|An optional regular expression that evaluates the name of the destination topic for an event to determine whether to apply the condition logic. 
  +If the name of the destination topic matches the value in `topic.regex`, the transformation applies the condition logic before it passes the event to the topic.
  +If the name of the topic does not match the value in `topic.regex`, the SMT passes the event to the topic unmodified.
   
   |[[content-based-router-language]]<<content-based-router-language, `language`>>
   |
  -|The language in which the expression is written. Must begin with `jsr223.`, e.g. `jsr223.groovy`, or `jsr223.graal.js`. Currently, only bootstrapping via the https://jcp.org/en/jsr/detail?id=223[JSR 223 API] ("Scripting for the Java (TM) Platform") is supported.
  +|The language in which the expression is written. Must begin with `jsr223.`, e.g. `jsr223.groovy`, or `jsr223.graal.js`. {prodname} supports bootstrapping through the https://jcp.org/en/jsr/detail?id=223[JSR 223 API ("Scripting for the Java (TM) Platform")] only.
   
   |[[content-based-router-topic-expression]]<<content-based-router-topic-expression, `topic.expression`>>
   |
  -|The expression evaluated for every message. Must evaluate to a `String` value where a result of non-null will re-route the message to a new topic, and a `null` value will keep it in the original topic.
  +|The expression to be evaluated for every message. Must evaluate to a `String` value where a result of non-null reroutes the message to a new topic, and a `null` value routes the message to the default topic.
   
   |[[content-based-router-null-handling-mode]]<<content-based-router-null-handling-mode, `null.handling.mode`>>
   |`keep`
  -|Prescribes how the transformation should handle `null` (tombstone) messages. The options are: `keep` (the default) to pass the message through, `drop` to remove the messages completely, or `evaluate` to run the message through the topic expression.
  +a|Specifies how the transformation handles `null` (tombstone) messages. You can specify one of the following options: 
   
  +`keep`:: (Default) Pass the messages through.
  +`drop`:: Remove the messages completely.
  +`evaluate`:: Apply the condition logic to the messages.
   |===
  
positive.code: [id="content-based-routing"]
  = Content-Based Routing
  
  :toc:
  :toc-placement: macro
  
negative.code: ...
  ----
  
  The preceding example specifies the use of the `Groovy` expression language.
  The regular expression reroutes all update (`u`) records to the `updates` topic, and routes other records to the default topic.
  
  [IMPORTANT]
  ====
  Although the {prodname} package includes the JSR 223 API, which provides support for scripting languages that integrate with JSR 223, by default, {prodname} cannot interpret scripts from these languages.
  To use an expression language, you must download the JSR-223 script engine JAR for the language, and add the JAR to your classpath, along any other JAR files used by the language implementation.
  For Groovy 3, you can download the JAR from https://groovy-lang.org/. For GraalVM JavaScript, the JAR is available at https://github.com/graalvm/graaljs.   
  
  Typically, you add the language JAR to the directory that contains the {prodname} connector JAR files, which is the directory that is referenced in the `plugin.path` configuration property that is set for the Kafka Connect plugin. 
  If you install the script engine JAR to a different directory, you must add that directory to the list in the `plugin.path` property. 
  ====
  
  // Type: concept
  // ModuleID: variables-for-use-in-content-based-routing-expressions
  == Variables for use in content-based routing expressions
  
  {prodname} binds certain variables into the evaluation context for the SMT.
  When you create expressions to specify conditions to control the routing destination, 
  the SMT can look up and interpret the values of these variables to evaluate conditions in an expression. 
  
  The following table lists the variables that {prodname} binds into the evaluation context for the content-based routing SMT:
  
  .Content-based routing expression variables
  [options="header"]
  |=======================
  |Name |Description |Type
  |`key`   |A key of the message. |`org.apache.kafka.connect.data.Struct`
  |`value` |A value of the message. |`org.apache.kafka.connect.data.Struct`
  |`keySchema` |Schema of the message key.|`org.apache.kafka.connect.data.Schema`
  |`valueSchema`|Schema of the message value.| `org.apache.kafka.connect.data.Schema`
  |`topic`|Name of the target topic.| String
  |`headers`
  a|A Java map of message headers. The key field is the header name. 
  The `headers` variable exposes the following properties:
  
  * `value` (of type `Object`) 
  
  * `schema` (of type `org.apache.kafka.connect.data.Schema`)
  
  | `java.util.Map<String, io.debezium.transforms.scripting.RecordHeader>`
  |=======================
  
  An expression can invoke arbitrary methods on its variables. 
  Expressions should resolve to a Boolean value that determines how the SMT dispositions the message.
  When the routing condition in an expression evaluates to `true`, the message is retained. 
  When the routing condition evaluates to `false`, the message is removed.
  
  Expressions should not result in any side-effects. That is, they should not modify any variables that they pass.
  
  // Type: reference
  // ModuleID: configuration-of-content-based-routing-conditions-for-other-scripting-languages
  // Title: Configuration of content-based routing conditions for other scripting languages 
  == Language specifics
  
  The way that you express content-based routing conditions depends on the scripting language that you use.
  For example, as shown in {link-prefix}:{link-content-based-routing}#example-of-configuring-content-based-routing-conditions[], when you use `Groovy` as the expression language, 
  the following expression reroutes all update (`u`) records to the `updates` topic, while routing other records to the default topic:
  
  [source,groovy]
  ----
  value.op == 'u' ? 'updates' : null
  ----
  
  Other languages use different methods to express the same condition.
  
  [TIP]
  ====
  The {prodname} MongoDB connector emits the `after` and `patch` fields as serialized JSON documents rather than as structures.
  To use the ContentBasedRouting SMT with the MongoDB connector, you must first unwind the fields by applying the {link-prefix}:{link-mongodb-event-flattening}[`ExtractNewDocumentState`] SMT.
  
  You could also take the approach of using a JSON parser within the expression.
  For example, if you use Groovy as the expression language, add the `groovy-json` artifact to the classpath, and then add an expression such as `(new groovy.json.JsonSlurper()).parseText(value.after).last_name == 'Kretchmar'`.
  ====
  
  .Javascript
  When you use JavaScript as the expression language, you can call the `Struct#get()` method to specify the content-based routing condition, as in the following example:
  
  [source,javascript]
  ----
  value.get('op') == 'u' ? 'updates' : null
  ----
  
  .Javascript with Graal.js
  When you create coentent-based routing conditions by using JavaScript with Graal.js, you use an approach that is similar to the one use with Groovy.
  For example:
  
  [source,javascript]
  ----
  value.op == 'u' ? 'updates' : null
  ----
  
  
  // Type: reference
  // ModuleID: options-for-configuring-the-content-based-routing-transformation
  // Title: Options for configuring the content-based routing transformation
  [[content-based-router-configuration-options]]
  == Configuration options
  [cols="30%a,25%a,45%a"]
  