XML, worth it?

[Tjobbe]

I have just started to understand XML and the meaning of it, but the point in it? not yet.

I understand you can use XML to store and describe data, but whats the point in using it if only ie5+, netscape6+ and firefox1.0 browsers are compatible with it!

shurely shome mishtake? why do i get the feeling XML is the next big thing when really, if you look at it that way, it isn't.

I re-did the test too, and when I first did it, I guessed most of the answers, and I got 17, today i got 16 - SURELY some mistake!

[Pauly]

XML is a way that financial and news companies and organisations, amongst others share data, because it's so compatible! The point in it for the web is XHTML. Using XML alone, is somewhat pointless and extensive to achieve what you can easily achieve in (X)HTML.

I was going to code my site with a .xml extension just so I could use crazy tags like <dont> <you> <steal> <my> <sh*t> and so forth, but when I realised how extensive the XML and CSS would be compared to your usual XHTML / CSS documents, it seemed somewhat pointless.

I'm pretty sure I read that W3C recommend to all developers to use XML whenever possible. It's about time we had a universal data sharing standard where developers aren't so pigheaded. 21st century now, crap is out, standards are in (Well coming in :lol: ).

I'm pretty sure the above is accurate - Someone correct me if I'm wrong, I'm still learning XML too ;)

[Tjobbe]

XML is a way that financial and news companies and organisations, amongst others share data, because it's so compatible! The point in it for the web is XHTML. Using XML alone, is somewhat pointless and extensive to achieve what you can easily achieve in (X)HTML.

I was going to code my site with a .xml extension just so I could use crazy tags like <dont> <you> <steal> <my> <sh*t> and so forth, but when I realised how extensive the XML and CSS would be compared to your usual XHTML / CSS documents, it seemed somewhat pointless.

I'm pretty sure I read that W3C recommend to all developers to use XML whenever possible. It's about time we had a universal data sharing standard where developers aren't so pigheaded. 21st century now, crap is out, standards are in (Well coming in :lol: ).

I'm pretty sure the above is accurate - Someone correct me if I'm wrong, I'm still learning XML too ;)

that is accurate, it says it on the w3schools XML tutorial so it MUST be true :wink:

but the reference to the browser compatibility is also true, it says so on the W3schools XML tutorial also.

my Fx and opera browsers can not read my XML documents. I made an XML file containing simple data, and then 'included' the data within a HTML file, as to the example on that site, Ie does it fine, but Fx and opera do not, maybe some settings within the browsers are disabled, I cant remember disabling them!

I have uploaded three files, the CSS, XML and the HTML with the 'included' XML data, I have also added the code of both on the HTML page. Unless I'm doing something wrong, which I don't think but wouldnt surprise me! Then Fx and opera should display the data, but it doesn't!

(notice im using the 'correct' abbreviation for FireFox!)

you can see what I mean at www.now-design.co.uk/xml/display.html

[Pauly]

That's funny, my Fx browser seems to read XML formatted files but not your site properly.

