Why no one is re-purposing XHTML
Anyone who firmly commits to a CSS-XHTML development standard for their websites, often struggles with the process for the first 6 months - when it quite often seems easier to revert to the old tag-soup style of coding.
The organisational advantages and ease of future updates alone are enough to convince you that CSS and Standards are here to stay. But what next? You converted all your client sites into a standards wonderland. It's fantastic for search engines... and looks neat... and well... all your design is kept together in one neat css file... but is that it?
'But you can view our website on anything and it degrades happily'
Well one of the most significant advantages of the separation of style from content is the ability to re-purpose your content - not just expose it to <insert arcane/featureless/console/browser name>.
It seems that this one BIG reason for hitting the standards bandwagon is not really used at all!
As Andrew Tetlaw rightly points out in " The importance of semantics":
The semantic web, microformats, WYSIWYM; it's all too valuable to ignore. What is clear to me now is that each post is like a little database of information.
When you achieve a standards based site, you now have a valid (as in XML valid) file, which is now actually reusable - all the content from every <p> to <em> to tag with a class or id, is now fully accessible to be reused/re-purposed/collected/collated in an infinite level of detail.
So if this amazing level of content is freely available for no added development 'cost' why is no one using it?
One of the big problems with most CMS's (blog's included here) is they simply provide a front end to post articles, choose a template or layout, organise some files and set access. You might be thinking 'duh, that's ALL a CMS needs to do'.
There are a million CMS's out there and they all pretty much follow that format - an article is an entity to itself, a template is an entity to itself, files, user accounts, product databases - all little isolated roughly interconnected 'objects' with no further granularity than that.
Why? Well most CMS focus on the process or work-flow of posting an article - the content (whether it is a file/article/user-account) is secondary. Most CMS's use a development cycle based on choosing a database, a programming language, some templating pseudo-language and throwing in a heap of 'plug-ins'.
This is how we built our previous CMS. And it sucked.
With Spring however, we started out at the complete opposite end of the scale.
We started with the idea that all output had to be XML/XHTML standards compliant and that the real 'database' was actually in the XML not 'SQL'.
Secondly we decided that the programming language to build all of this was actually irrelevant - and that we would do the main structural processing in XSLT. At all stages the programming was to 'get the results to XML/XSLT as soon as possible'.
With those 2 decisions everything else falls into place.
Our programming (most is PHP - but it could be anything) is broken up into many small scripts that provide a URL based RESTFUL 'API'. A script only does as much as it needs to produce an XML feed or process and XML feed with an XSLT.
At the end of the day Spring is a collection of 'web-services' with a RESTFUL API via URL. And the web-services can be 'mashed' together to produce pretty much an infinite level of configurations.
So what the hell does this have to do with 'not re-purposing content'. Well because everything is XML/XHTML from the ground up and everything has an API, the full contents of posts are now fully exposed to every other Spring web-service, and can be mashed together in any method required to reuse the content.
Andrew has posted several fantastic example of this in his article - and highlights perfectly how every CMS SHOULD be able to use and reuse content.