- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Fri, 14 Dec 2007 11:19:11 -0800
- To: "Forms WG (new)" <public-forms@w3.org>
All,
Nick's comment about functions echoes some thoughts I had as well.
Adding new standard functions for each piece of reusable functionality
we may think of will only yield a huge library of functions, and I am
more than uneasy about doing that.
Allowing form authors to define their own XPath functions like XSLT
2.0 or XQuery 1.0 does would solve this problem very nicely in many
cases, by providing reuse, yet not clogging the spec.
-Erik
On Dec 14, 2007, at 1:13 AM, Nick_Van_den_Bleeken@inventivegroup.com
wrote:
>
> Hi John,
>
> I've included my response in-line.
>
> public-forms-request@w3.org wrote on 12/13/2007 10:51:37 PM:
>
> >
> > Hi Nick (and Erik),
> >
> > The uneasiness about adding a feature in one release which is
> > "useless" in the next release must be tempered by the understanding
> > of what "next" means in this case.
> >
> > XForms 2.0 is a *major* revision over 1.x. It is going to happen
> > that we add features to 1.x that are not as useful in 2.0. Agreed
> > that we should be minimalist about it and agreed that such features
> > should at least not conflict, at realistic best be aligned with 2.0
> > capabilities. But we have to be careful about being too rigid. If
> > we have a limitation that causes problems for a vertical industry,
> > and there is a straightforward fix, then we need to be responsive.
> >
> > So, one reason we need to be responsive is to increase XForms
> > adoption velocity. In the case of a simple obstacle, easily
> > removed, the ability to capture greater market share in the
> > financial industry is more valuable even if it were true that
> > decimal-string() were not valuable once we have XForms 2.0.
> >
> > Another reason is to be more responsive, though, is that XForms 2.0
> > is a *major* revision, and I suspect XForms 1.x will have value
> > longer than the moment XForms 2.0 becomes a recommendation.
> > Consider, for example, how hard it will be to create that Javascript
> > implementation.
> >
> > Next, for technical reasons I am unable to access the W3C right now,
> > so let me ask this: Does XPath 2.0 still allow you to operate over
> > the double numbers, e.g. with the right typecasting or schema
> > datatype assignments?
>
> Yes it does it has the following numeric types:
> - xs:integer
> - xs:decimal
> - xs:float
> - xs:double
>
> And the resulting type of the arithmetic operators are define in the
> spec
>
> >
> > If so, is it known whether math calculations are faster with double
> > numbers than with decimal numbers? Gut feel is that they are
> > faster, and if so, then I think we have a use for decimal-string()
> > even in XForms 2.0.
>
> If you want to do math calculations in with doubles (or any other
> numeric type) if you want, and the do a cast to type decimal
> followed by a call to round-half-to-even() which can then be
> converted to a string.
>
> >
> > Finally, I don't think round-half-to-even() does the job because we
> > need a string output from the function not a numeric one. In
> > particular, we need a string with a guarantee that the decimal
> > string has two digits past the decimal point, even if zero padding
> > is required to make it so. Requiring XPath 2.0 to get this simple
> > behavior is like requiring a hammer to drive a thumb tack. It'll
> > work, but it's overkill and you may just hurt your thumb in the
> process.
> >
>
> Ok, now I see your point the 'padding' of the canonicalized
> representation of the decimal will require a 'string-join', 'for',
> 'substring-before' and 'string-length' which you don't want to
> repeat for each occurrence where you want the 'decimal-string()'
> function.
>
> If you were doing this in XQuery or XSLT you would define your
> custom function for this. You would do the same to solve John's
> other proposed aggregation function sum-product. Maybe we need to
> consider adding this functions to XForms 1.2 and define (or reuse
> from another spec) a way to define your own custom functions in an
> XForms document. And (like in XQuery 1.0 and XPath 2.0 Functions
> and Operators) maybe have an appendix with common used example
> functions. This will enable the addition of custom functions in a
> cross processor way without the need to clutter the XForms spec.
>
> > 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
> >
> >
> >
>
>
> Regards,
>
> Nick Van den Bleeken - Research & Development Manager
> Inventive Designers
> Phone: +32 - 3 - 8210170
> Fax: +32 - 3 - 8210171
> Email: Nick_Van_den_Bleeken@inventivegroup.com
>
>
> <<End of response>>
>
> >
> > Nick_Van_den_Bleeken@inventivegroup.com
> > Sent by: public-forms-request@w3.org
> > 12/13/2007 02:34 AM
> >
> > To
> >
> > Erik Bruchez <ebruchez@orbeon.com>, John Boyer/CanWest/IBM@IBMCA
> >
> > cc
> >
> > Forms WG (new) <public-forms@w3.org>
> >
> > Subject
> >
> > Re: A decimal-string() function proposed for XForms 1.2
> >
> >
> >
> >
> >
> > If I may quote my initial response and the try to explain it a bit
> > more (most of the things are already said in the thread now):
> >
> > "I don't think we should do it on a version of XForms that is based
> > on XPath 1.0, because it is automatically solved when we go to XPath
> > 2.0 and and all calculations in XPath 1.0 are done in double-
> > precision 64-bit format IEEE 754"
> >
> >
> > The two main reasons why I don't like to add it to the standard
> > function set of an XForms version that is based on XPath 1.0 are :
> >
> > 1) XPath 2.0 introduces the decimal type and it has the
> > round-half-to-even() function [1] which solves the use case of
> > decimal-string() and can even be used in calculations (you can still
> > do arithmetic calculations with the resulting decimal).
> >
> > 2) I don't like adding functions in a release who become useless in
> > the next release (XForms 2.0 will support XPath 2.0)
> >
> > Regards,
> >
> > Nick Van den Bleeken - Research & Development Manager
> > Inventive Designers
> > Phone: +32 - 3 - 8210170
> > Fax: +32 - 3 - 8210171
> > Email: Nick_Van_den_Bleeken@inventivegroup.com
> >
> > 1 : http://www.w3.org/TR/xquery-operators/#func-round-half-to-even
> >
> > public-forms-request@w3.org wrote on 12/13/2007 01:31:42 AM:
> >
> > >
> > > 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/
> > >
> > >
> > Inventive Designers' Email Disclaimer:http://
> > www.inventivedesigners.com/email-disclaimer
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
>
>
--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/
Received on Friday, 14 December 2007 19:19:37 UTC