'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... 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... 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...