Wonder why that is .... (Maybe I'm stupid and don't know what I'm talking about).

[Tjobbe]

so you can see the tabular data on:www.now-design.co.uk/xml/display.html
-or cant you?

I'm starting to think its a basic coding error.

Shall I validate it? good idea!

[Tjobbe]

I am lost now, I thought I had done the tutorial and examples by the letter - I could swear on it. but now the validator is giving me errors, and I dont understand them.

http://validator.w3.org/check?verbose=1&uri=http%3A//www.now-design.co.uk/xml/display.html

It must be a coding error? surely?

Can't wait for america to wake up!

[inimino]

Tjobbe, the point of XML really has little to do with rendering in browsers. The point of XML is that it can be easily parsed and can contain structured data in a consistent format across many different uses. Rendering XML, other than XHTML, directly in a browser is a kind of cheap trick but it's not where the real benefit of XML lies. The real benefit is to programs that process the XML directly and do something interesting with it.

For example, your bank could provide you with your monthly bank account statement in XML format, and your financial program could then read that data and automatically update your records. Reading the same data with your browser would be much less interesting than having it directly imported into your financial program.

If you're thinking about browsers right now you need to stick with XHTML, and worry about XML if you want to do something with a client-server protocol that requires some kind of unique program on both ends. Then you can use XML for your data exchange if you like.

Hope that helps.

Also, the validation problems are in the containing HTML document, which is not valid HTML 4.01, not in the embedded XML. Your XML looks fine by the way.

[Dan]

I didn't read everything in the post, so I apologize if any of this repeats what has been said.

I see XML as a way of normalizing data rather than displaying it. XML with CSS is inadequate, since it lacks the structure needed to form webpages.. like on IE, you can't get rid of the margin on the page without a <body> tag.

Now there's XSLT, but it is pointless. You skin the XML with an HTML page, but you can't use external CSS. Now, on one hand, giving the user data and worrying about presentation after is a good idea as far as accessability goes, atleast it could be in the future. However, it SEVERELY limits what you can do.

XHTML, which I haven't investigated enough, will be the future as I can see--you have a layout, and incorporate XML data with <xml> tags, which allows for a more structured and dynamic content base.

[BigBison]

...Now there's XSLT, but it is pointless...

I beg to differ. I have a thread open in the private forums here showing some practical uses, that will soon be a thread here titled "XML for Webmasters". In the meantime, careful with the blanket statements like that -- if XSLT was pointless and "couldn't use CSS" then it wouldn't be exploding in use like it is. You run the risk of offending those who are focusing on it, for example me, who sees it as a far superior method of templating a CMS than using something like Smarty.

XHTML, which I haven't investigated enough, will be the future as I can see--you have a layout, and incorporate XML data with <xml> tags, which allows for a more structured and dynamic content base.

Take a closer look. XHTML will be generated from XML source trees using XSLT. There is no <xml> tag in XHTML.

[Dan]

I could have sworn w3schools said there was an XML tag to denote an area where XML would be used.

How do you mean by generating XHTML? When I used it, I just saw it as applying XSLT to XML, the same way as you would apply CSS [in a loose sense] to HTML.

What I meant by the CSS statement was that you couldn't use it externally--I should have been more clear.

[BigBison]

I could have sworn w3schools said there was an XML tag to denote an area where XML would be used.

I prefer the xml.com presentations by far over the very Microsoft IE-specific information at w3shools. Yes, there is indeed an XML tag, and it may very well function in XHTML 1.0, but that isn't where the future lies. I don't know much about XHTML 1.0 other than it really isn't XML, it's HTML 4. I don't know how to say it, I've considered posting my views on that coherently, but I work with XHTML 1.1 and 2 validation every day now and there is no <xml> tag in modular XHTML.

How do you mean by generating XHTML? When I used it, I just saw it as applying XSLT to XML, the same way as you would apply CSS [in a loose sense] to HTML.

XSLT can transform pretty much any text format into pretty much any other text format. HTML and XML are ultimately text files.

What I meant by the CSS statement was that you couldn't use it externally--I should have been more clear.

Sure you can. It took me a while to figure out how to embed my external CSS call properly in an XSLT-generated XHTML 1.1 file, but I assure you it works just fine.

[inimino]

There is no <xml> tag in XHTML.

Indeed, the rationale for this is that since XHTML is already an XML document, including an <xml> tag would be pointless. Rather, all the other tags of XHTML are part of the xhtml namespace, and XML namespaces allow you to mix and match XML tags from different namespaces within the same document.

[Dan]

Interesting.

Also, Eric, I'm taking a wild guess, but would you use two xml-stylesheet's to achieve embedding CSS in the file?

[BigBison]

IE 5+ implements a pre-standards version of client-side XSLT transformation. Other browsers may support it as well, but it's iffy and only XSLT 1, which is going out the door quickly in favor of 2. So, the next generation of browsers beginning with IE7, will most likely support client-side XSLT 2. The w3schools presentation does illustrate the concept if you accept these caveats and do the tutorial with IE.

One can write a fairly all-encompassing XSLT stylesheet for client-side caching, the exact same .xsl file is used on the server to generate (X)HTML output. Page requests, whether user-requested or dynamic, will involve the client requesting only the pertinent snippet of XML. In other words, whatever the output format (in my case, HTML 3.2, 4.01, XHTML Basic and 1.1 -- each of these is its own template) the XSLT stylesheet is served once, then the XML infoset it's transforming is varied.

Also, Eric, I'm taking a wild guess, but would you use two xml-stylesheet's to achieve embedding CSS in the file?

No. If your CSS is part of your XHTML document (in 1.1+, allowed only in <style> tags within the document <head>) then it's part of your XSLT stylesheet.

Again, stay tuned for a future thread. But, in my CSS-layout XHTML and HTML 4 presentations I have a container <div> within a container <div>, which don't exist in the table-layout HTML 3.2 version. The fantastic power of XSLT is that I can generate all versions from the same XML base document, which is then the document whose content is updated. That base document's markup is devoid of frilly <div> and <span> tags that we use to make our layouts work in CSS.

Sorry. I'm learning this stuff, it's a bit early for me to be writing about it yet.

[Dan]

Wow, I never really realized that until just now. I assumed that having an external template would take away from it, rather than make it better.

If I was only a little better with PHP, it would be nice to try for a forum--or CMS as you mentioned. Giving people XML would make templating a hundredfold easier as you now have data rather than some mishmash of code and pre-defined files.

Edit: Say you want to do tabs that change color based on whether the tab == the page you're viewing. Is there an effecient way to achieve this without re-caching the page? Maybe javascript?

[BigBison]

If I was only a little better with PHP, it would be nice to try for a forum--or CMS as you mentioned. Giving people XML would make templating a hundredfold easier as you now have data rather than some mishmash of code and pre-defined files.

Yes, and an open-standard template which doesn't have 1/100th the security risks of other methods.

[Dan]

Not allowed to re-edit posts, so..

Previous edit: Say you want to do tabs that change color based on whether the tab == the page you're viewing. Is there an effecient way to achieve this without re-caching the page? Maybe javascript?

The second edit I wanted to make was on using PHP with XML. I think linking to XML pages would have a consistancy problem as you can never dynamically generate the data. Wouldn't it be better to link to PHP pages which return XML than an XML page in and of itself?

[BigBison]

Edit: Say you want to do tabs that change color based on whether the tab == the page you're viewing. Is there an effecient way to achieve this without re-caching the page? Maybe javascript?

That's a good question, and one that's occurred to me. XSLT is pretty big, and I don't know the extent of what it can do yet. My educated guess at this point is "yes". Before resorting to javascript, the app that's generating the XML can do this and vary the infoset of the source document, for example:

<body>
<ul id="navlinks">
<li class="current"><a href="thispage.html">you are here</a></li>
<li class="linkto"><a href="anotherpage.html">this is a link</a></li>
</ul>
</body>


Then just apply a different CSS rule to each class of <li>.

[Dan]

I'll have to Google some more for an answer.

As far as stylesheets go, using xml:include looks like an option, however, it isn't as "correct" as a <link>.. [it now does not matter whether the CSS is external, but it's easier to read without CSS+HTML in one page, especially when you have 300+ lines of css]

