Choose a DOCX Revision View Before Local AI Ingestion

Direct answer

A DOCX is a package containing WordprocessingML parts, not a plain-text file with harmless formatting. If a local-AI feature extracts text from a user-selected document, it must decide which revision view the user intends before sending content to a model. A tracked deletion can remain in the package even though it is not part of an accepted view; an insertion may be proposed text not yet accepted. Passing every text node to inference can expose removed wording or combine competing alternatives. This guide concerns revision-aware text extraction after a package has already been opened under a separately tested container policy. It does not teach ZIP path validation or XML external-entity hardening, and it does not claim that Cove currently imports DOCX. In WordprocessingML, `w:ins` and `w:del` mark inserted and deleted run content; deleted text can be represented by `w:delText`. Move-from and move-to markers represent another revision relationship. A flat descendant-text walk loses those distinctions. It may include text that a user believes was removed, omit which replacement it was paired with, or concatenate two versions into a sentence that never appeared in the document. Preserve a source-part and revision-kind reference for every extracted span, or reject a document whose revision structures the supported view cannot interpret. Revision semantics are broader than filtering two inline tags. A tracked deletion of a paragraph mark can merge adjacent paragraphs while leaving their text intact; Microsoft’s Open XML example documents that the paragraph contents are not automatically deleted with the mark. Paragraph and table property changes can alter structure without changing run text. Revision markup may also occur in related document parts such as footnotes or endnotes. A text-only importer should state which parts and revision types it supports, and report unsupported markup rather than calling its output a complete Word view. Fields and their cached results, comments, headers, and footers are separate content sources; do not silently imply that they were represented when they were skipped. Choose a product policy instead of guessing. An original-like projection simulates rejecting pending changes; a final/proposed projection simulates accepting them; a review view retains pending alternatives and revision metadata. Here an accepted-view projection means a user-selected simulation of accepting all supported pending revisions, not evidence that the author already approved them. Different decisions per revision require an explicit decision map and a capable implementation. The user or document workflow must select the meaning; author names, timestamps and trackRevisions are not acceptance decisions. Use a mature implementation for the chosen view or mark unsupported semantics. Never apply accept/reject changes to the original package as an import shortcut. Keep extraction read-only. Preserve the source bytes and a stable identifier or digest in app-owned task state, then create a separate derived representation with explicit labels such as inserted, deleted, moved-from, and moved-to. Link every span to its package part and location where practical. If the model receives only the accepted view, retain a record of excluded revision text without placing that text in the prompt; if the user requests review, show alternatives in a human-readable preview before processing. Clear derived copies according to the feature’s retention policy, and never delete or rewrite the original content-provider document. Test revision cases using synthetic DOCX fixtures whose expected views are prepared independently. Cover inserted and deleted runs, `w:delText`, moves, a deleted paragraph mark, tracked table or paragraph properties, footnotes/endnotes, fields, nested or malformed revision markup, no revisions, and unsupported parts. Compare extraction against the chosen policy, not against a plain-text dump or one editor’s incidental rendering. Include a sentinel in deleted text and assert it does not reach an accepted-only model prompt. Also assert the source file hash is unchanged after preview, cancellation, parsing failure, and successful extraction. Microsoft’s Open XML SDK documentation is useful evidence for the package vocabulary and revision examples, but its .NET classes are not an Android API and do not establish that an Android library supports the same view. Pin and test the actual parser/provider used by an Android product, including its revision semantics, part coverage, memory limits, and error behavior. A passing fixture suite supports only that implementation and policy. It does not prove visual equivalence to Microsoft Word, comprehensive document conversion, legal review, or a current Cove feature.

A selected DOCX contains an unaccepted deletion

A user chooses a contract draft for local analysis. The package includes tracked replacement wording and a deleted paragraph that remains present in the WordprocessingML parts. The importer has not defined whether it sends a proposed, accepted, or review view.

Decision

Pause before model processing, show the supported revision-view choice, and preserve source-part provenance without changing the selected document.

Expected outcome

The task uses only the user-selected view; excluded deletion text is absent from an accepted-only prompt and remains in the untouched source.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Part and revision-kind provenance
• Run, move and paragraph-mark fixture views
• Deleted-text exclusion and unchanged-source checks

Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.

Implementation workflow

1. Specify the supported document view. Define whether extraction represents an original-like, proposed, accepted, or review view, and identify the revision and package parts included. Unsupported semantics must produce an explicit limitation.
2. Use a revision-aware parser contract. Preserve `w:ins`, `w:del`, move markers, deleted text, paragraph-mark changes, and structural property changes as distinct cases. Do not flatten all descendant text or infer acceptance from revision metadata.
3. Create a separate read-only derivative. Keep source bytes unchanged; produce labeled extracted spans with part/location provenance. Never apply accept/reject changes to the original package as part of text import.
4. Review before model input. Show the chosen view and any excluded or unsupported sections. Require user selection when alternatives affect meaning; do not send hidden deletion content in an accepted-only task.
5. Test exact parser behavior. Use synthetic revision fixtures, deleted-text sentinels, unchanged-source checks, cancellation, malformed parts, and device builds. Scope claims to the tested parser and supported package parts.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• The task identifies its revision view and supported package parts before inference; unsupported revision structures are visible rather than silently flattened.
• Inserted, deleted, moved, paragraph-mark, and relevant property changes are handled according to the selected view, not a two-tag text filter.
• The selected DOCX source remains byte-for-byte unchanged through success, cancellation, and failure; derived text retains reviewable provenance.
• Microsoft Open XML examples are not represented as an Android API or as evidence that Cove supports DOCX import.

Decision table

Failure patterns to prevent

• Treating accept-all projection as author approval
• Flattening all descendant text
• Confusing .NET format examples with Android support

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Android privacy and security
• Microsoft Learn — Accept all revisions in a WordprocessingML document
• Microsoft Learn — DeletedRun and WordprocessingML deleted content
• Ecma International — ECMA-376 Office Open XML standards

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions