ReplacementInfo data structure, which
maintains contextual and positional consistency throughout the pipeline. The approach is
validated through a suite of integration tests covering overlapping replacements, protected
inline elements, Unicode code-point indexing, and multi-group rule interactions.colourwith
colorshould not match the literal text
status="deleted" that happens to appear inside a change-tracking element. Because
the document is serialized XML, the engine must distinguish text content from tag syntax.ReplacementInfo record that carries positional and
authorship metadata across all three phases.<w:ins> and deletions
in <w:del>, each carrying author and timestamp attributes. ODF
<text:insertion> and
<text:deletion> elements. The ContentXML (CXML) format used in our
implementation employs <style> elements with a status
attribute whose value is "added" or "deleted", described in
<?oxy_insert_start?> /
<?oxy_insert_end?> and <?oxy_delete?> PIs
xsl:analyze-string (available since
XSLT 2.0 fn:analyze-string (available since XPath 3.0 tan:batch-replace(),
which applies an ordered sequence of find/replace pairs to text nodes, handling
back-references and case folding within XSLT. The advantage of tree-native replacement is
that tag boundaries are never at risk: the processor sees only text-node content, not
serialized markup.Design Trade-offs, paragraph
Serialization round-tripping).
<style> element with a status attribute value of
"deleted" or "added", together with author and
dateTime attributes, records a tracked change. A tracked deletion of the word
colourfollowed by its replacement
coloris represented as:
<p> elements alongside text nodes and other inline markup
(bold, italic, superscript). This means that serializing a paragraph to a string will
include the change-tracking elements as literal tag text.<style status="added"> element may itself contain further
<style status> elements, representing a subsequent change to text that
was itself introduced by an earlier change. This nesting is the mechanism by which the
format records layered editing history.<p> element in the
document (in reverse DOM order to avoid index invalidation as nodes are replaced). For each
paragraph, it executes three phases:allReplacementsForPNode, of ReplacementInfo
records threads information through all three phases. After Phase 3, the reconstructed XML
string is wrapped in a <p> element and replaces the original node in the
DOM.<style status> wrapper elements), while recording the position and
authorship of every pre-existing track change so it can be reinstated in Phase 3.<style> elements with a status attribute. For each
status="deleted" element, it records the inner XML content as
deletedText, finds the element's character offset within the serialized
paragraph string, removes the element from the DOM, and creates a
ReplacementInfo record. For each status="added" element, it moves
the element's children directly into the parent paragraph (unwrapping the
<style> wrapper), records the addedText, and creates a
corresponding ReplacementInfo record. In both cases, the author
and dateTime attributes from the original element are preserved in the
ReplacementInfo.pElement contains the paragraph with track changes
unwrapped—the addedtext is present inline and the
deletedtext is captured in
allReplacementsForPNode. The paragraph is now ready for
regex processing without any change-tracking markup interfering with pattern
matching.java.util.regex.Pattern is compiled and applied to
the serialized text. For each match, the code checks:Match caseis unchecked.
$0, $1, $2, ...) in the replacement string are
resolved using the groups captured by the original Matcher, preserving the
surrounding context that lookahead and lookbehind assertions depend on.ReplacementInfo is added to the per-group
local list.StringBuffer:ReplacementInfo
in allReplacementsForPNode—whether from Phase 1 (pre-existing track changes)
or accumulated during Phase 2—always refers to positions in the
currentProcessedText is the fully replaced
paragraph text as a flat string (still containing inline XML markup for bold, superscript,
etc., but no <style status> wrappers), and
allReplacementsForPNode is a sorted list of every change that should be
recorded as a track change—both pre-existing editorial changes and new programmatic
ones.allReplacementsForPNode in order
and produces a new XML string:Onewith
two. Now suppose a dictionary rule maps
two → three. After Phase 1, the paragraph text is
"Confirm that the two is changed to a three" (the deleted text
Oneis captured in
allReplacementsForPNode, the added text
twois unwrapped into the paragraph body). The rule matches
twoat its position in this text and adds a new
ReplacementInfo to
allReplacementsForPNode.allReplacementsForPNode contains two records:| # | startIndex | endIndex | originalText | replacedText | author |
|---|---|---|---|---|---|
| 1 | 17 | 20 | One |
two |
test user |
| 2 | 17 | 22 | two |
three |
Tool |
originalText equals Record 1's replacedText. This
is the nested case: the programmatic replacement targets exactly the text that the editorial
change introduced.nested list, and
processTrackChanges() is called recursively with nested as the
replacement list. The recursive call produces:status="added" element for Record 1, yielding
the final output:Oneto
two, and the automated tool subsequently changed
twoto
three. A reviewer can accept or reject each change independently. The outer pair of
<style> elements carries the
editor's authorship; the inner pair carries the rule's identifier.twoat position 17, Record 1 already exists in
allReplacementsForPNode with the same startIndex and
replacedText equal to the matched text. If Phase 2 were to add a second record
unconditionally, the result would be a duplicate sibling rather than a nested child. An
isSameText predicate detects this situation—it checks whether an existing record
already covers the same position with a replacedText matching the current
match's originalText—and suppresses the sibling record. Phase 3's recursive call
then picks up the match via the semantic nesting condition, producing the correct nested
structure shown above.other.originalText.equals(info.replacedText)) detects genuine nesting as
described above—a later rule modifies text that an earlier rule introduced. The first
disjunct is purely positional: it checks whether one record's range falls inside another's.
However, because offset propagation (allReplacementsForPNode consistent as replacements of varying lengths are
applied to the text. As noted in String.codePointCount(0, length) rather than
String.length() for all position computations. This ensures correctness for
Unicode content containing characters outside the Basic Multilingual Plane (represented as
surrogate pairs in Java's UTF-16 char encoding), which appear in scientific
and mathematical content—a common case in academic publishing.Δ = codePointCount(replacedText) − codePointCount(originalText) is propagated
forward:startIndex > currentStartIndex have their startIndex and
endIndex shifted by Δ.allReplacementsForPNode from
group < currentGroup) that
fall after the current replacement position are also shifted. This is necessary because
those records were computed against earlier snapshots of the text.startIndex > info.getStartIndex()) ensures that
only records positioned after the current replacement are shifted, since the replacement
does not affect text before its start position.ReplacementInfo, its positions are already correct for the current
text state. Earlier-group records in allReplacementsForPNode must be
retroactively adjusted whenever a later-group replacement changes the text length. The
condition r.getGroup() < info.getGroup() in the offset propagation loop
performs this retroactive adjustment.allReplacementsForPNode—regardless of which phase or which group produced
it—is positioned relative to the same final text snapshot that Phase 3 operates on. A
consequence is that an earlier-group record's position may be shifted into a later-group
record's range, creating a positional coincidence that Phase 3 distinguishes from semantic
nesting via the group-ordering guard (ReplacementInfo, preventing the replacement engine from
corrupting the XML markup.ReplacementInfo, whose fields encode both positional and authorship data:| Field | Type | Purpose |
|---|---|---|
startIndex |
int |
Code-point offset of the match start in the current text |
endIndex |
int |
Code-point offset one past the match end |
originalText |
String |
The matched (deleted) text |
replacedText |
String |
The replacement (added) text |
regexId |
String |
ID of the rule that produced this replacement (empty for Phase 1 records) |
group |
int |
Rule group number (used for offset filtering and nesting guard) |
enableTc |
boolean |
Whether this replacement should appear as a track change in the output |
author |
String |
Pre-existing track-changes author; empty for programmatic changes |
dateTime |
String |
Pre-existing track-changes timestamp; empty for programmatic changes |
author / dateTime being either populated
(Phase 1, pre-existing track changes) or empty (Phase 2, programmatic) drives the authorship
logic in Phase 3: a non-empty author means the original metadata is forwarded
as-is; an empty author means the tool attribution and the current timestamp are
synthesized.enableTc field allows per-rule opt-out of track change generation. A
rule with enable-tc="false" applies its replacement silently: the text changes,
but no <style status> elements are emitted. This is useful for
normalization passes (e.g., collapsing redundant whitespace) that should not clutter the
reviewer's view. It is also necessary when the replacement text is not well-formed XML in
isolation—for example, a rule that inserts an opening tag without a corresponding closing
tag, or vice versa. Wrapping such a replacement in
<style status="added"> would produce invalid XML; disabling track
changes for the rule avoids this problem.<p>) level. Each paragraph is
processed independently: it is extracted as a DOM subtree, serialized to string, processed,
and replaced in the document. This granularity matches the editorial workflow assumption that
reviewers accept or reject changes paragraph by paragraph. It also provides error isolation:
if a single paragraph produces malformed XML during reconstruction, only that paragraph
fails; the remaining paragraphs are still processed.DocumentFragment. The implementation
configures the serializer with OMIT_XML_DECLARATION=yes and
INDENT=no to prevent namespace or whitespace artifacts.processTrackChanges() call would need to be evaluated carefully for correctness
in that case.alphato
betaand an automated rule targets
alphabetin the original text. The string
alphabetspans the boundary of the editorial change:
alphahas been replaced by
beta, and
betis now followed by whatever came after. In the element-wrapping model, there is no clean representation of a change that straddles a pre-existing change boundary. The current implementation handles this conservatively: Phase 1 unwraps the editorial change, so the text seen by Phase 2 reflects the
beta...), not the original (
alpha...). A rule targeting the original text
alphabetwould simply not match. This is correct behavior—the tool processes the document as it stands—but it means the tool cannot reason about the original pre-change text. Word processors with richer change-tracking models (such as OOXML's run-fragmentation and anchor-based approach) can represent finer-grained overlapping edits, at the cost of considerably more complex markup.
xsl:analyze-string
(XSLT 2.0+) or fn:analyze-string (XPath/XQuery 3.0+), provides a solid
foundation for this kind of work java.util.regex features. The notable gaps are: lookbehind assertions (XPath
regex supports lookahead (?=...) and (?!...) but not lookbehind
(?<=...) and (?<!...)), possessive quantifiers, and certain
Unicode property shortcuts. Saxon's j flag for fn:matches and
fn:replace provides access to Java's full regex engine, bridging most of these
gaps for deployments that use Saxon tan:batch-replace() ReplacementInfo records are accumulated, mutated in-place, filtered
by group, sorted, and passed through recursive calls. The offset propagation requires
in-place mutation of a shared list with different filtering criteria at each step. While XSLT
3.0 xsl:iterate, and
accumulators ReplacementInfo record and the two-level offset propagation strategy. The
secondary challenge is correctly handling cases where a programmatic replacement targets text
that was itself introduced by a prior editorial change; this is resolved by recursive track
changes reconstruction in Phase 3. A related subtlety is distinguishing genuine semantic
nesting from positional coincidence introduced by cross-group offset propagation; the nesting
condition uses a group-ordering guard to separate these cases
(xsl:analyze-string) combined with imperative track-changes
reconstruction—could reduce the serialization round-trips while preserving both the
algorithm's correctness properties and compatibility with existing dictionary
patterns.Onewith
two.
two→
threewith track changes enabled:
One→ ...) is preserved. Inside the
<style status="added"> element for that change, the tool's change
(two→
three) appears as a nested pair:
two→
three(at the start of the paragraph text) is a direct replacement. The second occurrence, inside the
<style status="added"> element, is the nested case: the rule has modified
text that was itself introduced by the editor's earlier change. Both layers of editing
history are preserved and independently reviewable.2024-01-09T12:00:00) for all
tool-generated changes, making the output deterministic and directly comparable to the
expected file. The comparison is performed using XMLUnit
Concurrency Control in Groupware Systems.
Standard Change Tracking for XML.
Approaches to Change Tracking in XML.
A New ⟨u⟩: Extending XPath Regular Expressions for Unicode.