Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re: XML for databases?!?! YES!!! With XML, XSL, and SAXON!

by Mission (Hermit)
on May 24, 2002 at 13:10 UTC ( #169048=note: print w/replies, xml ) Need Help??

in reply to XML for databases?!?! Is it just me or is the rest of the world nutz?

For the longest time, I had a problem with the bloat that XML had in comparison to other text data formats (CSV, etc.) so I had a difficult time understanding how XML could be a benefit. More reading uncovered some really cool stuff that XML can do that is a benefit to the web world.

The ability to template web content (content management systems) is becoming a huge business. The concept is to separate your content (in this case XML) from the style (CSS) and from your design (a template.) Now the template concept can be with HTML::Template using XML::Parser or XML::Simple to extract, but I found a quicker way, and it was built into XML.

The template that you create is utilizing XSL (Extensible Stylesheet Language) which is a natural parser for XML and applying HTML to it's content based upon your XSL template. For any of you who have created TMPL files with HTML::Template, the XSL is almost identical to it, but you don't have to parse the XML and THEN walk the data through the template!!!

Although that discovery was neat, it didn't help much, since you still just viewed the XML in a browser window that supported XML, and then it automatically applied the XSL to it for the display. If by chance you didn't have a browser to view the XML, then you were out of luck. It was at this time that I thought about going back to HTML::Template, but then I discovered another of XML's tools... SAX (Simple API for XML). Actually if you do a search for SAXON, it is a small program that is an interface to the SAX. Essentially you:
saxon -o myhtml.html myxml.xml myxsl.xsl
Which can be run from a system command from Perl, so there is no issue. You can throw an output (-o filename.html) to make a html file then hand the program the XML and XSL files.

The benefit is that now everything is seperate and I've preserved my original data. I no longer have to walk back through my HTML trying to find my XML, and I didn't have to parse the XML myself. The XSL simply is a faster process than parsing and doing the HTML::Template.

For more information on the basics of XSL go here:
For more information on SAXON go here:

BTW: XSL is markup, but you will see mention of XSLT as well... it's simply the XSL Translation which is essentially processing the files. (Just to clear up any confusion.)

- Mission

Replies are listed 'Best First'.
Re: Re: XML for databases?!?! YES!!! With XML, XSL, and SAXON!
by ajt (Prior) on May 24, 2002 at 13:39 UTC
    Separation of content (XML files in an XML database) from templates (XSL-T files in an XML database) from presentation styles (CSS, JavaScript & DHTML) is one of the most powerful and useful things a content management and application server combination can do - see also Content management system recommendations? and XSLT vs Templating?.

    However from a Perl programmers perspective, you don't need to use an external standalone XSL-T engine such as Saxon, or Xalan (good though they both are). You can get your own application to do it it's self, directly or via a library, this is how Cocoon and AxKit and many other commercial systems do.

    From the perspective of a Perl user you can use Matts excellent AxKit framework, or his XML::LibXSLT module directly from within your Perl code. I use XML::LibXML to manipulate XML files, template them with XSL-T, and save the output as HTML files! See Mega XSLT Batch job - best approach?, (in answer to Tilly's question, in testing on a 1Ghz Linux box, from one 1Mb XML file I was able to create over 2000 HTML pages, and associated folders in under 30 seconds!)

    If used right XML is a very good tool, just remember it's not right for everything, no matter what some people say!

    Another humble 2p

Re: Re: XML for databases?!?! YES!!! With XML, XSL, and SAXON!
by S_Shrum (Pilgrim) on May 24, 2002 at 18:43 UTC

    Don't get me wrong...but all of what you mentioned can be done from flat-files...heck, even I wrote a script that allows me to multi-template & table my data from flat files (without the bulk of additional record and field tags). This is really only a concern when dealing with large data sources. The XML markup is a p.i.t.a. and incrediblely redundant.

    I'll check the page on Saxon guarentees that I'll convert though.

    Sean Shrum

      You can take tabulated data, and using one of many templating system you can generate something else from it. This works perfectly well, for many applications.

      If your source file is an XML file, you can have any kind of XML file you want, you can even verify it against an XML Schema or DTD (take your pick) should you want to.

      You can make a range of XSL-Templates to convert the XML file you have into another XML file. The Transformation always gives you a well-formed new XML (or XHTML) file. You can have a range of XSL-Templates for a range of devices, web browser, WAP phone, another server. If you want you can also use XSL-FO and generate a PDF file should you wish.

      Should you want you can pipeline one XML document into one round of templating after another, as each step always generated well-formed XML.

      XML, XSL-T, XSL-FO, DTD, XML-Schemas are all public standards, you can use a range of tools, on different operating systems, in different languages, and most of the time things behave the way you expect them to. Using one XML file and one XSL-template I can generate one HTML file on my Linux box and NT box, using Saxon, Xalan, LibXSLT or even MS-XML, it's pretty predictable.

      One of the key strengths of XML is that the coding and the content/templates are kept apart. By using XML, you can use any code you want, and any content and it works! As your team gets bigger it means that the coders code and the mark-up people mark-up.

      There is a good thread on templating versus XSL-T here: XSLT vs Templating? where people put many sound arguments for both sides. Matts in particular as a strong advocate of XML says many things that I could add here.

      I'm not saying that XML is the best solution, just that it's one solution, and for larger more complex applications, it's focus on flexible structures, and it's wide scale use, does make it the tool of choice.

      Update: Typos fixed, and XSLT link added

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://169048]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (5)
As of 2018-02-21 19:50 GMT
Find Nodes?
    Voting Booth?
    When it is dark outside I am happiest to see ...

    Results (287 votes). Check out past polls.