[BigBison]

The second edit I wanted to make was on using PHP with XML. I think linking to XML pages would have a consistancy problem as you can never dynamically generate the data. Wouldn't it be better to link to PHP pages which return XML than an XML page in and of itself?

bold = Sure you can. In .htaccess, set up php as the handler for .xml files.

Your php code can query a database and format XML tags just as easily as HTML tags. Or, if you use an XML document with PHP as a handler, that PHP code is calling an XSLT processor to transform the XML document. Personally, I say ditch the filename extension entirely if you're working with XML. One client may want .pdf, the next .html, the next .xml (for a client-cached XSLT client only IMO) depending on what transformation is applied. To keep it simple, use an .html extension because that's what the client ultimately sees.

[BigBison]

As far as stylesheets go, using xml:include looks like an option, however, it isn't as "correct" as a <link>.. [it now does not matter whether the CSS is external, but it's easier to read without CSS+HTML in one page, especially when you have 300+ lines of css]

This took me the majority of the last two weeks to figure out, but let me kickstart you with this XSLT 2 stylesheet. It will transform any well-formed XML file you feed it into a bare-minimum XHTML 1.1 valid document containing simply the word "text".

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
<xsl:output method="xml" doctype-public="-//W3C//DTD XHTML 1.1//EN" doctype-system="http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"/>
<xsl:template match="/">
<xsl:text disable-output-escaping="yes">
<![CDATA[<?xml-stylesheet charset="utf-8" rel="stylesheet" href="example.css" type="text/css" title="style"?>]]>
</xsl:text>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>title</title>
</head>
<body>
<p>text</p>
<xsl:apply-templates/>
</body>
</html>
</xsl:template>
<xsl:template match="*"/>
</xsl:stylesheet>

