Release note · August 3, 2026
A Word OLE link can change without an embedded payload
An OLE object in a Word package is not always an opaque binary part under word/embeddings. Legacy VML can instead carry an OLE object typed as a link, with an external standard oleObject relationship. A package can therefore retain its ordinary stored text, its VML object carrier, and its entire member set while the linked source changes.
Document Change Assurance Benchmark (DCAB) 0.15.0 adds its twenty-sixth deterministic pair: external.vml_linked_ole_object_target_retargeted. Neither side contains an embedded OLE payload. Both retain one w:object carrier, one VML placeholder, Type="Link", the fixed link metadata, the relationship ID, and ordinary stored w:t values. Only word/_rels/document.xml.rels changes: one private external target is retargeted.
The link is a relationship, not a payload
Microsoft’s VML o:OLEObject reference places the element inside a Word w:object carrier, identifies the actual OLE object through r:id, and associates the object with a VML placeholder through ShapeID. Its UpdateMode applies when Type is Link. Microsoft’s Office compatibility notes describe that type as distinguishing an object stored externally from one included in the package.
word/document.xml
w:object
v:shape id="fixed placeholder" o:ole=""
o:OLEObject Type="Link" r:id="rIdLinkedOleObject"
word/_rels/document.xml.rels
rIdLinkedOleObject ──oleObject, External──> private sourceThat is a different review boundary from DCAB’s embedded-OLE payload case. The new fixture has no word/embeddings member and does not interpret an OLE compound file. It requires a reviewer to associate a link-typed VML OLE anchor with its external oleObject relationship while preserving the fixed marker topology around it.
One changed relationship, no activation claim
The generator and verifier require exactly one object carrier, one sibling VML placeholder, one link-typed o:OLEObject, fixed ProgID/shape/object identifiers, visual aspect, update mode, and one external standard oleObject relationship. They also require the package-member set and stored Word text to remain stable, and declare the relationship part as the sole changed member.
No component opens Word, renders the VML object, resolves or retrieves a source, parses an OLE payload, activates an object, launches an application, authenticates to a target, or claims a client will update or display it. This is static package review evidence only.
Aggregate evidence without the source
The optional DocFence 0.27.0 adapter maps the aggregate external_relationships_changed, embedded_object_inventory_changed, and word_vml_linked_ole_object_inventory_changed transitions. Both sides retain one linked-OLE object and one external standard OLE relationship; DCAB observations do not include the source, relationship ID, shape/object IDs, ProgID, update mode, path, or document text.
Hosted CI passed on Python 3.11, 3.12, and 3.13, including a separate clean DocFence adapter job. The standard python-docx reader opens all 50 .docx fixtures, while its lower-level OPC reader opens all 52 packages. Rebuilt fixtures, fresh wheel and source-distribution installs, the published GitHub release downloads, and a fresh Hugging Face dataset snapshot each validate the 26-case corpus.
Use the release
python -m pip install https://github.com/SybilGambleyyu/document-change-benchmark/releases/download/v0.15.0/document_change_benchmark-0.15.0-py3-none-any.whl
dcab validate
dcab docfence-observations --executable docfence --output observations.json
dcab score --observations observations.json --strictDCAB 0.15.0 retains fixture schema version 1 because its public truth and observation envelopes are unchanged. It adds one precise linked-object relationship boundary, not an OLE parser, object launcher, document renderer, or runtime security claim.
The MIT-licensed source, generated fixtures, structural verifier, release artifacts, and research notes are available on GitHub. The fixture corpus is also mirrored as a public Hugging Face dataset.