The announcement I saw said: A discussion in the WSCCI and Services groups is looking to standardize how we represent nodes and other entities in JSON or XML form.
They offer these justifications:
- Including entities in exported configuration, or in configuration files.
- Taking a content snapshot in some form other than an SQL dump file (which, you know, kinda sucks for mose uses).
- Transferring a node from one site to another for content sharing purposes.
- Aggregating content from many sites together for improved searching and cataloging.
- Exposing Drupal content to other non-Drupal systems. This is made easier by using non-Drupal-specific formats.
This is great. This is one of the things in Drupal which has rubbed me the wrong way for years. That there isn't a standard export/import. It's all great and wonderful that the data we've stored in our Drupal websites is in a database, that everything is documented and visible as open source software, but the situation we have is one where our data is entrapped inside Drupal. Yes it's possible to write code to extract our data from Drupal, but that introduces a lot of friction into what should be a frictionless-no-effort operation. Namely, exporting or importing content to/from a Drupal site.
An example of an attitude that I believe is correct is Google's Data Liberation Front - http://www.dataliberation.org/ - where their goal is "to make it easier for users to move their data in and out of Google products."
One of the things that website suggests is -
... we always encourage people to ask these three questions before starting to use a product that will store their data:
- Can I get my data out in an open, interoperable, portable format?
- How much is it going to cost to get my data out?
- How much of my time is it going to take to get my data out?
With the ideal answers being:
- Yes.
- Nothing more than I'm already paying.
- As little as possible.
Drupal is a "product" (well, open source content management system, the word "product" isn't quite right) that stores our data to display on websites. If we apply those questions to Drupal it would be:-
- Not really.
- Depends on whether you're a coder. You may have to hire a programmer.
- Possibly quite a lot of time.
That much covers export of data from Drupal. That is, you can write some custom code to export Drupal's data in any format you like. And there are some modules that exist that might do what you want, but probably do not.
The other side of the equation is importing data. Again there are sometimes modules to do this, but often they're not really all that helpful.
Finally there's a couple kinds of data to be concerned about. Some of it is the configuration settings and there has already been quite a bit of work on that front, because some shops have multi-stage deployment practices and export modules (features) and configuration data from development to staging to production servers. But what about the content?
For an example of a "product" where the Data Liberation guys have done their magic, consider the Blogger platform. I have a few blogs hosted with Blogger and the other day I wanted to merge the content from several of these blogs together to form one blog. If these blogs were on Drupal I'd be saying UGH and frustratedly either launch into a conversion script, or else just throw up my hands and go on to some other project that has an actual chance of being done. But because of the Data Liberation guys this was trivial on Blogger.
The steps were:-
- Create new blog
- For each of the old blogs, export the content using the export button in the blog settings
- On the new blog, import each of the exported files
It was trivial and even preserved the URL's so that setting up redirects were real simple.