Notice, not only is an .xsl file well-formed XML, but the above code also validates to the XSL standard, if you have a validating XML parser handy.

[Dan]

I was referring more to how the XML is generated. So say one day you want to switch <page><title> to <webpage><head>, you could just edit an index.php file. I usually use mod_rewrite as a default.

[inimino]

Absolutely, lose the extension altogether I say, even the .html. It's a historical artifact and has no semantic relevance or use to the user.


http://domain.tld/content


Clean and simple.

[Dan]

That's an interesting way of generating headers, but is there an advantage over just coding them in? Unless youy aren't supposed to have <!DOCTYPE> anymore [in favor of an XML alternative].

[BigBison]

I was referring more to how the XML is generated. So say one day you want to switch <page><title> to <webpage><head>, you could just edit an index.php file. I usually use mod_rewrite as a default.

Yuck, edit somebody's proprietary code? Why not just modify the XSLT to achieve the same thing?

That's an interesting way of generating headers, but is there an advantage over just coding them in? Unless youy aren't supposed to have <!DOCTYPE> anymore [in favor of an XML alternative].

Careful, now -- it's done that way for very good reasons that I won't go into here, but here's the resulting markup:


<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet charset="utf-8" rel="stylesheet" href="style.css" type="text/css" title="style"?>

<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>title</title>
</head>
<body>
<p>text</p>
</body>
</html>


That validates to XHTML 1.1, does it not?

[Dan]

Well, look at it this way: Say you want to store your hand-made site's data in a database. You need to go through a PHP script to get that data. So in effect, you don't have XML files, rather a PHP file that dynamically generates the XML for you. The only XML file you have as a 'make-believe' one from mod_rewrite.

[BigBison]

The only XML file you have as a 'make-believe' one from mod_rewrite.

Your php script generates an XML tree which you can do with as you please, like writing it to disk. Except what you will do, is pipe that XML tree from memory into the XSLT processor along with an instruction for which XSLT template to apply. If you want that resulting (X)HTML file cached, just like any other PHP output stream, you can set the HTTP headers to whatever you want.

Or just write the resulting .html file to disk, then an incoming request for "example" looks to see if example.html exists, if not (404 handler) example.php is called, which builds example.xml and applies example.xsl to it.

See Cocoon, the PHP version of which is called Papaan.

[Dan]

I think Popoon/Papaan/Cocoon is a bit robust for what I would do.

Again, I'm relatively new to XML, but in PHP, you just generate like you would HTML, right?

[BigBison]

Again, I'm relatively new to XML, but in PHP, you just generate like you would HTML, right?

Right. :)

[Dan]

That's a relief!

