As the XForms working group gears up for our face-to-face meetings next week, I can't help but be energized by the selection of features we are working on for XForms 1.2 (http://www.w3.org/MarkUp/Forms/wiki/Category:XForms12).
If you have a look at the linked page, you can get an idea of the current feature pipeline as well as some initial text describing each feature. Here's some further commentary on selected features.
I look forward to improvements to the available XPath function library. This includes addition of functions like pattern() and replace(), which would simplify data matching and manipulation via regular expressions. This also includes functions like an XPath eval(), XML parse() and serialize(), and run-time XML node creation functions. However, this also includes increased capabilities in the area of user-defined XPath functions and even XPath variable definitions.
Speaking of extensibility, we've had huge success with XForms by extending the capabilities of the submission element so that it is easier to connect it to more kinds of services, like REST services, ATOM services and of course SOAP-based web services. Looks like two-way JSON communications are on the horizon.
As propeller-headed as it may sound, I'm looking forward to having the context attribute everywhere. It has proven very useful for the insert and delete actions, but it is really needed in other elements. Probably most notable would be the action element, to provide a common context to a sequence of actions. Similarly, I am really ready for it on the bind element as a way to mitigate having to type so many ../ sequences into calculate formulae. Next would probably be group, to impart context without attaching to model item properties like relevance. And, of course, the repeat element would benefit just from the standpoint of parity of expression with the insert and delete actions that amend the data to which the repeat table binds.
At the UI level, I look forward to the addition of the dialog element. 'Nuff said there. We also have a basket of features intended to beef up the capabilities of the user interface switch element. Most notable will be a declarative way of binding a switch to a data node that controls which case of UI controls presented by the switch. To me, this will complete the XForms story of letting the data drive the web application.
One of the hardest problem we have to solve is to tease apart the use of relevance versus switching in various kinds of user interfaces. Right now we have UIs that need to style non-relevant controls as disabled, and we have other UIs where relevance means the controls simply shouldn't be there at all, and still more UIs where something is non-relevant because it is not yet pertinent in a multi-step UI experience, or perhaps has already been pertinent and is no longer. Some of this could be solved by better recognition of the difference between a group bound to a non-relevant node versus a switch with selected and non-selected cases, but in current XForms we have equated non-relevant groups and non-selected switch cases, so we'll need to revisit that decision. Doing this work, though, will allow us to produce a very crisp UI control lifecycle and event model, which would improve the lives of advanced XForms authors.
Perhaps the only cooler thing we could do is define the XForms calculation engine in a way that does away with "rebuild" and makes it the XForms processor's job to dynamically decide when it needs to refresh to data model calculation binds, not just UI bindings. The trick, of course, is keeping performance in the linear or nearly linear order of magnitude. But, hey, that's why it would be cooler.
Well, clearly we have our work cut out for us!