Forum Moderators: open
I have a site (that is the center of entertainment news/guide/forum in New Zealand and it kills me at the moment that I cant push XML to the client, reference an XSL to format it up and turn it into XHTML/CSS client side and have a wonderful solution that is search engine friendly...
Thats basically the only thing stopping me, I like search engine traffic, I have lots of content, I'm building a publishing system at the moment that looks to the future by pulling its data as XML... But at the moment i'm reduced to doing an XML/XSL transformation server side and pushing the XHTML to the client...
Since I still thing AJAX etc. is immature and suffers the same problems... I'm stuck with good old XHTML...
*shakes hands in the air
"STEEEELLLAAAAAAAA, WHHHYYYYYYY?" :p
Do you see search engines favouring XML documents in the future? If googlebot could just do the transformation like one of my thousands of visitors browsers (I mean even IE can do it) and rank the pages... I'd be doin it... yesterday...!
[edited by: rogerd at 7:58 am (utc) on Nov. 15, 2005]
[edit reason] No specifics or URLs, please. [/edit]
There are real advantages to using good old HTML or XHTML rather than generic XML. Of course with some browsers you can style any old XML to look the way you want, but with HTML a simple browser or other program can just ignore the styling and rely on the basic meaning of the elements.
For example, Google knows that headings (h1, h2, etc.) are likely to contain more important text. If you have generic XML, the headings might be called 'heading' or 'subtitle' or something. How can a program know what they mean?
Also, things like RSS readers can just ignore CSS and stuff and display HTML in a very basic way. So they can strip it down to just basic elements, and display paragraphs, blockquotes, links, etc., in whatever style fits with their interface.
I can't see client-side XSLT being very important for many years for these reasons. It might be useful in certain situations (web-based applications, where you can require your users to have a compatible browser, and don't care about search engines, for example). But I don't see why normal websites would be better for using this sort of thing.
Unless I'm missing the point, or there's something cool about XSLT that I haven't realised?
And why would Google index an XML file (in some unspecified format) rather than the page people see? This would not be search engine (results) friendly - it would quickly result in a cloaking frenzy.
Forget about XML (and XHTML) unless you are actually using it to do something that you couldn't do before, or it makes an existing task easier. i.e. use it to solve a particular problem, not as an end in itself.
Mattur: The advantage of doing the transform client side is only when you're a big site like one of my sites that gets 3 million page views a month...
- I like the idea of feeding users "data" only. When they refresh pages they get XML and cache the XSL, CSS files.
- I like the way it breaks data (XML), application (XSL) and display (CSS) layers up. (ok so you cant get all your application stuff done in XSL but a lot of it).
My forum has millions of posts and thousands of people on it. Think of the advantage if refreshing a page only meant pulling down very small XML of the data.
Think of the advantage if refreshing a page only meant pulling down very small XML of the data.
I see what you mean. What sort of size difference between the XHTML file and XML file are we talking about here?
(Apologies if my previous post came across as harsh, I jumped to the conclusion that you were only doing this because you thought XML is more SE-friendly/semantic/future proof etc. My bad.)
The other benefit is that creating views as XML outputs means you can base your site on that framework. We're going to be syndicating content to many other sites that will link back to us for more info and if it could be considered just another "view" like any other page the dev work would obviously be put in one basket.