XFA Specification
Chapter 13, Dealing with Data in Different XML Formats
Extended Mapping Rules
382
For the example data above, the following fragment in the XFA configuration document would cause the
inverted XML to be represented in the XFA Data DOM the same way as the conventional XML:
<transform ref="item">
<nameAttr>nodename</nameAttr>
</transform>
Although this renaming is performed before some other transformations it does not affect which later
transformations apply to the renamed node. For example, the following configuration fragment:
<transform ref="item">
<nameAttr>nodename</nameAttr>
<whitespace>normalize</whitespace>
</transform>
causes the data from the
address
elements in the above example to be renamed. It also causes those
same nodes to be normalized in whitespace, even though their names no longer match the
ref
value in
the
transform
element.
The XFA configuration document must not declare multiple different
nameAttr
mappings for the same
value of
ref
. For example, the following fragment from an XFA configuration document illegally declares
two different
nameAttr
mappings for
foo
:
<transform ref="foo">
<nameAttr>x</nameAttr>
</transform>
<transform ref="foo">
<nameAttr>y</nameAttr>
</transform>
This is forbidden because it can lead to paradox. For example, consider the above illegal configuration
fragment and the following XML data document:
<foo x="abc" y="def">some content</foo>
If the configuration was legal, the data loader would be required to map the data value simultaneously to
both names
abc
and
def
, which is impossible.
If the value supplied by the nominated attribute is not a valid XML node name, the behavior of the data
loader is implementation-defined.
Note that this mapping is data-dependent in that the data determines what node names result.
Consequently it is not reversible; inverted XML can be loaded into the XFA Data DOM but cannot be
copied back into the XML data DOM.
The picture Element
During data binding and after an item of data has been bound to a particular field in the form, the
supplied data may be interpreted using a
bind
picture clause. The
bind
picture clause describes the
formatting of the data. For example, a
bind
picture clause of
"$999.99"
indicates that the data contains
a currency symbol, followed by three digits, followed by a radix indicator, followed by two more digits.
The XFA processor uses
bind
picture clauses to parse the numeric content and make the value available in
canonical format to scripting engines. It also uses the same picture clause on output to convert the
internal canonical number into the appropriate human-readable format. In the example, if the data string
is
"€439,02"
the canonical format is
"439.02"
.