My PHP app needs to export to a range of different XML formats: should I use XSLT or native PHP?

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

I think your reasoning is sound and it's the way I would go as well.

Basically what you're talking about are bridge/adapter/facade classes. They are (imho) more flexible and easier to understand than XSL templates.

The third reason isn't really one because XSL support involves nothing more than uncommenting a PHP extension.

I'm also glad to see you want to do this via the DOM extensions (or equivalent library) rather than writing XML as text, which introduces all the escaping issues and whatnot you'll avoid your way.

Personally I also think that XSL templates are more fragile to change (by virtue of them being somewhat more cryptic to the vast majority of programmers) so if your superset format ever changes (which, let's face it, it will) you'll potentially need to change all your templates. Of course you may have to do this with code too but code will probably be easier to maintain.

Answer 2

Interesting problem.

Both solutions will work, I guess you know this however.

I would probably go with the coded solution myself. But thats probably to do with XSLT giving me a headache.

There is an upside to XSLT and that is you can ask for them to be produced by the people giving you the unaltered XML..

If it is always you going to be producing them then it probably doesn't matter and coded solution will be easier to maintain most of the time.

Answer 3

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
{ /* ... */ }