W3C home > Mailing lists > Public > public-forms@w3.org > December 2007

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

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Wed, 12 Dec 2007 14:21:41 -0800
Message-Id: <A7A0C874-855C-435C-B552-311180AEF11C@orbeon.com>
To: "Forms WG (new)" <public-forms@w3.org>

My bad, yes format-number() was in XSLT 1.0 already.

format-date(), format-time(), and format-dateTime() are new in XSLT 2.0.


On Dec 12, 2007, at 2:14 PM, Ulrich Nicolas Lissť wrote:

> All,
> I was just writing a response along similar lines like Erik's  
> one ... So
> just a short cut.
> I don't see much value in adding more functions in general and in  
> adding
> a decimal-string() in particular. There is no decimal-string() in  
> XPath
> 2.0 (Nick ?). Instead, format-number() is there and is more  
> powerful. It
> is actually an XSLT 1.0 function and if we really want this, we could
> "borrow" it like we did with current().
> However, we have the extension function mechanism and it should
> therefore be easy to include any function for specific business  
> reasons.
> Regards,
> Uli.
> Erik Bruchez wrote:
>> 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/
> -- 
> Ulrich Nicolas Lissť

Orbeon Forms - Web Forms for the Enterprise Done the Right Way
Received on Wednesday, 12 December 2007 22:21:58 UTC

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