By krahe on

We have all our website data stored in XML and looking for a cms that is XML compatible. It is possible to use drupal with a xml database? Typo3 is not very good for xml, so is drupal?

Comments

tomcalloway’s picture

tomcalloway commented

to this question. If it's not, I wonder how difficult it would be to extend Drupal to support an xml database.

I guess a good question is to define what "xml database" we're talking about here. Berkeley DB's embedded xml database or xml objects in a relational database like MySQL? Or do your data reside in flat xml files?

krahe’s picture

krahe commented

the data is stored in in flat files. we have coded a exporter which transfer plain html files to xml. it could be again exportet into a xml database.

what do you mean exactly with: "I wonder how difficult it would be to extend Drupal to support an xml database?"

Greetz,
-Jens

tomcalloway’s picture

tomcalloway commented

I wondered whether you were interested in this...or something else like it:

http://www.sleepycat.com/products/bdbxml.html

As you'll note in the discussions around the ongoing poll of databases, MySQL is the most popular. If you wanted to use something other than MySQL or Postgresql, it seems like it would require a certain amount of work to use it with Drupal. But I'm interested in options like the Berkeley DB, so that's why I mentioned it.

budda’s picture

budda
Primary language English
Location Cheshire
commented

Do you want to import the XML data in to a "normal" Drupal database such as MySQL or Postgres?

--
www.bargainspy.co.uk | More Drupal modules

--
Ixis (UK): Drupal support, Drupal hosting.

krahe’s picture

krahe commented

Best thing would be to leave it in XML. At best in plan files or in a xml database.

Heine’s picture

Heine commented

Then I guess the answer is no for standard drupal. See also System requirements.

the_other_mac’s picture

the_other_mac commented

I'm in the position of running a normal MySQL Drupal, and want to add some 3rd party content, which is made available to me as an XML feed. Two things occur to me:

1) surely this is an extremely common scenario?

2) aggregator.module already tackles the same task, albeit in quite a specialised way (lots of code handling RSS-specific functions such as expiry of old content.)

Aggregator works by (a crontab) fetching the XML into (MySQL) tables. I suppose it must, since otherwise we'd be hitting the servers of our RSS content-providers, each time someone loaded a page of our own website. The same logic applies to my own case; perhaps we can generalise that if the XML file is off-site, it's better to use an intermediate MySQL table. (Or Postgres, if that's your thing.)

Modules to handle these cases can probably reuse some concepts from aggregator. But whereas RSS has data fields like "Title" and "Author", my PHP will need to refer to "HINCLVAT" etc. I can't see any way of writing code that can be plugged-in by someone else. The database interactions can be handled with existing db_ wrapper functions, but that's about it. Apart from having a general approach, none of that could be reused by the next Drupaller (unless they were subscribing to the same data, obviously.)

It took me a few minutes to think of a plausible scenario for storing data locally as XML files, without also having a database that they came from. It's not actually very common... but okay, let's say your XML files are .XLIFFs(a multi-lingual document format used in the localization industry). So now you'll need a bunch of PHP functions for, e.g. reading the contents of the "glossary" element and outputting it as a link to the glossary. Which will be of little help to the next Drupaller handling XML-resume files.

What's the point of all this rambling? Well when your data is in SQL-type databases, it's nice to have a few wrapper functions to clean up your SQL-string, read field contents into arrays, and so on. When your data is in an XML file, the nearest thing I can think of to "wrapper" functions is, well, something such as XSLT functions in PHP, which you already have. I just can't think of anything useful that Drupal could add, as a general case.

Interested to hear other opinions...