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

I think I see better where you are coming from: you do not want this  
for presentation purposes, but for formatting data in an instance  
only. Is that right?

If so, then I agree that format-number() may indeed not be a good match.

The XPath 2.0 round-half-to-even() function seems a better match,  
since it can take an optional precision argument. However, it takes a  
numeric argument, whereas you propose a string. With XPath 1.0, this  
is hard to avoid, as a number type is a floating-point number, not a  
decimal.

My opinion on adding functions remains the same: I would rather fast- 
track to XPath 2.0.

-Erik

On Dec 12, 2007, at 3:52 PM, John Boyer wrote:

>
> 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/
>
>
>

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Received on Thursday, 13 December 2007 00:32:09 UTC