Re: A sumproduct() function proposed for XForms 1.2

I like the idea, not of the sumproduct() function, but of smaller specs.

However, are we not bound by our charter to produce "big specs" for  
1.2 and 2.0?

I am thinking that if we could do this, then a good thing to work on  
would be a separate document, like an addendum to XForms 1.1,  
explaining how XForms implementors can support XPath 2.0 in XForms,  
everything else in XForms 1.1 being equal. This may be a faster way of  
pushing XPath 2.0 adoption in XForms than waiting for a big XForms 2.0  
spec.

-Erik

On Dec 12, 2007, at 1:37 PM, Mark Birbeck wrote:

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

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

Received on Wednesday, 12 December 2007 21:59:30 UTC