Last night, I was working on a little demonstration project, teaching myself the intricacies of Backbone/CouchDB interaction. I wrote my first CouchDB views and figured out what they're for, which is a massive step toward world domination and all that. I was working on the retrieval layer, and thinking about the create/update features, when I said to myself, "Hey, Self, can you use that sexy new RDFa stuff to handle the create/update feature?"
I've been thinking about this because I have a different project that's very RDFa-heavy, and the details of implementation have been challenging. But no, I had to come to a different conclusion:
RDFa and Backbone.js are incompatible.
These are two completely different approaches to managing data on the client. Both are valid. And both have their uses, but for the moment they don't mesh well.
"If you have an idea and publish it on the internet, it counts as the ghost of done."
So here's my ghost:
We need a Backbone-like for RDFa. RDFa cannot easily be coerced into working with Backbone, but let's face it: there are only a few things we work with on the internet: text and inputs, and lists and trees of text and inputs.
It ought to be possible to formalize a backbone-like collection of Views, Schemas and Rules, such that the transition from presentation to revision is seamless and perhaps not even distinct, and synchronization for a range of RDFa-enabled articles, forms, fieldsets, and the like is automagical. In other works, make Models and Views "know" about their data because it's already present in the HTML, and not the other way around. It's the transition from page-format to server-side format that's the pain point.
Hmm. This needs more thinking.