[KLUG Members] Re: XSLT Transforms

Justin Buist members@kalamazoolinux.org
Mon, 13 Jan 2003 20:56:50 -0500


On Mon, Jan 13, 2003 at 08:37:28PM -0500, Adam Williams wrote:
> >A XSL tranform file that does this is attached.  The important bit is to
> >have two customer templates; one matches customer elements having
> >oem_discount elements, the other catches the rest.  The first template
> >includes the header html and should match for oem_discount.>
> ><xsl:template match="customer[oem_discount]">
> ><xsl:apply-templates select="oem_discount"/>

Hmmm... more elegant than my proposition.  Very much more in-tune with the
nature of XSLT too.  Congrats.
 
> Thanks, that was just the bit I needed.  This is great stuff.  With PHP
> 4.2.3's built in XML DOM object handling, and classes utilizing an ODBC
> connection to views defined in a database the logic to generate the data
> set is almost poetic.  Some of the most elegant code I've ever seen;
> immense functionality in a small amount of code and yet still very easy
> to follow and understand.  Then the XSLT turns the data into a viewable
> HTML file.  The layers of process couldn't be more clearly defined, and
> I can modify anyone of them without disturbing the layer above or
> beneath it.  This rocks!

I have to agree there.  My only experience with XML/XSL(T) for presentation
went absolutely wonderful.  The learning curve is pretty much linear, and there
is a weath of community support out there for it.  I'd love to see more HTML
applications being done in the format, as it would make it easier to "port"
the presentation layer over to new devices (ie: handhelds) without any re-work
to the backend code.  It's absolutely wonderful.  And you're right -- it's 
oh so elegant.
 
> If I used the XSLT to produce SGML (which unfortunately I don't know), 
> I would presumably then be able to produce HTML, Postscript, PDF,
> etc...?
> 
> Anyone want to give a presentation on SGML?

I might be very well showing my ignorance here, but isn't XML meant to replace
the much more structured SGML?  After all, you still need an SGML processor
to turn it into anything specific, and SGML isn't a layout language, it's
another mark-up language like HTML.  If you want to go PDF and PostScript with
your data in the future I'd look into making a stylesheet for your data that
went to XML:FO (well, they call it XSL:FO now).  I might have mentioned it on
the list before, but I can't stress it's elegance enough.  Plus, there's a nice
open-sourced processor for it at http://xml.apache.org/fop.  My last encounter
with it was at version 0.17 (v 0.15 to 0.17 made some good improvements), and
I can't imagine where it is now.  I'd like to play with it again if given the
chance.

Basically, you do something along theese lines:
XML + stylesheet1 == HTML
XML + stylesheet2 == XSL:FO + FOP == PDF or PostScript.

Once you're at the PDF and PostScript stage other print styles just flow
naturally from that, and can be transformed pretty easily.  Well, unless you
want to go to a Word Document.  Shame on you if you do. :)

Justin Buist