Chapter 4, Exchanging Data Between an External Application
and a Basic XFA Form
XFA Specification
Basic Data Binding to Produce the XFA Form DOM
177
Match Attributes (Step 3)
Attributes may optionally be loaded into the Data DOM. If loaded, they are represented by data value
nodes with the
contentType
property set to
metadata
. All of the preceding steps in the data-binding
process ignore data value nodes representing attributes. Instead they are handled separately at this point
in the process.
If attributes have been loaded into the Data DOM, after all the above processing is complete, the data
binding process makes one more try to match any yet-unmatched ordinary fields or exclusion groups to
data. It looks for attributes of data values that match the names of unbound fields. Note that it ignores
attributes of data groups; only attributes of data values are processed. Also, attributes that are already
bound via explicit data references are excluded.
For example, suppose the data says:
<?xml version="1.0"?>
<registration>
<first>Jack</first>
<last>Spratt</last>
<street apt="2">99 Candlestick Lane</street>
<city>London</city>
<country>UK</country>
<postalcode>SW1</postalcode>
</registration>
Failing to find a match for the
apt
field, the binding process extends the search to attributes of data
values. It finds the
apt
attribute of the
street
data value and binds it to the
apt
field. This is useful with
data produced by third-party programs which may choose to pass data in attributes rather than content.
(There is no general rule in XML for deciding what should be an attribute and what should be content.)
Attributes that are not needed to supply values for unbound fields or exclusion groups are ignored.
Re-Normalization (Step 4)
In certain cases, a data node may end up bound to a form node even though the nearest merge-able
ancestor of the data node and the nearest merge-able ancestor of the form node are not bound to each
other. XFA applications may provide an option to move data nodes around to reconcile these
contradictions. This process is referred to as
re-normalizing (or adjusting) the Data DOM.
Re-normalization
always does the least moving it can, so the data structure is kept as close to original structure as possible. If
the application does not request this service, existing nodes in the Data DOM stay where they are.
The example that was used above to illustrate scope matching will also serve to illustrate re-normalization.
The template has the following skeleton:
<template …>
<subform name="registration">
<field name="first" …> … </field>
<field name="last" …> … </field>
<subform name="address">
<field name="apt" …> … </field>
<field name="street" …> … </field>
<field name="city"…> … </field>
<field name="country"…> … </field>
<field name="postalcode"…> … </field>
</subform>
</subform>