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

Re: Handling currency values in XForms

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Tue, 23 Sep 2008 17:33:33 -0700
Message-Id: <300DC6AC-7868-4EA2-B74B-52A3AEB1598C@orbeon.com>
To: Forms WG <public-forms@w3.org>


Some good thinking. We could clearly go with a new built-in datatype,  
but maybe we should consider the more generic issue. In particular,  
the question of localization applies equally to date, time, and  
dateTime, so I would consider solving this question separately.

Now besides that, what is really being achieved here is decoupling the  
data is stored in the instance vs. the data presented/entered by the  
user. You have two transformations:

1. Formatting the instance value for display to the user
2. Formatting the value entered by the user for storing into the  

One possibility is to use XPath to specify transformations both ways.  
XPath 2.0 and XSLT functions like format-dateTime() and the likes take  
you pretty far. (This is what we do in our implementation for  
xforms:output, but we do not have a very satisfactory solution for  
xforms:input yet.)

A few more ideas:

* The transformations used could be determined by the datatype.
* If only the datatype is used to specify the transformations, then a  
currency datatype is probably needed.
* If there is another way of specifying the transformations, then  
xs:decimal may be enough for currency.
* A higher-level field format may be desirable so that input masks can  
be implemented.


On Sep 23, 2008, at 9:34 AM, John Boyer wrote:

> 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

Orbeon Forms - Web Forms for the Enterprise Done the Right Way
Received on Wednesday, 24 September 2008 00:34:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:31 UTC