On Wednesday, June 26, 2002, at 09:05  AM, John Holmes wrote:

> I disagree. Maybe I'm just not getting it, or understanding the "FULL
> POWER" of xml/xslt. It just seems like it's adding in an additional
> layer that you don't need. It seems so dependent on browser versions,
> and parser versions, etc. Just make a plain HTML template and a small
> template parsing script to insert the variables you need. Pattemplate is
> pretty close to XSL, but I haven't seen any speed comparisons on it.

Yeah, but what if you want to output to a format other than HTML?  For 
instance you want to generate a PDF invoice, which is emailed to the 
user, but you also want to display that invoice to the user?  Should you 
have two separate files/sources of data?  You could have one XML file, 
and use XSL to make an HTML document which appears in the user's browser 
and a PDF which is emailed to them.

The point of XML is to look beyond the web browser as a point where the 
user needs data.  PDAs would benefit from non-HTML formatted stuff (too 
small a screen for most web pages), cell phones have their hardly-used 
WML, there are tons of different print formats like PDF or PostScript, 
plus alternative formats like troff (for man pages) and POD (for Perl 
manpages) and others.  XSLT lets you output from one source file to any 
desired format.

If you need versatility in the output of your data, XML can really help 
you.  Plus, it doesn't depend on browser version if that's what you're 
worried about -- it can be done server-side: use PHP to perform the 
transformation before it gets to the user if it's going to their 
browser.  That's why some XML-based sites let you choose whether to view 
the page in HTML or XML (so that if you want to use a spider or script 
to parse the data on the web page instead of looking at it in a browser, 
you can do that much more easily with the XML formatted output than the 
HTML formatted output).  Later on down the road, when (hopefully) all 
browsers incorporate an XSLT processor, the burden of performing the 
transformation can be handled by the client.

Not that client-side technology has been very successful at 
standardizing, in consideration of different JavaScript implementations, 
CSS implementations, and even Java Virtual Machines (witness Microsoft 
consistently refuse to ship a decent JVM with their OS, even though they 
are freely available from the Sun web site).

That's why server side stuff like PHP will probably always be invaluable.



Erik Price
Web Developer Temp
Media Lab, H.H. Brown

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to