Native XFA Data DOM

General execution with EnableJavaScript exposes the document's native datasets tree through xfa.datasets, $data and $record resolver paths and FormCalc accessors

Data nodes use stable native identities and the same live SOM resolver as form nodes; they support names, class selectors, occurrence selection, parent traversal, predicates and node-level resolution

Roots and classes

Object or path	Meaning
`xfa.datasets`	The datasets packet node, or null when absent
`xfa.datasets.data` and `$data`	The data root under the datasets packet
`$record`	The first record root under data in the current non-record processing model
`dataGroup`	A data element containing child elements, including an explicitly declared empty group
`dataValue`	A data element carrying a value
`formNode.dataNode`	The node bound to the form field or subform, or null when no data binding is present

The dataNode attribute in the XFA data namespace can explicitly select a group's or value's class; namespace prefixes are resolved rather than requiring a particular prefix spelling

Reads and writes

A dataValue exposes value as a writable alias of rawValue; both accessors update the same bound data cell and native data node

const value = xfa.resolveNode("$record.row[1].cell");
value.rawValue = "25";
target.rawValue = xfa.resolveNode("main.row[1].cell").rawValue;

$record.row[1].cell = 25
target = row[1].cell
var p = Ref($record.row[1].cell)
p = 30

Bound field writes update the corresponding data value immediately, and data value writes update bound field reads immediately within the same script; native publication writes the actual data node

Materialized scalar value properties synchronize their native form content after field or data writes, including shared-data aliases and new repeated-instance data publication

Data elements without a bound form field remain accessible and writable; successful transactions preserve their changes in saved XDP

Form fields with bind match=none retain template defaults and store edits in their own occurrence's Form DOM value; they expose no synthetic data node and do not modify sibling occurrences

Data values share Unicode, value-size and execution budgets with the form event host; group nodes provide structural access rather than a writable raw value

Repeated instances and retained references

Form instance insertion, movement and removal update the corresponding live Data DOM during the same script; new implicit-bound rows expose template defaults through their data nodes before publication

A zero-occurrence prototype can create its first data group and values; native publication supplies real identities for the new nodes, allowing script objects to retain data handles across subsequent events

Retained data references follow movement by identity; using a reference after its group is removed fails the event, and runtime rollback restores native occurrence order, values and script-object counters

Instance managers retained by script objects resolve the current scope, including managers whose initial occurrence count was zero

Native XML content

datasets, dataGroup and dataValue nodes expose loadXML and saveXML with native parsing, same-script graph updates and transactional publication

XML imports preserve comments, processing instructions, CDATA, expanded namespaces and Unicode names while keeping nontext nodes out of ordinary Data DOM child selection and visible field values

Imported values immediately synchronize bound field reads, including fields whose existing dataRef selects a different suffix or whose previously unresolved target is now available

Transactions and lower-level callers

TXFAWidgetRuntime builds data-domain bindings, links form fields to native data values, applies data writes and new identity bindings, and restores exact XDP state after engine or native publication failure

Lower-level event callers use TXFAEventBindingDomain and the DataIdentity and DataBindingEnabled fields of TXFAEventBinding to supply equivalent object relationships

The xeakBindDataIdentity action binds a new virtual data handle to its published native data identity; lower-level applications must apply returned data mutations and identity bindings transactionally

Remaining object-model coverage

Record-window navigation, standalone data-node creation and reparenting, arbitrary data attributes, and full template property-node editing remain separate integration targets

Instance mirroring follows the existing implicit data-binding instance manager behavior; additional explicit-binding instance mutations require further binding integration