I’m happy to report that Ruby on Rails not only offers a comfortable way to develop web applications, but that a little-noticed feature makes some formerly theoretical open approaches to XML much more immediately practical.

I’ve been digging deeper and deeper into Rails, concluding that after many years of frameworks offering me more headaches than benefits, Rails finally provides enough good for me to think it worth using a potentially constraining framework.

Much of that benefit comes from the RESTfulness that had been creeping into Rails for a long while, and really gelled in Rails 2.0. map.resource is an incredibly powerful way to simplify RESTful development, especially when combined with the default handling in the scaffolding. Rails’ support for REST in HTML may cheat a bit with hidden fields - whatever. Rails makes it hard for me to even consider writing an app without RESTful foundations at least - they’re powerful, and it’s really that easy.

Beyond the smart support for REST, Rails also reaches a watermark in regards to the XML that I spent so many years on. Back in 2001, I’d gone looking for XML tools for Ruby, and what I found wasn’t enough to keep me working in Ruby. (I should have - working in Java was completely silly for the kinds of projects I was doing then, and Ruby would have been a much better fit.)

Today, by default, Rails scaffolding does something really simple for XML: it lets you avoid thinking very hard about the XML coming in and going out. Now, I know, you could if you wanted create Builder templates that let you ensure that all of the XML going out was perfectly structured according to this or that specification, but you don’t have to. The foundation there, in the scaffolding, is:

format.xml { render :xml => @person }

That call to render will generate XML based on whatever happens to be in the @person object. The developer’s control over that rendering comes from their work within Rails on the @person object, thanks to ActiveRecord and data migrations. During the development process, and to a (usually) lesser degree in deployment, that object, and hence that XML, is going to change on a regular basis. There is no schema locking the XML representation down.

No schema? But won’t that produce errors? It depends on how you write your software. If you really want to lock down your expectations of what’s coming across the wire, and refuse to process a slightly different (probably extended) structure for an XML document, this will drive you crazy. If instead you’re willing to be more flexible, accepting that some pieces of a document from yesterday may come and go today, you can write code that tolerates such variation, reporting an error only when a critical piece of information goes missing or weird.

Rails’ RESTful scaffolding also accepts XML documents coming in through PUT or POST. Again, it’s not advertising a formal schema (by default, anyway). Instead it seems to be doing something like Examplotron - look at a sample document, see what’s there, and imitate it.

Rails can get away with this for a couple of reasons. First, the type system within Rails is extremely simple, and not that hard to specify within documents. Second, Rails has a pretty thorough understanding within the framework of how data flows - all that ActiveRecord goodness ensures that Rails knows what’s supposed to be in the data, and makes it more comfortable sending and receiving without an external set of checks.

Perhaps my favorite part of this approach is that a lot of developers are fixated on the HTML side of things, but the scaffolding generates the XML side too. It comes for free. Left as it arrives, it’s an opportunity to open a much wider set of services to XML manipulation, at zero cost to developers. (Well, except for some potential surprise if and when people start using their services that way.)

It’s taken a decade, and the Rails models are pretty much data-centric rather than the documents I love working with - but we may finally be reaching the point where XML is starting to behave the way Walter Perry said it should, unconstrained by data structures negotiated in advance. If something changes or comes in wrong, that’s an opportunity to talk, to explore something new, not a reason to turn sullenly away from processing.

(I’ll eventually be exploring ways to extend how Rails accepts incoming XML to push this further, but outgoing is a start!)

If your goal is blind processing that works without perpetual tinkering, this post probably has you shaking your head violently. If, however, your goal is continuous improvement of carefully-monitored processes, Rails provides an opportunity to extend the iterative model that Rails developers typically do on the server side to the broader world of interconnected networks, to drive based on the signs on the road.

REST’s limited number of verbs produce a new flexibility for those of us specifying nouns, and the approach Rails’ creators chose here offers developers a tremendous amount of freedom, should we choose to use it.