tags:

views:

487

answers:

10

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

A: 

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.

Andy White
A: 

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.

Saint Gerbil
+1  A: 

Arguably this is a duplicate of Is there a point creating a site using XSLT. Specifically I'd draw your attention to The Death of XSLT in Web Frameworks.

cletus
and a dupe of http://stackoverflow.com/questions/78716/is-xslt-worth-it
annakata
That "Death of XSLT" article isn't very good. The logic can most likely be done in the XPath pattern in xsl:template match, not xsl:choose.
Steven Huwig
"The Death of XSLT ..." uses terrible and non-well-formed examples for the XSL (See the first code sample in the article). XSLT is a very verbose language, but the author is slanting it quite a bit with unnecessary code.
sirlancelot
+2  A: 

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.

Marc Gravell
+1. I use XML and XSLT for several sites and every transform is done on the server side, thus allowing me not to care about browser support.The only issue is that it does not allow people to use the Semantic Web tools. Sometimes, I address it by sending the HTML file by default but allowing, with an explicit URL, to get the XML source.
bortzmeyer
+1  A: 

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.

PQW
A: 

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.

Cerebrus
A: 

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.

Anriëtte Combrink
A: 

(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.

PQW
A: 

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.

Dario
A: 

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.

Russell Leggett