Three to Two Merge Use Cases
This section describes common use cases where converting a three-way merge result into a two-way simplified representation is the preferred approach.
Use Case 1: Editorial Round-Trip Through Document Editors
When a document needs to be reviewed and approved in a document editing tool (such as oXygen XML Author or Adobe InDesign), the three-way DeltaV2 format is too complex for the editor to display natively. The Three-to-Two Merge produces a simplified result that the editor can render using its built-in change-tracking UI.
Recommended result type: ALL_CHANGES with TwoWayResultFormat=OXYGEN_TRACK_CHANGES
Use Case 2: Reviewer-Friendly Change Presentation
When presenting merged changes to a non-technical reviewer, the simplified two-way format is easier to understand than the full three-way DeltaV2. Non-conflicting changes that were made by one editor are shown as accepted; only genuine conflicts appear as pending tracked changes.
Recommended result type: CONFLICTING_CHANGES
Use Case 3: Auto-Resolution of Non-Conflicting Changes
In automated publishing workflows, non-conflicting changes (where one author made a change and the other did not) can be auto-accepted, leaving only genuine conflicts for human review.
Recommended result type: RULE_PROCESSED_DELTAV2 (concurrent) or CONFLICTING_CHANGES (concurrent3)
Use Case 4: Remote Branch Integration
In a version-control-style workflow, the 'their changes' mode presents changes from a remote branch while auto-resolving local changes that do not conflict. This mirrors the familiar git merge mental model.
Recommended result type: THEIR_CHANGES
Choosing the Right Result Type
|
Scenario |
Recommended ResultType |
|---|---|
|
Show all tracked changes for review |
|
|
Show only conflicts; accept everything else |
|
|
Integrate remote branch changes |
|
|
oXygen track-changes round-trip |
|
|
Programmatic auto-resolution |
|