W3C home > Mailing lists > Public > public-forms@w3.org > September 2008

Handling currency values in XForms

From: John Boyer <boyerj@ca.ibm.com>
Date: Tue, 23 Sep 2008 09:34:53 -0700
To: public-forms@w3.org
Message-ID: <OF1EFA693A.9A8860AE-ON882574CD.0055E993-882574CD.005B1B2E@ca.ibm.com>
One of the things that makes it hard for us to do effective demonstrations 
in XForms is the lack of support for currency formatting.  Numeric values 
computed at the data layer typically have many more digits of accuracy 
than we want, and of course they don't have things like comma separation 
or currency symbols.

So far, it appears to be the case that every host language is adding its 
own special markup to indicate We have been using host language markup to 
value-add an xforms:input by formatting a data value as a currency on 
output, and allowing a user to enter a currency value, and then boiling 
that down to the raw data value before pushing the result to data.

However, it would be helpful if we came up with a common markup to signify 
the desire for a currency value at the XForms level. One idea that comes 
to mind is using the 'appearance' attribute, so that currency is a hint to 
the processor.  So, suppose you have some markup like this:

<xf:instance>
   <data xmlns="">12345.6789</data>
</xf:instance>

<xf:input ref="/data" appearance="currency">
    <xf:label>Enter principal of loan:</xf:label>
</xf:input>

The output display resulting from this might be $12,345.68.  Then, if the 
user types $9,876.4567, it seems the user input should be stripped of 
currency formatting and rounded appropriately, so that the raw data sent 
to the model would be 9876.46.  Then, the input would reformat the actual 
data to display $9,876.46.

Of course, the problem is not so simple:
1) In many locales, the decimal separator is a comma, not a period
2) In many locales, the grouping separator is a period or a space, not a 
comma
3) The currency symbol is locale dependent
4) The currency value may be in a different locale than the user, e.g. 
showing Japanese currency values to a European.
5) The data itself may carry currency-related information.
6) Some financial applications require currency values with more precision 
than two digits past the decimal place.

For the first three of these, and possibly the fourth, it seems reasonable 
to use xml:lang to solve the problem.  Well, it is as reasonable as our 
current solutions at the host layer markup.  Point 5 and to some extent 
point 6 are more advanced scenarios in which it is clearer that there 
should be some notion at the data layer of a number being a currency 
value.

One almost wants for another XForms datatype for currency, similar to our 
card-number type, which makes no significant contribution to data 
validation beyond that obtained from the underlying decimal value, but 
which communicates to UI controls bound to the node that it is a currency 
value.

Attaching the locale information to the currency value could then be done 
at the data layer using an xml:lang attribute. 

It is a little hard to see how to solve the decimal precision problem, but 
if that is the only outstanding problem, then perhaps that could get 
pushed to the UI layer or left as a battle for another day.

So, here's how it might look if we did it this way:

<xf:instance>
   <loan xmlns="">
      <principal xsi:type="xf:currency" xml:lang="en-US">10000</principal>
   </loan>
</xf:instance>

<xf:input ref="principal" xml:lang="zh-Hant">
   <xf:label ref="instance('zh-Hant')/principal"/>
</xf:input>

The above xf:input would indicate that the view layer is in the locale 
zh-Hant, so a data layer currency value in the locale en_US would be shown 
as USD $10,000.00, whereas the following markup:

<xf:input ref="principal" xml:lang="en-US">
   <xf:label ref="instance('en-US')/principal"/>
</xf:input>

would only show $10,000.00 because that is how someone in the en-US locale 
looks at currency values that are in en-US format.

Anyway, this email seemed like a good way to get the discussion started so 
we can figure out how we could eventually offer this value at the XForms 
level consistently across implementations.  Please lets keep up the 
discussion on this.

Thanks,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
Received on Tuesday, 23 September 2008 16:35:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:49 UTC