|Do you know where your variables are?|
CSS Right, it wouldn't lose much for the discussion even should the CSS not included. It's just more complete as an example with one.
STATIC XML The static XML file is for the Artist (or Web/Frontend Designer) to be able to do the HTML markup with XSL without the Perl script even ready.
The static XML also serves as a req spec doc. In a working app, you probably won't have or need a static XML file sitting around. The XML will be generated dynamically from within a Perl script by then. But during the devel proc, it's good to have a static XML file against which to check your Perl's generated XML.
BOSS Sorry for not explaining the BOSS-XML part. A BOSS could be your Project Manager or System Analyst or Team Leader. Or, to read that relation another way, a BOSS-Client conveyed a req to your Project Manager to your Lead Programmer who came up with the XML.
No, a non-techie BOSS handling XML won't be a good idea.
HTML::Template Template is really a clean solution. Easy to use. It does the job of separating Perl and HTML. Especially nice when the same person who does both the HTML and the Perl. Not to hard for less technical Web designer to handle a Template either.
However, sometimes (or most of the times) a Template need to wait for a Perl script in order to see the complete HTML result. Hence, lacks the independency. XSL can check it against a static XML, not Perl script.
Also, when changes were made to both Template and Perl script simultaneously and something went wrong, you might need to check a Template and a Perl script against each other--an a bit more troublesome debugging process--whereas (in theory) XSL and Perl script check against XML (which is supposed to be locked/frozen).
Yet another situation, you need output to multiple media. A common req is that a client wants a report to be on the Web, as well as on PDF. (Well, refer to your phone bill, for example.) XSL makes a sensible solution, though I won't claim it's the best.
One more thing, you can't swap your "backend" (the Perl script) with Template. XSL doesn't care what backend you use.
Of course, if those are not your concerns, HTML::Template makes a good choice.
XML/XSLT NOT FUN I must say, XML does require more discipline than many Web development companies are willing to commit to. (Many organizations tried to come up with some XML templates and ended up nowhere.) No, XML/XSLT isn't fun. Neither is trying to make a "quick fix" to a live system, just because some client/account manager forgot some "minor" req.
The point is not so much about using XML as it's about thinking things through. It's a mixed blessing that you don't need much planning to code a PHP page, for instance. XML forces you to do a bit more thinking.
A FOOTNOTE Actually, to be more correct or "orthodox," when I said checking a Perl script's XML result against XML, I probably should or could have said DTD or Schema, in lieu of XML. But not everyone bothers with DTD or Schema. XML alone is an enough start.
In reply to Re: (jeffa) Re: XSL/XML/Perl as a development process