Test authored origin, frame-generation, and JSON message cases against the current DocA policy. Accepted candidates remain SaveReceived with persistence pending; no live editor is embedded.
Keep viewer output separate from the editor protocol
Draw.io's HTML embedding guide describes exported viewer markup and its JavaScript dependency. A reading-only export is a display option; it does not implement the host's editor load/save transaction.
The official embed-mode reference documents the editor at https://embed.diagrams.net with embed=1. For this fixture, choose proto=json as well, so the host follows the documented JSON protocol.
These are intended configuration values, not a tested iframe URL or evidence that an external editor works in a particular host. Record the actual editor/host version or deployment identity, browser, frame configuration, and permissions later.
The fixture proposes no public diagram URL, cloud account, analytics, automatic sharing, or remote storage. A viewer's separate “open for editing” affordance would need its own review; it does not replace the bounded host integration below.
Define the original document and stable graph identities
Document DocA revision R1 has:
| Authored element ID | Element | Initial value |
|---|---|---|
| intake-node | Node | Intake |
| check-node | Node | Check |
| intake-check-edge | Directed edge | intake-node → check-node |
These source element IDs remain fixed in the illustrative XML candidate, including the edge endpoints. A native editor and persisted-source record still require separate evidence.
The edit target changes the label of check-node from Check to Review. It retains the node identity and the same directed edge. The expected graph becomes Intake → Review.
Do not create a new node merely because its label changes, infer IDs from diagram position, or compare only a rendered screenshot. The later native inspection should confirm labels and source relationships.
DocA's document identity, original persisted-source reference, and current editor session belong to the host. They are not fields that this article assumes the editor will echo in every message.
Wait for JSON initialization before loading XML
The embed reference describes an init event under proto=json, followed by the host's load action containing XML. Wait for the current frame's validated init before sending DocA's source. JSON embed protocol
A minimal message-shape specification is:
Editor to host:
{"event":"init"}
Host to editor:
{"action":"load","xml":"<actual DocA XML string>"}
Editor to host after Save:
{"event":"save","xml":"<actual edited XML string>"}
The angle-bracket descriptions are placeholders, not valid diagram source. JSON values must be serialized from actual data during implementation. Do not interpolate raw XML into HTML markup as an ad hoc transport.
This baseline does not enable autosave, configure-handshake extensions, diff synchronization, or other protocol options. If those are added, record a new configuration and verify their messages separately.
Sending load immediately after creating an iframe is not evidence that initialization completed. Identify the observed native event and the host state in the ledger. A duplicate or out-of-sequence init should not blindly reload R1 over unsaved edits.
Accept messages only from the current trusted frame
A plausible JSON object is not sufficient authority to replace a diagram. MDN's postMessage guidance calls for checking sender identity and message syntax and using an exact target origin.
Keep SaveReceived separate from Persisted
| State | Meaning in this specification |
|---|---|
| Loading | Current frame/session awaits initialization and document loading |
| Editing | Current document is available for the intended edit |
| SaveReceived | A current, accepted save message supplied candidate XML |
| PersistencePending | The host's chosen storage operation has not been confirmed |
| Persisted | Actual storage evidence identifies the stored document revision |
| Failed | A specific load, message, XML, or persistence failure needs resolution |
Check initialization, save, and failure cases
| Case | Event or edit | Expected outcome |
|---|---|---|
| A | Valid current init, then DocA load | Initialization precedes load |
| B | DocA Check renamed Review; valid current save | Candidate XML received; persistence still pending |
| C | Save-shaped message from wrong origin | Rejected |
| D | Correct origin, wrong window | Rejected |
| E | Malformed JSON or invalid save shape | Rejected with specific reason |
| F | Old DocA frame sends save after replacement by DocB | Rejected for current document |
| G | Future storage fails | Received candidate distinct from last persisted revision |
Try the worked example
Check the authored current-frame save envelope to get SaveReceived. Change the origin or mark the frame old to reject it. Keep the XML candidate distinct from the last persisted revision, which this demonstration has no evidence to fill. Local receipt does not establish persistence.
This is a synthetic transport-policy exercise, not a native diagrams.net editor, real postMessage sender check, XML acceptance test, or storage implementation.
Recreate this example
Build one complete self-contained HTML page for this task: check the original synthetic draw.io message envelope and distinguish candidate receipt from persistence.
Use these exact original practice data and worked expectations: DocA begins with Intake → Check; the proposed edit renames Check to Review. The authored envelope must use the exact origin https://embed.diagrams.net and the current frame session. Wrong origins and old sessions are rejected. The proto=json init/load/save contract separates SaveReceived from Persisted: receiving a save does not prove storage. This exercise has no real frame or storage.
Implement the following useful local interactions: Origin input, synthetic frame identity current/old, JSON save payload containing an XML string, and Check. Validate the exact origin, current marker, save event, and nonblank XML string within 10,000 UTF-16 code units. Report envelope acceptance only; XML validation separate. Switch document session invalidates old candidates. Do not run iframe or fake Save. Preserve the supplied source text and distinguish an uncomputed state, a successful local result, and an invalid or incomplete input. Update output only from the current input snapshot. An input edit must retire stale feedback until the reader runs the relevant action again. Do not silently invent missing values or replace a failing case with a success.
Design the page as a compact source-and-result developer workbench with readable code, labeled inputs, and a separate explanation area. Put a compact task heading, actual sample data, the main result, and usable controls early enough to be useful on a narrow screen. Use readable text of at least 16px, generous paragraph spacing, strong contrast, native labels, accessible buttons, and visible keyboard focus. Stack long records at 360px and wrap code without page-level horizontal overflow.
Use type=button and explicit querySelector-based click handlers rather than relying on form submission. If Enter is useful, handle it only on the relevant input and ignore isComposing. Keep effects within this open page; no remote dependencies, network calls, persistence, fake downloads, or automated sending. This is a synthetic transport-policy exercise, not a native diagrams.net editor, real postMessage sender check, XML acceptance test, or storage implementation. Place worked explanations beside their data and identify teacher or synthetic examples clearly. Output only the complete HTML document, with inline styles and script and LF line endings.
Review the synthetic editor-message envelope checker in NOS
Implement real event.origin, event.source, and host session checks before connecting storage. Review the Check-to-Review rename beside the SaveReceived and Persisted definitions in NOS, and revise eligible static save-state instructions in visual editing mode if receipt sounds like storage.