XQuery on Rails
Rails (and similar frameworks like Seam, Grails, etc.) work by inspecting database schemas and dynamically generating code at runtime. They implicitly assume a SQL database, which isn’t really a good fit for most publishing applications. Sure you can slice and dice documents enough to force them into tables, but it’s a lot like pounding screws into set concrete with hammers.
Many publishing applications, especially generic systems like Wikis, content management systems, and blog engines, would be better served by a native XML database and XQuery; e.g. eXist instead of MySQL. What would a Rails-like system look like in this environment? What would the conventions (instead of configurations) be?
Is XQuery even capable of supporting this? After all, it’s only SELECT. Updates aren’t finished yet. Even more importantly, a lot of details like how you find collections are unspecified and implementation specific. It’s not really possible to write any XQuery code that queries a database without using DB-specific functionality.
Of course, it’s probably too early to design such a thing. We don’t have a lot of experience building sites on top of XQuery yet, though there are some examples. We probably need to build a few hundred more systems so we can see what we need before we try to automate the process. Right now we don’t even know what defaults make sense.
February 24th, 2007 at 11:06 AM
I’m working on it; I’m one of the team on the Zorba XQuery project, which will implement not only Update for XQuery, but also enough non-functional facilities to make it a fully usable programming language (blocks,
whileloops, exceptions). We just spent the last two days hashing out most of the design.February 24th, 2007 at 12:03 PM
Why would publishing applications be better served by XQuery / XML than SQL databases?
February 24th, 2007 at 12:29 PM
Because documents (books, articles, blogs, etc.) are better modeled as trees than tables. Neither’s a perfect fit, but trees work much better.
February 24th, 2007 at 12:35 PM
My thought was more along the lines of replacing the SQL part of Rails, not the Ruby part. That’s an interesting idea to though.
A little recognized but critical feature of Rails is that it does huge amounts of code generation. What code to generate is usually determined by reflecting on the database. My question is whether XQuery+XUpdate provides sufficient internal reflection capabilities to enable something like Rails (Quail?) to do all it needs to do, especially without resorting to database specific calls.
February 24th, 2007 at 12:52 PM
you could definitely do that in rails, just plug it into ActiveRecord, and the rest of the stack will be fine.
just a matter of being able to introspect the schema of the store, as you said.
February 24th, 2007 at 6:23 PM
Databases are multi-user and transactional. XQuery may be useful as an additional parsing support. Why does it’s mere existence qualify XML files as a Database? IMS did that in 1964. It was found wanting.
February 24th, 2007 at 6:59 PM
An XML file is not a database. But tens of thousands, maybe millions of documents inside one piece of software with query and index capabilities? That’s a database. The primary reason for XQuery is to move beyond single documents to collections of documents.
February 27th, 2007 at 9:11 AM
Xquery on Rails is already here: it’s the Exist XML-DB (has XUpdate) together with the Formfaces XForms processor on the client!
Have Fun ! Rusco.
April 3rd, 2007 at 7:10 PM
Interesting.
We (W3C work group) just got around publishing requirements for XQuery scripting extensions(http://www.w3.org/TR/xquery-sx-10-requirements/), and I am writing a draft specification. Everybody is welcome to submit suggestions.