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

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

From: John Boyer <boyerj@ca.ibm.com>
Date: Wed, 12 Dec 2007 15:52:00 -0800
To: Erik Bruchez <ebruchez@orbeon.com>
Cc: "Forms WG (new)" <public-forms@w3.org>, public-forms-request@w3.org
Message-ID: <OF5F3AA546.282EF88B-ON882573AF.007FEA3D-882573AF.00831A39@ca.ibm.com>
Well, there were two reasons why the XSLT format-number() function was not 
proposed:

1) It is an "output" or "presentational" function, so it is massive 
overkill compared to what XForms needs, which is a "data" function.  It is 
also, frankly, a mismatch.

The format-number() function can be a lot of work if you are trying to 
implement XForms in something other than Java, e.g. Javascript.  The 
format-number() function is connected localization services that decide 
things like what should the grouping separator or decimal separator be 
and, I think, what digits to use to represent the number.

None of that is needed.  We need a much smaller and more direct things. We 
just need to be able to easily modify the lexical string in the XML that 
gets presented to back-end processors of XForms submission data. 

In particular, we need something that produces a result guaranteed to 
still be compliant with xsd:decimal, and format-number() doesn't do that. 
We only need to be able to restrict the number of places past the decimal 
point to a specific number, with rounding and zero padding. 

2) Proposing format-number() immediately opens the door to all manner of 
presentational characters in our data, including results from 
format-date() and format-time().  Again, we don't want all this heavy 
end-user presentational formatting in our data, in part because it binds 
XForms data processing to a localization engine. 

I have a lot of experience, unfortunately, with the grief that can come 
from this.  For example, it does not take people long to want to calculate 
further results over the formatted "data", so you then need parsers for 
every possible format output so you can get back data that can be used in 
calculations.

Generally, we have to be a bit careful here because XPath/XSLT are not  a 
perfect match for XForms because XSLT is about output and XForms is about 
data processing.

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





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
12/12/2007 02:21 PM

To
"Forms WG (new)" <public-forms@w3.org>
cc

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







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

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

-Erik

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
http://www.orbeon.com/
Received on Wednesday, 12 December 2007 23:52:32 UTC

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