Import/Export with other CMSs?

Events happening in the community are now at Drupal community events on www.drupal.org.
nedjo's picture

[Some questions/suggestions that are kinda late in the game, but coming from research I've been doing today....]

To what extent is this API intended to facilitate data exchanges between Drupal and other CMSs?

Have you seen the Portable Site Information PSI specification, http://psilib.sourceforge.net/? It sets out a generalized XML interchange format for CMS data (and provides some tools written in Python). Would it be useful to consider this as a basis for the Import/Export XML format?

A potentially useful reference is the Exorcist softare produced as an offshoot of the Midgard CMS, http://www.midgard-project.org/documentation/exorcist/. It provides a general toolset for data exchanges between CMSs (in Java).

Following that approach, it might be feasible to write a general PHP framework around a common encoding (maybe PSI), and then write export and import include files for Drupal. That way the code could be used by other CMSs and adding CMS support would require only adding the include files.

Comments

Interesting

Jaza's picture

Thanks for pointing me out to these resources, Nedjo - I hadn't heard of the PSI spec, or of Exorcist, before now.

To what extent is this API intended to facilitate data exchanges between Drupal and other CMSs?

This is definitely not the primary application that I have in mind for the API. Considering that there is very little in the way of generally-accepted standard formats for data entities between CMSes, my opinion is that it's more practical to focus on how the API can be used within Drupal. Possible uses within Drupal include an easier backup/restore process, migration between staging and production sites, transfer and merging of data between multiple live sites, and of course, easily importing to and exporting from simple text formats (such as flat CSV files).

Have you seen the Portable Site Information PSI specification... Would it be useful to consider this as a basis for the Import/Export XML format?

From looking at the PSI spec, it seems that it takes a very different approach from what I've developed so far, with the API's XML import and export engines. PSI defines its own DTD and schema, which has certain fixed elements and attributes (e.g. 'collection', 'resource') that must be used in certain situations, in a certain hierarchical fashion. The API (as I've developed it so far) does not define a DTD, and does not have a fixed XML schema at all. The names and the structure of the XML tags are determined completely by the module-defined data definitions, and as such, they are completely flexible.

Also, XML is only one of several formats that the API will support (and new engines can be written by other modules, to support additional formats). Although XML is probably the most important and the most useful format that will be supported, I don't wish to tie the API to XML or to any other format.

the psilib project still looks like it's in the early stages, although it has been around for a few years - seems to me that it's not being very actively developed at the moment. The PSI spec that it's based on isn't very widely talked about - for example, a Google search for "portable site information" brings up a mere 314 results. What's more, it doesn't even have a Wikipedia article. Apart from Midgard, are there any other CMSes that make use of PSI? I would be interested to see if it's been adopted elsewhere in the CMS world.

A potentially useful reference is the Exorcist softare produced as an offshoot of the Midgard CMS

Exorcist looks like a very useful tool, but it seems that it is still new and under development. Also seems to be based around data exchange using PSI. Will have to have a look at it in greater detail before commenting further.

Following that approach, it might be feasible to write a general PHP framework around a common encoding (maybe PSI), and then write export and import include files for Drupal. That way the code could be used by other CMSs and adding CMS support would require only adding the include files.

Writing the API as a separate PHP application/framework, independent of Drupal, is an interesting idea. It wouldn't be particularly hard to do, because the API doesn't depend a great deal on Drupal functionality for what it does. At the moment, the module implements a few of the basic Drupal hooks, and it uses Drupal's DB abstraction layer for its DB 'get' and 'put' engines. But apart from that, it basically goes off and does its own thing. If other CMSes wanted to use the API, they'd probably have to do very little, apart from supplying their own data definitions. I will certainly look at breaking the API away from dependence on Drupal, further down the track. But for now, it's easier to focus on developing it within and on top of the Drupal framework.

Jeremy Epstein - GreenAsh

Jeremy Epstein - GreenAsh

Content migration, import, and export

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: