The Debezium community documentation has always been authored in AsciiDoc. Beginning next year the Red Hat product documentation is migrating to DITA. To facilitate a smooth migration, the following changes are required in the current AsciiDoc files:

• Reformat content to remove third-level (and higher) topic headings. This implies a great deal of restructuring. (Pending testing, it's unclear whether all of these must be removed, or whether the current documentation toolchain can do some of this processing). This might not be necessary. After Nebel splits source files, the resulting module files no longer contain third-level headings. However, review of files in the /partials directory is needed to determine whether any block titles they contain are valid.
• Remove in-line links and replace them with entries within an Additional resources section.
• Remove text from Additional resources list entries. Only links are allowed.
• Remove hard line breaks (the are present mostly in properties descriptions within table cells).
• Insert blank line after topic title headings.
• Remove block titles before admonition blocks (and most everywhere else, but that's where most of the illegal instances occur).
• Remove [discrete] attributes before headings.
• Add short description introductory sentence for each content chunk that's designated for use as a downstream topic module. 
• Add alt text to image tags (image::[]) as needed.

Other issues are likely to present themselves, but that represents the majority of the known required fixes.

Use of hard line breaks

Regarding the use of hard line breaks, looking the current docs, some (many? most?) of the hard breaks are extraneous. But in some contexts they serve a useful purpose.
For example, to provide the configuration properties for the MariaDB and MySQL connectors, a shared file presents the properties in a definition list. The two connectors mostly use the same properties, but there are some variations, so some conditionalization was required to shared the list.
Implementing conditionalization in a table is challenging, and it's much easier to do it in the context of a description list.
Each entry in the list provides the following information:

• Property name
• Default value
• Description
• Possible values

[id="
Unknown macro: {context}
-property-bigint-unsigned-handling-mode"]
xref:{context}-property-bigint-unsigned-handling-mode[`bigint.unsigned.handling.mode`]::
+
Default value: `long` +
Specifies how the connector represents BIGINT UNSIGNED columns in change events.
Set one of the following options:

`long`::: Uses Java `long` data types to represent BIGINT UNSIGNED column values.
Although the `long` type does not offer the greatest precision, it is easy implement in most consumers.
In most environments, this is the preferred setting.

`precise`::: Uses `java.math.BigDecimal` data types to represent values.
The connector uses the Kafka Connect `org.apache.kafka.connect.data.Decimal` data type to represent values in encoded binary format.
Set this option if the connector typically works with values larger than 2^63.
The `long` data type cannot convey values of that size.

Here, a hard break after the Default value helps to set off that information on its own line, improving scannability and readability.

Alternate markup, such as the use of list continuations vs. hard breaks can accomplish a similar, yet "legal" result for these entries. These look similar, because they both use the + character, but continuations, which just tie together paragraphs within a block don't place a space before the character. In some cases, it might be possible to dispense with the extra markup altogether. For example:

property name:: 
Description

Default value::: VALUE

option1::: blah blah blah

option2::: blah blah blah

property name 2::
Description

Default value::: VALUE

option1::: blah blah blah

option2::: blah blah blah

This renders correctly as:

property name
   Description
   Default value 

      VALUE
   option1
      blah blah blah
   option2
      blah blah blah 

property name 2
   Description
   Default value 

     VALUE

   option1
      blah blah blah
   option2
      blah blah blah

Any "corrections" implemented must be applied to the upstream files, so that they are not overwritten by successive releases.

Over time, the migration process should become easier and smoother as I incrementally weed out constructions that block conversion.