Chapter 4, Exchanging Data Between an External Application
and a Basic XFA Form
XFA Specification
Localization and Canonicalization
143
Limitations in Picture Clauses
While this solves some problems, it does not address every need. For example, the interchange date and
time format is based on the Gregorian calendar. It would be possible to do conversions to and from other
calendars, but locale support on most platforms does not go this far. Hence in this version of XFA only the
Gregorian calendar is supported. Another limitation is that times may be entered through the UI without
any accompanying date or time zone. Such a time is inherently ambiguous. When a user enters a time
without time zone information, the application supplies the time zone from the prevailing locale.
A more fundamental limitation applies to currencies, namely that there is no way to automate conversions
between currencies. Currency exchange rates are constantly fluctuating and in any case the appropriate
rate varies depending on circumstances (a retail banking customer can't get the same conversion rate as a
financial institution can). Hence currency conversions should not and can not be done automatically.
Therefore locale can be used for simple currency formatting and parsing but it entirely is up to the creator
of the form and designer of the web service or data file to arrange for monetary amounts to be computed
in the appropriate currency.
Recommendation on Specifying Locale
It is recommended that locale definitions be included with a template when it is created. This ensures that
the template creator and the template user see the same definition for the locale. However it would be
inefficient to include all possible locales, as the definitions take about 3kbytes apiece. It is more sensible to
include only those that are going to be used. Also, it is not necessary to include a definition for
en_US
(United States of America English) because it is the default for XML and consequently is available and
thoroughly tested on all platforms. On the other hand including a locale definition this way makes the
definition accessible to scripts via SOM expressions. Built-in locale definitions are not accessible this way,
although of course the locales they define can still be used.
Scripts must not alter locale definitions. The result of any such attempt by a script is undefined.
Selecting Between Alternate Picture Clauses
Template designers can create picture clauses that support multiple locales. Such picture clauses contain a
series of alternate picture clauses, each of which specifies a locale. (“Picture
page 901)
This technique is useful only for canonicalizing data (during data loading or input parsing). That
is, when canonical data is localized using a set of alternate picture clauses, only the first picture clause is
used.
Dataflow Paths for Localizing and Canonicalizing Data
The XFA Data DOM and Form DOM maintain their contents in canonical format. Data supplied to an XFA
processing application may appear in localized or canonical format. The XFA processing application
ensures such data is in canonical format before adding it to the Data DOM or the Form DOM. Later, data in
the XFA Data or Form DOMs may be localized before being presented in a human-readable form.
The diagram below illustrates the situations in which data is localized and canonicalized. It also shows the
picture clause elements influence conversions for each type of situation and explains in general what
triggers such conversions. The table on
page 145
elements that influence localization and canonicalization.
“The localeSet Element” on page 149
describes the default picture clauses used when a picture clause
element is not defined for a field.