[BigBison]

On a side note, I've finally settled on my tools, more or less. Eclipse is a cross-platform Java-based IDE framework. For web development, you'll need a plugin or two. There is a nice comprehensive commercial distro of Eclipse, fleshed out with almost everything you could possibly want for web development, called MyEclipseIDE Enterprise Workbench. That covers you for everything shy of XML development.

On top of that, or just raw Eclipse, the essential tool for XML web development IMHO is Oxygen XML Editor. I've really put it through its paces up against XMLBuddy and XMLSpy, and only Oxygen made the final cut, primarily due to its support of RELAX NG, a schema language for XML, and XQUERY. Of course, its primary function for me is XSLT design & debug.

Dan, I've re-read this thread, and I really think you should look at XQUERY, which is designed to build an HTML page from a combination of XML snippets and SQL queries.

http://www.oxygenxml.com/

I've downloaded an interesting new product's trial version, it remains to be seen if I can make it accept a modular-XHTML doctype for the output document. I'm not able to form an impression of this as yet, but if it works as advertised what a fantastic timesaver it will be! Also an Eclipse plugin.

http://www.axizon.com/

[BigBison]

An essential open-source plugin which fits hand-in-glove with the above combo is AnyEdit:

http://andrei.gmxhome.de/anyedit/index.html

Quoting from the Eclipse website:
The AnyEdit plug-in adds several new actions to the context menu of Text-based Eclipse editors including the following:
Open file under cursor
Open type under cursor
Conversions: Leading tabs to spaces, Leading spaces to tabs, Chars to Html entities, Html entities to chars, Capitalize, Invert case

AnyEdit also allows you to automatically remove trailing whitespaces and/or perform tabs<->spaces conversion on a "save" action in nearly all text-based Eclipse editors. AnyEdit works with Eclipse 2.1.*, 3.0.* and 3.1.*.

Oh, puppy! Look what I just found:

http://www.abridgegame.org/pipermail/darcs-users/2005-March/006232.html

That's an Eclipse plugin for my favorite CVS alternative, DARCS! I've been frustrated with the lack of tool support for this simple, powerful, distributed source-control system for quite some time. Now, just when I've gone with the Eclipse platform, it's the first one to support it.

[BigBison]

Oops, forgot the URL for MyEclipseIDE Enterprise Workbench:

http://www.myeclipseide.com/

[Dan]

XQuery looks like a godsend for small sites. I'm going to investigate it a bit more later on.

Oxygen looks nice, but is it FAST? One think I like about my text editor is that it loads only a fraction slower than notepad and does what it needs [and more]. However, if one pops up that can have mock databases.. then we're talking.

Did you mean: CARDS

darcs
... Hello, I'm David Roundy, the author of darcs. Darcs is a revision control system. Darcs is simple to learn and use, with a powerful ...
abridgegame.org/darcs/ - 4k - Mar 25, 2005 - Cached - Similar pages :D

If the software can support this, however, it could be very nice--I've been itching to start using software like this, but again like things to be lightweight. [In the same logic that using Smarty for a script 1/10th its size is pointless.]

[BigBison]

Eclipse is anything but lightweight. If by fast you mean time to load, no. I use Scite as a notepad replacement, it is tiny-fast. Once Eclipse is running, is it fast? You bet! If I hit ctrl-space to bring up the code assist, even the longest list of tags pops right up without hesitation. My worry with switching to Eclipse was that Java apps are supposed to be slow, but this one isn't. If you want DB connectivity, I haven't looked for that yet but I would lay money on that capability being included in MyEclipse -- most everything else is.

I believe Eclipse natively supports CVS, I've also seen plugins for Subversion and Perforce, now DARCS. For web development, DARCS has several advantages, primarily by being binary-file compatible, and also in its unique patching concept. A hard-core coding project with branches and revisions may need something more industrial (then again, maybe not) but for what we do DARCS makes much more sense for the web developer.

[Dan]

