Guide to DeltaXML Merge Result Formats and Types

1. Introduction

The Merge 6.0 release has introduced a new merge type called Sequential Merge. The merge product now has three different merge types: ConcurrentMerge, SequentialMerge and ThreeWayMerge.

2. Table of Merge Types and Result Types

Result TypeConcurrent MergeThree Way MergeSequential Merge
Rule Processed DeltaV2
Analyzed DeltaV2
Simplified DeltaV2
Simplified Rule Processed DeltaV2
Two Way Result
Rule Processed Two Way Result
Two Way Oxygen Track Changes
Three Way Oxygen Track Changes

3. Result Formats and Result types

The following table summarizes the result format differences and offers advice as to which may be appropriate for different user requirements and use-cases.

deltaV2rule processed deltaV2simplified deltatwo way results
Number of inputs3+3+3+3
Extract all inputs
Supports nested change
Use with editor accept/reject
Use with DeltaXML oXygen plugin
Suitability for automated processing✔✔✔✔✔✔✔✔✔✔✔
Suitability for manual resolution✔✔✔✔✔

4. Considerations

4.1. Number of inputs

The ConcurrentMerge class is designed as n-way merge system and therefore supports an unlimited number of input XML files or trees. The use of a common ancestor to guide the alignment process in addition to two versions or branches being merged means that a minimum of three XML inputs are required.

The SequentialMerge class is also designed as a n-way merge system and therefore supports an unlimited number of input XML files or trees. SequentialMerge requires a minimum of three inputs where each version is derived from the previous version.

The ThreeWayMerge has all of the capabilities of the n-way ConcurrentMerge class but provides some additional capabilities suited to the three way use cases such as the ability to represent and simplify the merge results using a two-way representation.

4.2. Extract all inputs

A complete representation of each input file means that there is no loss of information in the merged file, i.e. any one of the input files could be extracted as an XML tree. This is a general property of the merge system.. However some result formats and representations provide simplifications or processing that restrict this capability. In particular:

  • The rule processing system used with deltaV2 and simplified result formats automatically process changes such as adds and deletes. After these changes are processed the full details of these changes cannot be reversed and therefore all of the inputs cannot be extracted.
  • The three-to-way way result simplification process by design removes information associated the the ancestor input in order to emphasise changes between the branches being merged.

4.3. Supports nested change

The merge system supports generating optimal results which avoid repetition of content from the inputs. When three or more inputs are involved such a representation involves nested change. The simplified result format and the three-to-two way result simplification process are designed to remove the need for a nested change representation. This allows the results to be used with simpler user interfaces and editing processes, but with the potential loss of some detail in the result. The support for nested change is closely related to the types of user-interface available with the various result types.

4.4. Use with editor accept/reject

XML editors often provide accept/reject style user interfaces that can be used to process track-change recording and in some cases comparison results. This type of user interface supports add and delete operations and is unsuited to general n-way merge result processing. However the three-to-two way processing options available with the ThreeWayMerge class were designed to support this type of interface with the compromise that in some cases a little information, typically related to the ancestor input, cannot be presented to the user.

4.5. Use with DeltaXML oXygen plugin

A user-interface specific to n-way merge operations has been developed in order to demonstrate the possibilities that an n-way algorithm and interface can provide. DeltaXML has developed a plugin or 'add-on' for the oXygen editor for content used with the editor's author mode. This allows the user to deal with n-way conflicts as well as non-conflicting changes such as additions and deletions. A web-based resolving system ('XMLFlow') is also under development. Both of these systems are designed to handle nested change.

4.6. Suitability for automated processing

The n-way form of the deltaV2 result format was designed for ease of XSLT processing and conversion into other types of result. Using this result representation, it is easy to make processing decisions at various points in the XML tree as each element has information about any descendant change using the deltaV2 attribute. The format is also minimal so that information is not repeated unnecessarily.

4.7. Suitability for manual resolution

The deltaV2 format has information throughout the XML tree hierarchy that becomes laborious to process manually, for example when a user wishes to resolve merge conflicts or changes using an XML editor. A major driver in the design of the simplified delta format was to make manual processing of merge results easier. The simplified result can also be processed automatically using XSLT or technologies, however the change representation is not as rich as deltaV2.