Elliotte Harold has published a nice introduction to XForms in Firefox on IBM developerWorks. In the conclusion he notes that:
Client-side XForms processing won't be possible for public-facing sites until XForms is more widely deployed in browsers. However, that doesn't mean you can't deploy it on your intranet today. If you're already using Firefox (and if you aren't, you should be), all that's required is a simple plug-in. After that's installed, you can take full advantage of XForms' power, speed, and flexibility.
I'd agree with this whole-heartedly. I wrote and deployed a little XForms application just before Christmas and it was a very painless exercise indeed.
Over the past few years we've rolled out an number of RESTful XML based APIs internally. We've also toyed with different ways to build tools to manage systems using these APIs, including using Java Swing desktop tools, simple HTML forms, etc. Mainly we've been trying for a while to find a sweet spot between ease of implementation and a reasonably good user experience.
Recently I'd been toying with a Javascript library to one of our REST interfaces based around the Prototype library. It was fun if occasionally frustrating banging my head against Javascript. However it wasn't finished and I needed to quickly roll out some forms for managing some key data. So I took another look at XForms. I'd researched it a few years ago and had rejected it because of the lack of browser support and the different ways that the plugins required you to deploy the forms.
As almost everyone internal has gravitated towards Firefox cross-browser support isn't a strong requirement so I went ahead and built the system using XForms. It was a very satisfying experience: the syntax is easy to get to grips with, and its possible to create some fairly slick AJAX style forms with a minimum of fuss. And more fun that messing with Javascript.
So for us at least XForms does seem to hit a sweet spot for rapid tools development, particularly as we already have a lot of existing XML interfaces. In fact the exercise highlighted a few flaws in our interfaces (e.g. delivering correct mime types, under use of "hypermedia" to link between resources in some areas) so was a good learning exercise in its own right.
It would be nice to see some slicker custom controls for different data types though. I think AJAX and client-side scripting still corners the market on slick dynamic UIs, and will do for some time. But for sheer ease of use, and getting things done, XForms gets the thumbs up from me.
Recent conversation at the Dodds Family Residence:
Martha (who is three): Mummy, I want to go to the hair dresser
Debs: OK
Martha: I want to have the straggly bits cut so I look more like a Jedi
Debs (to me): What have you done to my kids?!
I don't think its entirely my fault, but the kids have turned into complete Star Wars addicts recently. They're both imaginative and love role-playing. For example we spent most of November and December playing Scooby Doo for example (Ethan is Scooby and Martha likes to be Daphne).
I've not let them watch the Star Wars films as they're too young obviously. But I did get Lego Star Wars for the Playstation over Christmas, and have played it co-op with Ethan. With Martha watching. I'd highly recommend the game, btw. Its a very good game and well paced for younger players.
Using that uncanny ability of kids to hoover up everything they're exposed to they now both know all of the character names. So instead of sneaking around pretending to be Scooby and the Gang, Chez Dodds is now routinely the home of various Jedi battles with Ethan being Obi Wan Kenobi (and occasionally Darth Maul), and Martha being Padme or Queen Amidala. Or maybe invading Naboo or something.
Except that is when Martha wants to be a Jedi in which case she wants to be Qui-Gon Jinn. Its the long hair that does it.
So, yeah, I geeked the kids. Didn't mean to though!/
(Thought I'd share that one after reading Joe Gregorio's posting)
Quakr is a project to build a 3-dimensional world from user contributed photos, a.k.a. some friends having fun with geek hacking. I see they submitted an abstract to XTech too. The blog links to some interesting experiments mashing up Google Maps with a Flash and VRML viewer.
The Quakr 7D Tiltometer is worth viewing too if only for its sheer Blue Peter stylee "build this at home" excellence.
The "five things" meme is still doing the rounds and it turns out I've been tagged by Phil Wilson. So here's five things that you almost certainly don't know about me:
I'll try tagging Geoff, Pete, Kirsty, Dorothea, and iand to spread things around a little further (and in some different directions!).
"The dreams of XML hypertext are dead, or at least thoroughly dormant"
Simon St Laurent's XML.com article on XQuery is an interesting read. But I think the above statement is worth discussing. Is XML hypertext really dead? Or, if its dormant, is it going to remain so?
Firstly what is XML hypertext? I presume from the context of the quote that Simon is referring to client side use of XML on the web. To me this incorporates several use cases including both the use of XML for presentation (XHTML, SVG, etc) and for data publishing (RSS, Atom, XML based web services). There is an obvious need for linking in both of these use cases.
Where I'd agree with St. Laurent is that most of the existing work here is dormant or duplicated. For example while SVG makes use of XLink, its not used in RSS and Atom, and was deemed not flexible enough for use in XHTML due to issues with attribute naming. However the basic model, labelled links with activation indicators (onLoad, onClick, etc) seems to be shared across vocabularies. But still, XLink has been a Recommendation since 2001 and has yet to set the world on fire.
However where I'd disagree with Simon is that XLink or XML hypertext is thoroughly dormant. Much as I hate to make predictions, I think we're only just gaining any appreciation of the power of producing good hypertext, because we're only now seeing the large scale publishing of machine-processable, interrelated data that makes linking worthwhile.
I think growing appreciation of the REST architecture is driving a greater understanding of the benefits of highly linked resources. Sure, we all know its good practice to avoid making web pages that are "dead ends", but not everyone is publishing data to the same guidelines. The principle of "Hypermedia as the engine of application state" is still not widely understood; it's a piece of REST Zen that benefits from practical implementation.
Hypertext simplifies client-side development as it avoids spreading the requirement that the client must know how to construct URIs: this reduces coupling. It also simplifies client logic as "the navigation options" (i.e. state transfers) can be presented by the server as the result of previous interactions; the client can simply select from amongst the labelled options. For example if the client needs to access some specific data, e.g. a list of my recently published photos, it can select the appropriate link to retrieve (assuming its available).
That link may be to an entirely different service.
In an XTech 2005 paper I tried to argue (I suspect not very clearly) that linking offers the best route to integration of data from multiple web services. Linking as a means to easier mashing.
If the current data publishing trends continue then I suspect there's going to be a growing understanding of the benefits of hypertext and this inevitably drive some renewed interest in XLink or a related technology.
What I personally like about RDF in this regard is the "closure" it offers: every resource has a URI, every schema has a URI, every Property and Class has a URI so the data, metadata and schemas can be linked together, and this offers some very powerful capabilities.