Not DB connectivity, but having the script emulate a database.

I've looked at SVN but setting it up caused some odd quirks on my server.

I personally use EmEditor.com which was worth the $40 paid for it. It's my favorite piece of software.

[BigBison]

A product I get lots and lots of use out of is CSE HTML Validator (I'm on 7.0 beta3) Pro. It's small, fast, also checks spelling and accessibility guidelines, and is one of few HTML code editors that doesn't choke on XHTML 1.1. I have it running when I'm working with XSLT.

The output from the XSLT process is saved to disk each time, I have that file open in CSE. After transforming to XHTML 1.1, I task-switch to CSE, which tells me the file has changed on disk and asks if I want to reload. I hit yes, and the file is automatically validated. I can also validate this output file with Oxygen, but while this is quite handy, the error messages aren't nearly as helpful as CSE's.

It's really hard to look at your transformation-generated XHTML and tell if everything is where you expect it to be. A stray attribute left out of the XSLT sheet may not cause a validation error, but may trigger an accessibility warning. By instantly checking my results not only for validity, but accessibility and spelling is a vital QA/QC procedure for developing XSLT.

XML for Webmasters Preview:

Design your target XHTML document as you normally would. Then, look at the code within the <body>. Strip it down to the bare essentials -- whatever isn't related to the content, say a container <div>, can be moved to the XSLT sheet. We're after a source XML document with <body> as its root element, but don't get carried away just yet --

In my case, I'm using XML inclusions for content, so my actual document framework looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<body xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:include href="header.xml"/>
<xi:include href="body.xml"/>
<xi:include href="footer.xml"/>
</body>

The source XML document I need at this point is the XML infoset a parser would return after including all elements -- the final infoset before transformation.

Now, you have your source and target documents. All that's left is writing the XSLT sheet. If your source XML document is, aside from lacking the tags which encapsulate <body>, valid XHTML 1.1 then you simply change this line from the XSLT sheet I posted earlier in this thread, which blocks everything in the source from being copied:
<xsl:template match="*"/>
To the so-called "identity template" which copies the source document to the target:
<xsl:template match="*">
<xsl:copy>
<xsl:copy-of select="@*"/>
<xsl:apply-templates/>
</xsl:copy>
</xsl:template>

Provided your XML source document is XHTML 1.1, the following will work, ignoring for the moment the external CSS stylesheet reference. For XHTML 1.1 output, the following line is used:

<xsl:output method="xml" doctype-public="-//W3C//DTD XHTML 1.1//EN" doctype-system="http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"/>

To get XHTML 1.0 strict, change it like so:

<xsl:output method="xhtml" doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN" doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"/>

There's even a way to suppress that nasty XML prolog so IE won't choke into quirks mode, but I've lost my reference to it atm. Moving on, let's say you want that same source document to spit out HTML 4.01 strict. The tags are all good, except for the ones that <selfclose/>. No problem, use this line instead:

<xsl:output method="html" doctype-public="-//W3C//DTD HTML 4.01//EN" doctype-system="http://www.w3.org/TR/html4/strict.dtd"/>

Yeah, that appeals to my lazy Sunday Afternoon side! I've oversimplified a bit, you'll actually need to modify the <html> tag, but notice how the correct meta tags are added when you're set for XHTML or HTML output?

Let's say you're using a custom tag or two, and you want to make sure they're not copied to your output -- which would make the target document invalid. Simply change the <xsl:copy> tag to read <xsl:copy validate="strip"> and any tags in the source which aren't valid for the target won't be copied. You can still transform those into valid tags with another template, of course.

[Dan]

Eric, I'd make a decent reply, but I want to test out some of these editors/more XML first. Switching hosts, too, so I'm in a sort of do-nothing interim.

[BigBison]

If I was only a little better with PHP, it would be nice to try for a forum--or CMS as you mentioned. Giving people XML would make templating a hundredfold easier as you now have data rather than some mishmash of code and pre-defined files.

Definitely. Any type of CMS should really use XML as its data storage format, and is the #1 reason I'm writing my own. I looked extensively at a variety of forum, blog and wiki software over the course of last year. Blog software, at least, typically stores user posts as HTML.

But forums and wikis? All the information held within a forum is destined for HTML display. So why are posts stored as BBcode? What kind of standard is that? Not one that's based on SGML like everything else Web. In the case of wikis, posts are stored as wiki markup. Most wikis out there have their own idiosyncracatic wiki-markup code. Again, no standard exists, and stored data lacks portability.

At some point along the line, that BBcode/wiki markup is transformed to HTML. I say, why not transform it to a well-formed XHTML snippet when posted, and store that? That XML can then be transformed via XSLT processing into whatever is needed. In the case of a user editing a previous post, what appears in the textarea for editing is easily transformable into the user's original, preferred format -- i.e. BBcode.

By storing posts as XML, even if the format is proprietary, the data becomes forwards-compatible as it can be transformed into whatever format is necessary for a different CMS. Compare that utopian thought with the current state of affairs -- how easy is it to migrate from one forum software package to another?

Even if there is a migration utility available, I can guarantee that the template/skin still needs to be totally reworked, which involves throwing out the previous template and starting from scratch, likely in a different templating language. I'd prefer to simply re-map my XSLT files.

[BigBison]

In my case, I'm using XML inclusions for content, so my actual document framework looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<body xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:include href="header.xml"/>
<xi:include href="body.xml"/>
<xi:include href="footer.xml"/>
</body>

I should also mention that this approach works with XSLT as well. I can design separate XSLT sheets and name them header.xsl, body.xsl and footer.xsl. Those sheets may then be included by the XSLT sheet that's applied to the compact .xml file. The above XML document, and the compact XSLT sheet that includes the others, are typically called "drivers". It's easier to maintain the smaller files inherent in this modular approach.

[BigBison]

...There's even a way to suppress that nasty XML prolog so IE won't choke into quirks mode...

<xsl:output omit-xml-declaration="yes"/>

Can't believe I mis-typed that line. Should have read, "There's even a way to suppress that XML prolog so nasty IE won't choke into quirks mode..."

:lol: I like that better! Stay tuned, I'm working on a correction to a little bit of misinformation I posted above.

[BigBison]

<xsl:text disable-output-escaping="yes">
<![CDATA[<?xml-stylesheet charset="utf-8" rel="stylesheet" href="example.css" type="text/css" title="style"?>]]>
</xsl:text>

Should be:

<xsl:processing-instruction name="xml-stylesheet">charset="utf-8" rel="stylesheet" href="example.css" type="text/css" title="style"</xsl:processing-instruction>

[BigBison]

...the so-called "identity template" which copies the source document to the target:
<xsl:template match="*">
<xsl:copy>
<xsl:copy-of select="@*"/>
<xsl:apply-templates/>
</xsl:copy>
</xsl:template>

I've also seen the identity template written like this, which is a bit more flexible:
<xsl:template match='*|@*'>
<xsl:copy>
<xsl:apply-templates select='node()|@*'/>
</xsl:copy>
</xsl:template>

[BigBison]

IE 5+ implements a pre-standards version of client-side XSLT transformation. Other browsers may support it as well, but it's iffy and only XSLT 1, which is going out the door quickly in favor of 2. So, the next generation of browsers beginning with IE7, will most likely support client-side XSLT 2. The w3schools presentation does illustrate the concept if you accept these caveats and do the tutorial with IE.

I jumped the gun on this a bit. IE7 won't support XSLT2, it will still have MSXML XSLT support, and still won't handle 'application/xhtml+xml' properly. As to XSLT support on web browsers, get ready to add Opera to the list:

http://snapshot.opera.com/windows/w90p1.html

Yup, get ready for Opera 9! Notice they've moved past SVG Tiny to (partial) SVG Basic compliance.