This year’s Balisage conference was preceded by the international symposium on Native XML User Interfaces, which naturally enough centered around XForms.
As someone who’s written multiple articles surveying XForms implementations, I have to say that it’s fantastic to finally see one break out of the pack. Nearly every demo I saw in Montreal used XSLTForms if it used XForms at all. And yet, one participant I conversed with afterwards noted that very little that transpired at the symposium couldn’t have been done ten years ago.
It’s safe to say I have mixed emotions about XForms. One one hand, watching how poorly the browser makers have treated all things XML, I sometimes muse about what it would look like if we started fresh today. If we were starting anew, a namespace-free specification might be a possibility. But with  XForms 2.0 around the corner, it’s probably more fruitful to muse about implementations. Even though XSLTForms is awesome, I still want more. :-)
- A stronger JavaScript interface. It needs to be possible to incrementally retrofit an existing page using POHF (plain old HTML forms) toward using XForms in whole or in part. We need an obvious mapping from XForms internals to HTML form controls.
- Better default UI. I still see InfoPath as the leader here. Things designed in that software just look fantastic, even if quickly tossed together.
- Combining the previous two bullets, the UI needs to be more customizable, and easier so. It needs to be utterly straightforward to make XForms parts of pages fit in with non-XForms parts of pages.
- Rich text: despite several assertions during the week, XForms can actually handle mixed text, just not very well. One of the first demo apps (in the DENG engine–remember that?) was an HTML editor. The spec is explicitly designed in such a way as to allow new and exciting forms widgets, and a mixed-content widget would be A Big Deal, if done well.
- Moar debugging tools
During the main conference, Michael Kay demonstrated Saxon-CE, an impressive tour-de-force in routing around the damage that is browser vendors’ attitudes toward XML. And though he didn’t make a big deal of it, it’s now available freely under an open source license. This just might change everything.
Curious about what others think here–I welcome your comments.
-m
Thank you for this blog entry!
XForms 2.0 will be soon a recommendation and, even if implementations are not fully compliant yet, you are not the only one thinking about XForms 3.0.
XQuery as a script language for actions might be the best deal for some developers but I agree that Javascript integration can be more important for a wider usage, wider than by Balisage speakers ;-)
AngularJS approach might be more than inspiring for XForms next version.
I am now thinking of an integrated design mode in XSLTForms allowing authors to just give an instance example, in XML or JSON, and, then, directly edit text labels and alert/hint/help messages within the generated form.
Sorry about the Rich Text Editor widget, implementations already have some but the W3C Work Group didn’t have time enough to package it in XForms 2.0.
Unfortunately, there is no template mechanism in XForms like in Saxon-CE. The declarative bindings in XForms are clearly powerful and implementing the corresponding engine with Saxon-CE might be challenging. BTW, I’m afraid that so many HTML authors won’t never be able to write any XSLT code…
-Alain
Is common these days to see many fast spreading trends, which also pass as fast as they come. But some ideas are so transcendental that the human mind takes years in order to widely accept them. For example, OOP was an idea born in the 60’s, but only until the 90’s it became a generalized practice.
Many people used to think of XForms as a failed technology (or the whole XML technology), because it hasn’t been implemented as fast as HTML5, but HTML5 is not a huge leap, is just like upgrading from FORTRAN to COBOL.
XForms (and all XML technology) is so disruptive (like jumping from COBOL to Java, just to compare), that took a decade to get a fully functional runtime and real applications to show its benefits. And to probe that it has been an excellent idea from the beginning, other “frameworks” are now stealing ideas from its foundations (i.e. AngularJS).
There is still some work left for the W3C XForms committee (mixed content and new ways of selecting are my candidates), but the big work to be done now is for us, the XForms adopters community: more documentation, samples, blog posts, tutorials and many other tools to help new adopters to get into this train.
I’m sure there are a lot of wise guys looking for the way to build their applications the right way, and are just expecting to see as many aids as those provided for getting on the “easy” trends.
– Bill
HI Micah,
thanks for your thoughts. Actually they mirror quite a lot of what we think at betterFORM. If XForms started today i would like to see it more integrated with standard HTML5 – lets face it: the abstract UI concept of XForms was a great invention back when it was specified. Today HTML has completely conquered the world and there’s hardly a device not capable of HTML. The mapping between abstract XForms markup and HTML (or JavaScript) controls has lead to some of the unlucky effects with styling and interaction between the XForms and the surrounding world.
Further the main problem of XForms is that it requires authors to learn a complete new language and that this language does not align very well with the knowledge people already have. In a real-world application XForms will only play a part (besides UI logic, navigation etc.) and therefore it should be easy to be pulled in when the time for complex form logic comes.
At betterFORM we are working on a complete different approach for our next major release which will not put XForms in the center any more. Instead it should be possible for the web developer to just use XForms when time for some form processing has come. That means a. providing a complete JS API for XForms as well as an annotated approach which enhances standard HTML elements with XForms functionality.
This will also address the styling issues as developers can continue using their favorite tools and libs and don’t have to change their complete development approach.
Joern
Yeah, I remember the DENG engine…
Minor comment on the “namespace-free specification”: there is no W3C police to prevent you from using XForms elements and attributes without a namespace ;) I think that is even be perfectly in line with the intent of XForms.
On the XForms/HTML forms convergence: there was a serious initiative in the Working Group to move XForms in that direction a few years back:
http://www.w3.org/TR/XForms-for-HTML/
Probably due to lack of time, this particular spec was never completed.
Also, at a smaller granularity, several attribute conflicts between XForms and HTML have been removed over time, and even better, the semantic of HTML attributes has been imported, including the “target” (submission, load) and “accept” (upload) attributes.
I confess that I had doubts that it was worth pursuing regular web developers. I think that XForms has other qualities that make it useful in the context of large and complex forms independently from the level of familiarity with HTML forms.
But I do think that it would be a net positive for XForms to converge more towards HTML forms, given the human resources. Because that is really the *only* problem: finding people interested and willing to work on it.