atom feed2 messages in org.w3.public-formsHandling currency values in XForms
FromSent OnAttachments
John BoyerSep 23, 2008 9:34 am 
Erik BruchezSep 23, 2008 5:33 pm 
Subject:Handling currency values in XForms
From:John Boyer (boy@ca.ibm.com)
Date:Sep 23, 2008 9:34:30 am
List:org.w3.public-forms

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.

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw