Question

My PHP application will need to be able to export to (and import from) a range of different data formats, mostly XML based.

I have the option of

• In PHP, use DOM to export to some XML based format that is a superset of all the data needed by the others, and create a separate XSLT stylesheet for each output format I want to support, running the DOM output through PHP’s XSL extension.

or

• Not using PHP’s XSL extension, but implementing each output format as a class in native PHP that translates directly from the internal objects/structures to a given XML format using DOM, each such class implementing the same interface so they are interchangeable.

The app will be used by universities and is a tool that manages ‘people’ records in various ways, and imports/exports from various sources like their HR system, etc. I’ll be implementing the set of input and output formats myself, but in future there is the chance that someone using it will want to modify it to support their own format.

One reason I’m considering NOT using XSLT is that if anybody else is going to maintain the app in future other than me, it seems that very few people even know XSLT – a lot more people seem to know PHP.

Another is that the second seems like a more efficient and ‘programmery’ solution, and more flexible in the sense that I’d be able to output to and import from non-XML formats like CSV or column based text just as easily by overloading the necessary parts of the class, not that that would often be necessary.

A third, but very small and insignificant reason is that PHP needs recompiling to enable XSL whereas DOM is enabled by default, so it would be a tiny bit more portable. However this isn’t too much of a problem as it’s easy to reconfigure PHP.

What do you think of my reasoning?

Answer 1

My personal opinion is that your decision should be based strongly on the fact how you’d judge the XSLT knowledge in your intended audience. If it’s clear that XSLT is somehow “terra incognita” among the people having to work with the system (that includes yourself), you can rule out the XSLT-solution. The need and the effort to learn XSLT will negate the advantages (very elegant – especially when transforming XML to XML, no need to mess with PHP code, no PHP knowledge needed) you’ll get from the XSLT-solution.

Perhaps a two-way solution could be the right thing to go with. You could build an adapter-system for importing and exporting that uses XSLT for the XML data formats and provides the ability to use PHP code for all the data formats that aren’t XML based. This way every developer can choose the way he’s more comfortable with.

interface My_DataConverter_Interface
{
    /**
          * @param string                $file
          * @return My_DataObject
          */
    function import($file);

    /**
          * @param My_DataObject $data
          * @param string                $file
          */
    function export(My_DataObject $data, $file);
}

abstract class My_DataConverter_Xslt implements My_DataConverter_Interface
{ /* ... */ }

class My_DataConverter_XmlFormat1 extends My_DataConverter_Xslt
{ /* ... */ }

class My_DataConverter_XmlFormat2 extends My_DataConverter_Xslt
{ /* ... */ }

class My_DataConverter_Csv implements My_DataConverter_Interface
{ /* ... */ }