Is it a good idea to use XML and XSLT for websites?

Question

I'm wondering whether it brings advantages or disadvantages when using a XML document for the content of a web page and XSLT to manage the display part and not using plain HTML.

The first condition in my eyes is browser support for XML and XSLT. But as far as I know no modern browser has a problem with it. (Correct me if I'm wrong.)

But are there for instance benefits (semantic web and so on) or losses (HTML tags are more common) in the ranking of search engines?

Or do you see other reasons why one should or should not use the combination of XML and XSLT for web pages?

Related:

Why choose an XSL-transformation?

Is there a point creating a site using XSLT

Answer 1

This is a VERY important topic. 10 years ago, people were beginning to ask this questions.....can we send data packets to browsers and have the browser render the content? The reason that design goal is so important is to address the problem we face today.....multiple types of devices and tablets that dont fully support the desktop model of browsing. XHTML has taken us so far.....now ECMAScripting is what people are trying to create to do such a thing. But its a very bad model in the long term. It breaks with the repurposing goal of markup and content on the web.

The answer is YES....you can build XSL/XSLT/XML types systems. You can send a packet of XML and with a link to its XSLT style sheet and have most if not all modern browsers parse the file into markup on the client. Ive done it and it works unbelievably fast.

Now the draw backs mentioned by the group are real ones. There are issues with how browsers parse the XSLT and then render say scripting elements and caching of stale XML, etc. There are real issues with interfacing with design teams, and learning to abstract content and design and structure into these types of pieces. But this is the real goal of the Web long term, and why XSL was designed the way it was. Its power is in separating out structure, data, and design, and freeing both the server and the client from the slavery of content locked into the design elements. Javascripted solutions, compiled and layered into the UI, has not helped but made it worse, because the markup design and data is often meshed together. I would encourage all new web developers to start considering an XSLT/XML solution because the end-goal is to be able to focus on XML data delivery to a whole host of clients BEYOND desktop browsers. If you have XSLT/CSS designed for a whole host of different devices, and XML is all thats sent beyond caching to your clients, you have a very simple, fast, and powerful repurposing data delivery system that goes beyond what the current desktop app/desktop browser-based web sites now give us, and usher in a truly expandable and powerful data delivery age for the Web. So, I say yes, give XSLT a try!

Answer 2

Here is an example of an xsl based website.

http://www.skechers.com.

Enough said

Answer 3

I've never heard of anyone else doing this, but I use XSLT as something of a macro language for an XML based html templating language. I don't use it for large scale transformations from one document to another, but rather for essentially custom tags. The templates get run through the xslt before getting compiled, so it doesn't ever need to actually manipulate data. What it provides though, is a way to just use a piece of xml as succinctly as possible, and then perform a very simple transform to output code in a way that would be impossible or at least more difficult to do in the templating language itself.

With html, there is often the need to nest divs, and add classes etc. just to get it to look right without adding any real meaning. Instead of repeating that pattern all over the place, it's easy to just create a custom element, and then write a simple XSLT transform to take that element and its attributes and turn it into the fully expanded html. However, I would never dream of using XSLT as the only means of templating data. Just too hairy.

Answer 4

I had to use clientside XSL(T) on my homepage to prevent the freehoster from inserting advertisement automatically ;-) (IE and Firefox had problems with this!)

I would use XML on the serverside but never transmit anything but plain XHTML+CSS. It's essential to the internet that everything is built up in one technology and not thousands of personal languages and semantics.

Answer 5

(Since I cannot comment yet this was ment as a a reply to "Saint Gerbil")

Actually you can use ASP.NET controls in XSL and it's very simple, add the namespace asp to the XSL, do the transform into a stringwriter, then parse for the controls in the transformed string:

// Transform
xsltrans.Transform(xmldoc, xslArg, oSW);

// Get transformed content
string sPage = oSW.ToString();

// Add to page
Page.Controls.Clear();
Page.Controls.Add(Page.ParseControl(sPage));

This will parse any ASP.NET controls inside the transformed content.

Answer 6

I do use XML sometimes, for when a website does not have a MySQL DB or just for record of a small array of items (which needs to be changed alot), and then use PHP to parse it in my webpages with HTML/CSS.

However, this does require that you manually edit each xml entry, so just use it for small applications.

Answer 7

If you compare it to the power of server side code, XSLT falls short on several parameters.

If your page is entirely dynamic, it would still be worthwhile to create it in the server side code. If your data source is XML, your could still use server-side XML parsing and transformation to create the transformed XHTML and serve it to the client.

It is rarely necessary to exclusively transform HTML on the client completely relying on the capabilities of the browser. Most modern browsers have a good XML/XSLT support, but their main difference lies in the type of XSLT processor used.

Answer 8

You should do the transformation on the server side and not rely on the browser support.

We use it to support multiple languages on our website. Disadvantage is that sometimes our designers have a steep learning curve with designing their pages using XSL/XSLT/XPATH.

Answer 9

Personally I wouldn't use clientside xslt very often; there are issues with browser support, and the fact that you may have data in the xml that you need to strip out (i.e. that the client doesn't need to know, or shouldn't know).

But serverside... back a few years, I used to routinely use this approach as an MVC implementation from VB6 - i.e. the VB6 code (the controller) gathers data as xml (the model), and uses xslt to shape the html (the view). It worked well in terms of separation of concerns. These days I would use ASP.NET MVC to do the same, but with ascx/aspx view templates.

Answer 10

Its a fine way of doing things but unfortunatly alot of server side technologies dont support the idea.

For example in ASP.NET you cant use Server Controls with this approach which is normally enough to turn people off.

XSLT is great for pages which have no interaction like reporting however.

Answer 11

XHTML is an XML version of HTML. I would probably avoid using XSLT for websites. I would use XHTML along with CSS to control the presentation. I say this because (X)HTML/CSS is pretty much the de facto standard for web applications, and there are many more tools available for development and debugging.

There are different levels of validation for XHTML if you want to leverage some of the non-ideal HTML stuff within XHTML.