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

Re: A sumproduct() function proposed for XForms 1.2

From: Mark Birbeck <mark.birbeck@formsPlayer.com>
Date: Wed, 12 Dec 2007 21:37:33 +0000
Message-ID: <a707f8300712121337v12666709xe1ab00ab2e932db6@mail.gmail.com>
To: "John Boyer" <boyerj@ca.ibm.com>
Cc: "new Forms WG" <public-forms@w3.org>

Hi John,

These all look like good ideas to me. :) However, I'd like to make a
suggestion as to how we proceed with this.

>From my experience in the XHTML 2 work over the last few years, I
believe that there is little to be gained by thinking in terms of
'next versions' of enormous specs that take ages to produce. I know
you discussed this the other week on the telecon, and I apologise for
not being there--I saw in the minutes that Sebastian and yourself said
that it was easier to deal with one large specification.

But my response would be that even if it is easier (and I don't
believe it is, as I'll explain...but let's say for the moment that it
is) that is pretty irrelevant. Our concern should be the deployment
and adoption of XForms-related technologies, and if creating one big
spec is the best way to achieve that, then of course, let's do it. But
if it is not, we must be open to alternatives.

And the experience of XHTML 2 shows that it is probably not.

Although XHTML 2 is still not complete, many of the components that
make it up are, and are flourishing. For example, we factored RDFa out
of XHTML 2, and then developed it further in conjunction with the
Semantic Web Deployment Group. It is about to go to last call, has
been implemented widely, and is generally recognised as being the best
way to add metadata to XHTML (as a more substantial solution than
microformats).

Similarly, we took @role out and developed that further with the WAI
group. As a result it has been implemented already in Firefox, has
extensions in the form of ARIA (a spec from the WAI group), is being
added to SVG, and even HTML 5!

I could go on--access key, XML Events (originally from XForms), and so
on. My point--if I haven't banged you over the head with it already :)
--is that smaller specifications are easier to manage, are fertile
ground for cooperation with other groups, decrease the time to
adoption, increase the chances of being incorporated into other
specifications...and so on.

So, to finally get back to your post...I would suggest that first we
create an XForms function library, just like the function library that
XPath has. We then add a mechanism to XForms so that a form can
indicate which version of the XForms function library it supports, and
of course if the attribute or whatever we use is not present, then we
default to using this first library. That gives us essentially what we
have now, but created by using a separate specification.

Alongside this we create a "version 2" of this function library, and
add the functions that you are proposing here, and others. We could
also allow the mechanism that indicates which library to use to pull
in other libraries, such as EXSLT, some algorithms from Nasa, clinical
trials functions, etc.

Then with this flexibility, Nick doesn't need to use the new functions
if he doesn't want to!

I'd like to use the same technique for a number of things, and I was
thinking that to illustrate the concept we'd start with a simple,
standalone module, for XForms messages, and related features (hint,
help, message, alert, etc.). I think this module would be immediately
useful outside of XForms (who knows, it might even find its way into
HTML 5, like the role attribute has done ;) and I think I could have a
first draft of this done in early January, so that people can get a
fuller idea of how I'm proposing this approach might work.

What do you think?

Regards,

Mark


On 12/12/2007, John Boyer <boyerj@ca.ibm.com> wrote:
>
> Hello all,
>
> One of the small features I proposed for XForms 1.2 is a function called
> sumproduct() which takes the sum of the pairwise products of two nodesets.
>
> Nick responded that this function seemed a little odd because it was
> essentially calculating two results.  However, it is really only calculating
> and returning one result.  Moreover, that result can be determined using a
> single pass through the two nodesets provided.
>
> A quick web search for "sumproduct" will indeed show that this is a
> *standard* spreadsheet function.  The main point is that on spreadsheets,
> they actually allow more than two arrays.  The function accumulates the sum
> of the products of the corresponding elements in each of the arrays
> provided.
>
> I believe it is likely that this function will be needed for our no-model
> XForms development, and I am certain it is useful in forms today.  Here is
> an example:
>
> <group ref="/purchaseOrder/items">
>   <repeat nodeset="item">
>     <input ref="productName"> ...
>     <input ref="quantity">...
>     <input ref="price">...
>     <output value="price * quantity">
>        <label>Product Value</label>
>     </output>
>   </repeat>
>
>   <output value="sumproduct(item/quantity, item/price)">
>       <label>Subtotal</label>
>   </output>
> </group>
>
> You can see here that instance data was not needed for the row products in
> order to calculate the subtotal over the whole table.
>
> This is good because we don't want limitations of XForms to force people to
> write their data schemas differently.  A key message we have for XForms is
> that we provide interactivity and fill experiences for instances of schema
> defined by the data architect.
>
> For no-model XForms development, I think that the output control may not
> result necessarily in a data node in the implicit instance.  In this case,
> there would not be a row product value to refer to, which is analogous to
> the situation I created above by using a value attribute on the output in
> the repeat.
>
> Now that there has been some discussion on this, it makes sense to make a
> thread for it to
> A) find out if there are any other objections to adding this function
> 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
>
>


-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.
Received on Wednesday, 12 December 2007 21:37:55 UTC

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