- From: Mark Birbeck <mark.birbeck@formsPlayer.com>
- Date: Wed, 12 Dec 2007 21:37:33 +0000
- 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