Re: A decimal-string() function proposed for XForms 1.2

My reaction to this will be the same as always: more custom functions  
== bad ;-)

But if we *have* to have such a function now, there is no doubt in my  
mind that we must then integrate the XSLT 2.0 format-number()  
function. While we are at it, integrate format-date() as well. The  
XSLT 2.0 group already did the work for us so there is no need to  
reinvent anything. Orbeon Forms already provides these two XSLT 2.0  
functions it its XPath function library, because, well, there is just  
no way not to have them. On this point, I definitely agree with you:  
it is a very important feature to have. But we don't have to invent it  
ourselves.

A side note: I understand the argument about "waiting" for such and  
such features. There are lots of features that are currently not in  
XForms 1.1 and without which Orbeon simply can't live, including XPath  
2.0, dialogs, HTML text areas, and so on. I am sure every implementor  
can come up with a series of such features, and unfortunately it may  
not be possible to rush them all in at the same time as our resources  
are limited.

But implementors don't have to wait: they can implement extensions to  
XForms as they see fit. This is very positive as it provides the  
Working Group with real implementation experience, which is then  
leveraged to define a standard.

-Erik

On Dec 12, 2007, at 11:31 AM, John Boyer wrote:

>
> Hello all,
>
> One of the small features I proposed for 1.2 is a decimal-string()  
> function that can convert an XPath 1.0 number to a lexical string  
> representation that is desired by financial industry application  
> developers.  Nick comments that we'll get this in XForms 2.0 when we  
> have XPath 2.0.  For my own part, I wouldn't want to wait that long  
> for XForms to 'officially' support financial applications.
>
> I think it is not hard to have a function that receives a number and  
> an indication of how many places past the decimal point it should be  
> rounded to obtain a string output.  The only extra bell/whistle  
> would be to indicate whether or not zero padding is desired, which  
> is often done with a negative sign or some such.
>
> The lion's share of usage will be of the form decimal- 
> string('12.300000002', -2) to get a guarantee of two decimal places,  
> with zero padding if needed. The output in this example would be the  
> string '12.30'.
>
> Right now, the numeric results of calculations come out to  
> irritating values when converted to lexical representation for  
> storage in XML, and it becomes necessary to write code on the server  
> side to fix this stuff up before it goes into a database.  I do have  
> actual customers now for whom I am currently having to add an  
> extension function because the XML data we send chokes their  
> database, and they don't want to add code, esp. since it is contrary  
> to our "killer app" messaging.
>
> Now that there is some discussion on it, it seems worth breaking out  
> into a thread of its own to see if
>
> A) there are any other objections
> B) to see if I've managed to convince Nick yet :-)
>
> Cheers,
> John M. Boyer, Ph.D.
> Senior Technical Staff Member
> Lotus Forms Architect and Researcher
> 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
http://www.orbeon.com/

Received on Wednesday, 12 December 2007 21:54:29 UTC